Subject: [EAI] MAIL FROM SMTPUTF8

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 17 Jun 2013 22:15:41 +0200

Hi,

it's not clear to me what an SMTP (or submit) server should do if it
receives a plain old message with MAIL FROM ... SMTPUTF8, or an
internationalized message without MAIL FROM ... SMTPUTF8. Can any of
you advise?

Also, while I'm writing, I've read the paragraph about avoiding risk,
but do not understand how the extra parameter avoids risk. I realize
this is water under the bridge, but I'm curious.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2013 22:13:00 -0000

>internationalized message without MAIL FROM ... SMTPUTF8. Can any of

What would it do if it saw this?

MAIL FROM:<@!)#@N@@)()c$!> KAFLOOGA

It should do the same thing, probably fail the command with a 501 or
555 error.

For stuff with invalid content in the message, a submit server would
probably try to fix it up using unspecified heuristics, and a mail
relay would just sigh deeply and pass it along.

I hope that nobody spends time changing the code in SMTP servers to
add special case for EAI commands other than making them support EAI
mail.  I suppose it's possible that buggy clients will send EAI to
servers that don't advertise the feature, but there's nothing new about
broken clients sending broken mail.

R's,
John

---

From: [email-masked]
Date: Tue, 18 Jun 2013 07:10:35 -0700 (PDT)

> broken clients sending broken mail.

Completely agree in regards to an EAI message without SMTPUTF8. As for a
non-EAI message that's marked EAI, how I handle that is going to depend on
whether or not for other reasons I happen to notice that the message isn't EAI.
If I do notice that I may choose to drop the EAI label. But expecting agents
to do a full MIME parse just to determine the EAI-ness of a message? Not
going to happen.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 18 Jun 2013 10:34:43 -0400

--On Tuesday, June 18, 2013 07:10 -0700 [email-masked]
wrote:

>...
> Completely agree in regards to an EAI message without
> SMTPUTF8. As for a non-EAI message that's marked EAI, how I
> handle that is going to depend on whether or not for other
> reasons I happen to notice that the message isn't EAI. If I do
> notice that I may choose to drop the EAI label. But expecting
> agents to do a full MIME parse just to determine the EAI-ness
> of a message? Not going to happen.

Agreed.  I would add that, IIR, the decision of the WG to
require explicit client announcements of EAI addresses or
headers was a decision to eliminate all claims that a recipient
MTA was required to parse content to determine what to do about
it.  I don't think we should be reversing that decision through
the back door even though nothing prevents such an MTA from
doing a full MIMR parse if its designers believe that is
necessary.

   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 18 Jun 2013 21:22:17 +0200

I understand now. Thanks.

Arnt