Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 18:01:38 +0000

Exactly?  If I'm an EAI aware client and I'm connecting to an EAI aware server, then I SHOULD really use the UTF8 MAIL FROM.

The value of MAIL FROM is to complete the handshaking, so the server knows that the client is EAI aware.  Nobody should be inspecting every message.

The one exception could be if my EAI aware client is passing along a message it got from a non-EAI source, in which case it could avoid the MAIL FROM UTF8, to avoid the risk of any response breaking the return path.  Any messages generated from the EAI aware system SHOULD use the UTF8 tag though.

-Shawn

 
http://blogs.msdn.com/shawnste

----------------------------------------------------------------------

Message: 1
Date: Tue, 18 Jan 2011 15:23:56 -0800
From: Bill McQuillan <[email-masked]>
Subject: Re: [EAI] Consensus Issue #1:  parameter on MAIL FROM?
To: IMA Discussion <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

I am concerned about the case where the client does NOT know that there is
an EAI facility needed, but THERE IS a need!

For example, a client (which is EAI compliant) is handed a message (say, by
SUBMISSION) which has no non-ASCII recipients or non-ASCII in its header.
The client contacts the MX server for one or more of the recipients and
begins a transaction with MAIL FROM: using *no* UTF8 parameter.

It then sends RCPT TO: commands until one of the recipients has a
forwarding address and the MX server would like to return a 551 reply
suggesting a <forward-path>. However, the <forward-path> is a non-ASCII
address and the MX server has no way to return this to the client since the
client must be presumed to be NON-EAI compliant due to the lack of a UTF8
parameter on the MAIL FROM: command.

This all presumes we are using the UTF8 parameter to both relieve the MX server
from Deep-Analysis as well as informing it of the capabilities of the
client.

Bill McQuillan <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Jan 2011 13:24:18 -0500

Hmm.

It seems to me that we have another, more fundamental, issue
here.   I'm not trying to do a formal appraisal of consensus
(Joseph's problem), but it seems to me that among those who have
advocated a keyword (without counting, at least a majority so
far), there are two separate opinions about what it means:

	(1) A handshake announcement that the client is
	EAI-capable (see Shawn's note below as an example)
	
	(2) An announcement from the client to the server that
	the message actually requires (or at least probably
	requires) EAI capabilities.

FWIW, note that the _only_ reply text that require
EAI-capability are those to VRFY and EXPN and the "new address"
codes, which we have nearly, but not quite, deprecated in
broader Internet contexts (e.g., non-enterprise ones).  Those
three cases need to return addresses, nothing else does.
Inclusion of mailbox names in replies to MAIL, RCPT, or any
other command is not required or suggested in RFC 5321 and, at
least in my experience, is uncommon.

If we go with the "handshake" model, then there is no issue with
replies containing text not permitted by 5321 (i.e., text
containing Unicode characters with code points above U+007F,
encoded in UTF-8).  But a server that actually needs to know
whether a message requires EAI capabilities (e.g., to deliver it
to a message store with appropriate information for POP or IMAP
clients) has to parse the message.

If we go with the "announcement" model, then the parsing problem
is eliminated but there is no possibility of replies that are
invalid under 5321 when the announcement is not made, i.e., when
the message, headers, and addresses are strictly 5321-conforming.

Speaking personally, I could live with either decision although
I have a preference.  But we need to resolve this difference and
have an unambiguous interpretation for the authors of 5336bis to
complete their work.   I assume that will require a separate
consensus call but hope we can have enough discussion first that
everyone understands both options.

      john

--On Wednesday, 19 January, 2011 18:01 +0000 Shawn Steele
<[email-masked]> wrote:

> Exactly?  If I'm an EAI aware client and I'm connecting to an
> EAI aware server, then I SHOULD really use the UTF8 MAIL FROM.
> 
> The value of MAIL FROM is to complete the handshaking, so the
> server knows that the client is EAI aware.  Nobody should be
> inspecting every message.
> 
> The one exception could be if my EAI aware client is passing
> along a message it got from a non-EAI source, in which case it
> could avoid the MAIL FROM UTF8, to avoid the risk of any
> response breaking the return path.  Any messages generated
> from the EAI aware system SHOULD use the UTF8 tag though.

---

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 23:36:10 +0000

I agree with your analysis, but I think I reach a different conclusion.  I'm not sure that in practice it matters whether an individual message announces UTF8SMTP or not.

It seems likely that, at least some, clients will announce UTF8 on MAIL FROM just because they can, or because it's easy, or because of a bug, but, in any case, that the server will get UTF8 declared messages containing only ASCII content.  

Similarly, some mail servers don't going to trust that the client implementations are perfect, and will probably check for UTF8 even if the keyword is missing, just to be careful.

Presumably, if I have an EAI server, and users get EAI mail, then they should have EAI POP/SMTP clients.  If they don't, then they probably rarely get EAI mail.  I suppose it's possible that the admin updates the server, but the clients are 5 years old, but that seems like an odd edge case.

-Shawn

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Poʻakolu, Ianuali 19, 2011 10:24 hours
To: Shawn Steele; [email-masked]
Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

Hmm.

It seems to me that we have another, more fundamental, issue
here.   I'm not trying to do a formal appraisal of consensus
(Joseph's problem), but it seems to me that among those who have advocated a keyword (without counting, at least a majority so far), there are two separate opinions about what it means:

FWIW, note that the _only_ reply text that require EAI-capability are those to VRFY and EXPN and the "new address"
codes, which we have nearly, but not quite, deprecated in broader Internet contexts (e.g., non-enterprise ones).  Those three cases need to return addresses, nothing else does.
Inclusion of mailbox names in replies to MAIL, RCPT, or any other command is not required or suggested in RFC 5321 and, at least in my experience, is uncommon.

If we go with the "handshake" model, then there is no issue with replies containing text not permitted by 5321 (i.e., text containing Unicode characters with code points above U+007F, encoded in UTF-8).  But a server that actually needs to know whether a message requires EAI capabilities (e.g., to deliver it to a message store with appropriate information for POP or IMAP
clients) has to parse the message.

If we go with the "announcement" model, then the parsing problem is eliminated but there is no possibility of replies that are invalid under 5321 when the announcement is not made, i.e., when the message, headers, and addresses are strictly 5321-conforming.

Speaking personally, I could live with either decision although I have a preference.  But we need to resolve this difference and have an unambiguous interpretation for the authors of 5336bis to
complete their work.   I assume that will require a separate
consensus call but hope we can have enough discussion first that everyone understands both options.

      john

--On Wednesday, 19 January, 2011 18:01 +0000 Shawn Steele <[email-masked]> wrote:

> Exactly?  If I'm an EAI aware client and I'm connecting to an EAI 
> aware server, then I SHOULD really use the UTF8 MAIL FROM.
> 
> The value of MAIL FROM is to complete the handshaking, so the server 
> knows that the client is EAI aware.  Nobody should be inspecting every 
> message.
> 
> The one exception could be if my EAI aware client is passing along a 
> message it got from a non-EAI source, in which case it could avoid the 
> MAIL FROM UTF8, to avoid the risk of any response breaking the return 
> path.  Any messages generated from the EAI aware system SHOULD use the 
> UTF8 tag though.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Jan 2011 20:48:34 -0500

--On Wednesday, 19 January, 2011 23:36 +0000 Shawn Steele
<[email-masked]> wrote:

> I agree with your analysis, but I think I reach a different
> conclusion.  I'm not sure that in practice it matters whether
> an individual message announces UTF8SMTP or not.
> 
> It seems likely that, at least some, clients will announce
> UTF8 on MAIL FROM just because they can, or because it's easy,
> or because of a bug, but, in any case, that the server will
> get UTF8 declared messages containing only ASCII content.  

> Similarly, some mail servers don't going to trust that the
> client implementations are perfect, and will probably check
> for UTF8 even if the keyword is missing, just to be careful.

That combination reinvents the argument for "just let them parse
if they really want to know" and takes us back to nearly where
we started.

> Presumably, if I have an EAI server, and users get EAI mail,
> then they should have EAI POP/SMTP clients.  If they don't,
> then they probably rarely get EAI mail.  I suppose it's
> possible that the admin updates the server, but the clients
> are 5 years old, but that seems like an odd edge case.

I fear it is quite a common case and is likely to be for some
time.  Remember an observation that folks from your company have
probably made more strongly than anyone else: servers get
upgraded and replaced according to need but Operating Systems
and fundamental software (probably including non-web-client
MUAs, including POP and IMAP clients) get upgraded only when
computers are replaced.

    john

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 10:58:48 +0100 (CET)

> MUAs, including POP and IMAP clients) get upgraded only when

"do not touch a working MUA and MTA" is a common message in nearly all 
environments... and unless you really know that an upgrade will solve you 
many problems, nobody will do upgrades (... or more specifically, nobody 
will be allowed to do an upgrade, just because of the - small - risk of 
having a non working e-mail system after it).

Okay... we could start teling people that implementing EAI conformance 
will solve spam problems... and everybody will rush tu support it. But 
where do we hide ourselves when they discover it is not true?

*the above sentence is a joke*

  > >    john >
>
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca