Subject: Automatic LHS downgrading is not on the agenda (Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label)

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 07:12:25 +0100

Charles Lindsey wrote:
>
> Are you now accepting that the use of Punycode for downgrding 
> local-parts is now back on the agenda, subject to a suitable technical 
> specification of exactly how to do it (and possibly in conjuction with 
> an ATOMIC, or more likely DOWNGRADABLE, keyword)?
(chair hat on)
I am not accepting that.

If you insist, I can make it the subject of a formal poll, but I think 
we've debated this enough times, and if anything the decision that "the 
sender decides what the downgraded address should be" has become more 
absolutist over time (this was why ATOMIC was removed).

                        Harald

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Nov 2006 12:44:22 +0100

John C Klensin wrote:
 
> I don't understand what you are saying above.  Perhaps a word
> is missing; perhaps I'm just confused.

Maybe it's just some case of "DEnglish" on my side.  I agree
completely with our description of a backup MX forced to fight
on its own while the primary MX (or any other source to get up
to date info wrt local recipients) is down.

It's in a bad position, if it accepts almost anything it will
get numerous rejects later, causing bounces to random addresses.

That's of course unacceptable, it would be handled as net abuse,
adding the IPs of the MTA sending those bounces later (that's
not necessarily the same MTA as the backup MX) on block lists.
After that some valid DSNs won't make it to the senders, their
mail is lost in a black hole.

Therefore the backup MX should try to limit mails it accepts as
good as possible, rejecting anything that's "unclear" (e.g. from
alleged "dynamic IPs", or similar black lists).  With TempFail
or greylisting it can survive on its own for about 100 hours.

That's the best it can do - of course there's no problem at all
with SPF PASS or FAIL mails if the backup MX supports SPF, but
most mails today won't offer this good/bad Return-Path indicator.

> When the target server is off-net or offline, the backup MX 
> receives all traffic bound for the target server and stores it
> for future delivery

Receives, yes, but it won't accept all.  Otherwise botnets could
take out the primary MX, and then flood the backup MX with their
crap.
  
> as I understand it, your proposal would prohibit those kinds of
> arrangements entirely, since the backup MX host would not have
> knowledge of the authenticity of sending addresses

No, it only needs to reject more radically than an ordinary MX,
e.g. TempFail based on DNSBLs - as far as I'm concerned it could
accept SPF PASS without further checks, but probably it's cheaper
to check DNSBLs first.  Implementation details, how it does this
is its own business.  Unsolicited DSNs will be reported as spam
no matter what we say.  

I tried to convince the SpamCop folks that such reports should be
limited to (unnecessary) SPF FAIL bounces, precisely because of
this "backup MX" scenario (among others like "over quota"), but
they didn't like that, claiming that "backup MX" is a hopelessly
obsolete concept. :-(

> it couldn't do real-time forward checks (VRFY?)

Or what you described here in another article, an SMTP dialogue
with the next hop, squeezed into the timeout between RCPT TO and
DATA, emulating VRFY by MAIL FROM + RCPT TO.  

> I don't think that conclusion, and prohibition, is tolerable, at
> least without an email regime in which only trusted hosts are
> permitted to send mail

White listed senders are a piece of the puzzle:  If the backup MX
knows that anything from say w3.org is normally "good" it only has
to verify that a client claiming to be w3.org really is w3.org -
if I try `nslookup -q=txt frink.w3.org` it's not hard to decide.

A very simple check eliminating some zombies could insist on one
dot, not found in "ehlo oemcomputer".  I really wish my ISP would
try that instead of their post-SMTP sieve-magic, when it's far too
late for any reliable way to deal with suspicious mails.  Updating
those zombies to get at least the dot right is no serious hurdle,
but IMO a step in the right direction.

> we are nowhere near getting there.  YMMD.

It's - no surprise - specified in RFC 4408 + errata, the original
concept are RFC 821 reverse paths (skipping RMX and other details).

> as Charles has pointed out, all of these issues exist without any
> i18n extensions, so they are not really the province of this WG.

ACK, but he also wrote this in <[email-masked]>:

| The only difference in the case of UTF8SMTP is that such messages
| may create more bounces than regular messages usually do.

EAI must not make it worse than it is.  It should use neutral terms
like "reject" instead of "bounce" where applicable.  That was the
point of the subject "issue: framework 4.1 - reject".  If a border
MTA accepts mails "on probation", claiming that they always could
be bounced later, it's probably doing something wrong.  Maybe based
on "(as indicated by the reverse-path)" as false premise for 80% of
the mail traffic today.

Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Nov 2006 12:23:15 +0000

John C Klensin wrote:

>--On Monday, 30 October, 2006 20:36 +0000 Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Charles Lindsey wrote:
>>    
>>
>>>>3.  Document Plan
>>>>  In addition to this document, the following documents make
>>>>  up this specification and provide advice and context for
>>>>   it. o  SMTP extensions.  This document
>>>>  [I18Nemail-SMTPext] provides an SMTP extension for
>>>>      internationalized addresses, as provided for in RFC
>>>>      2821.
>>>>        
>>>>
>>>Is not LMTP extended in the same way?
>>>      
>>>
>>Good point.
>>    
>>
>Not in the charter.  In other words, one thing at a time.  If we
>can get this right for SMTP and then move toward standards-track
>specs, certainly an LMTP upgrade should be part of that effort.
>  
>
This is a one line change to LMTP, IMHO: "The same SMTP extension can 
also be used with LMTP".

But otherwise I agree with "one thing at a time".

>>>>   There are many places in MUAs or in user presentation in
>>>>   which email addresses or domain names appear.  Examples
>>>>   include the conventional From, To, or Cc header fields;
>>>>   Message-IDs; In-Reply-To fields that may contain
>>>>   addresses or domain names; and in message bodies.
>>>>        
>>>>
>>>Arrrrrgghhhhh! No! Message-IDs do NOT contain email addresses
>>>(they  just  look
>>>like email addresses).
>>>      
>>>
>>Yes, I've stumbled on this text as well.
>>
>>I think Message-ID/In-Reply-To are examples of the "or domain
>>names" part.
>>    
>>
>
>Yes.  But I have restructured the sentence to clarify this and
>noted that Message-IDs may be a special case.
>  
>
Good.

>>>>   ago and not just those delivered seconds ago.  As such,
>>>>   MUAs and mail filtering software will need to continue to
>>>>   accept and decode header fields that use the "encoded
>>>>   word" mechanism [RFC2047] to accommodate
>>>>        
>>>>
>>>                                                           ^
>>>                                             and the
>>>                                             mechanisms of  
>>>[RFC2231]
>>>      
>>>
>>>>   non-ASCII characters in some header fields.
>>>>        
>>>>
>>>Not sure what "filtering software" you have in mind that
>>>might need  to  decode
>>>2047 and 2231 stuff.
>>>      
>>>
>>E.g. Sieve mail filtering, which can run inside MTAs or MDAs.
>>    
>>
>Yes, that is what we had in mind along with some non-standard
>techniques.  Do you think Sieve should be explicitly referenced
>as an example and, if so, should the reference be to 3028 or to
>something else?
>  
>
I don't think there is any need, but an informative reference to RFC 
3028 would be fine with me.
(IETF LC for 3028bis just ended, but it doesn't really matter which one 
is referenced)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 05:27:54 -0800

This issue has been assigned #1388.

I believe the debate has shown:

- The most controversial aspect here is whether message/rfc822 can be 
used for passing around UTF8SMTP messages or not.
- There are multiple people who think that doing so is asking for 
trouble, so we should do something else, and one person (Charles) who 
believes that it should be so used.
- A separate draft, draft-hurtta-eai-encapsulation, has been written, 
but not submitted (kari, can you get it onto a website somewhere? If 
necessary, send it to me..), detailing one "something else"

I believe the needed change to the Framework document is to state that 
the "headers" document also needs to describe the interactions between 
UTF8SMTP messages and MIME, and the details need to be tackled as part 
of the discussion on the headers document (and possibly Kari's document).

Makes sense?

              Harald

Frank Ellermann wrote:
> The "document plan" in chapter 3 tries to get away with updating 2822
> in the utf8headers I-D.  That's not good enough for some darker corners
> of MIME like UTF-8 in comments in Content-* header fields or preambles.
>
> The utf8headers I-D must explain why a new message subtype (different
> from rfc822) isn't desirable, why using message/rfc822 with UTF-8
> headers won't cause havoc, and how it might affect application/mbox.
>
> The "document plan" should note this - a separate draft for MIME issues
> (separated from the utf8headers I-D) would be too confusing.
>
> Frank
>
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 05:45:46 -0800

This issue is assigned #1389.

 From reading the discussion, I conclude:

- The word "bounce" is clearly not understood in only one way within the 
community. So if the editor wishes to continue to use the word, rather 
than a construct like "reject or send an NDN", a definition needs to be 
added to the document.
- There is no consensus in this WG about whether or not the SMTP model 
should be changed from "send an NDN if you have to drop a message" to 
"reject the message if you're not sure you can deliver it". Fortunately, 
that is also a question that is not on the charter of this WG, and is 
thus offtopic for this mailing list.

I suggest that the resolution to this issue will involve language in the 
framework document saying that the decision to send an NDN, reject, or 
drop the message when an UTF8SMTP problem is encountered should be done 
consistently with the policies in force for normal SMTP traffic 
(whatever those are).

Makes sense?

                         Harald

Frank Ellermann wrote:
> s/bounce/reject/g   A "bounce" is commonly understood as sending spam
> (unsolicited NDRs) to innocent bystanders as part of a DDoS.
>
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 05:55:34 -0800

(technical contributor hat)

In the RFC series, the first occurences of MDA as an acronym in a mail 
context appear to be in RFC 4406 (Sender ID), 4417 (IAB Messaging 
workshop), and 4496 (OPES use cases).

We might be best served by avoiding the term altogether.

               Harald

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 01 Nov 2006 14:05:37 +0000

> We might be best served by avoiding the term altogether.

(The MDA acronym is frequently used in Sieve WG.)
My personaly preference would be to ask Dave Crocker to publish 
draft-crocker-email-arch-05.txt as RFC and change the framework document 
to reference it.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 06:11:28 -0800

This issue is assigned #1391.

(chair hat on)
I think discussion shows that "final delivery MTA" needs a definition in 
section 1.3, but not much more needs to be changed; once that definition 
is clear, the text is too.

Makes sense?

                  Harald

Frank Ellermann wrote:
> A "delivery to the final delivery MTA" is confusing, should that be
> a "delivery by the final delivery MTA", or a "forward to the" MDA ?
>
> Maybe replace "or after delivery to the final delivery MTA" by
> "or at final delivery by the MDA" (acronym introduced in section 3).
>
> Frank
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 09:30:03 -0500

--On Wednesday, 01 November, 2006 05:45 -0800 Harald Alvestrand
<[email-masked]> wrote:

> - The word "bounce" is clearly not understood in only one way
> within the community. So if the editor wishes to continue to
> use the word, rather than a construct like "reject or send an
> NDN", a definition needs to be added to the document.

Done.  Tentative language follows; tuning welcome:

	<t>As specified in RFC 2821, a message that is
	undeliverable for some reason is expected to result in
	notification to the sender.  This can occur in either of
	two ways. One involves "rejection" by an SMTP server that
	generates a command response that contains a reply code
	indicating a fatal error (a "5yz" code).  The other
	involves accepting the message during SMTP processing and
	then generating a message to the sender, typically known
	as a "Non-delivery notification" or "NDN".  Current
	practice often favors rejection over NDNs because of the
	reduced likelihood that the generation of NDN themselves
	will be used as a spamming technique.  The latter, NDN,
	case is unavoidable if an intermediate MTA accepts a
	message that is then rejected by the next-hop server.  The
	term "bounce" is used informally below to cover both the
	rejection and NDN cases.</t>

> - There is no consensus in this WG about whether or not the
> SMTP model should be changed from "send an NDN if you have to
> drop a message" to "reject the message if you're not sure you
> can deliver it". Fortunately, that is also a question that is
> not on the charter of this WG, and is thus offtopic for this
> mailing list.
> 
> I suggest that the resolution to this issue will involve
> language in the framework document saying that the decision to
> send an NDN, reject, or drop the message when an UTF8SMTP
> problem is encountered should be done consistently with the
> policies in force for normal SMTP traffic (whatever those are).
> 
> Makes sense?

It does to me.  Is the above text sufficient, or should words be
added that indicate explicitly that policies for UTF8SMTP
messages should be identical to those for all-ASCII messages?

   john

---

From: Kari Hurtta <[email-masked]>
Date: 01 Nov 2006 16:30:17 +0200

> used for passing around UTF8SMTP messages or not.

I think that  message/rfc822 can be used for UTF8SMTP messages when
it is inside on UTF8SMTP environment, but message/rfc822 can not be 
used for encapsulation.

> necessary, send it to me..), detailing one "something else"

Ok. I try put it to website (possibly today or tomorrow.)

> of the discussion on the headers document (and possibly Kari's

/ Kari Hurtta

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 06:39:31 -0800

Resolution:

On scanning id-checklist, no requirement was found for such a section.

The section will be deleted.

Frank Ellermann wrote:
> The complete I-D is about I18N, it doesn't need this redundant section.
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 10:04:33 -0500

--On Wednesday, 01 November, 2006 05:27 -0800 Harald Alvestrand
<[email-masked]> wrote:

> - The most controversial aspect here is whether message/rfc822
> can be used for passing around UTF8SMTP messages or not.
> - There are multiple people who think that doing so is asking
> for trouble, so we should do something else, and one person
> (Charles) who believes that it should be so used.
> - A separate draft, draft-hurtta-eai-encapsulation, has been
> written, but not submitted (kari, can you get it onto a
> website somewhere? If necessary, send it to me..), detailing
> one "something else"
> 
> I believe the needed change to the Framework document is to
> state that the "headers" document also needs to describe the
> interactions between UTF8SMTP messages and MIME, and the
> details need to be tackled as part of the discussion on the
> headers document (and possibly Kari's document).
> 
> Makes sense?

Yes.  Proposed text for Framework, added to section 3, bullet 2:

		This document, possibly with one or more supplemental
		ones, will also need to address the interactions with
		MIME, including relationships between UTF8SMTP and
		internal MIME headers and content types.

Is that adequate?

   john

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Nov 2006 07:24:24 -0800

> 		internal MIME headers and content types.
It seems adequate to me.

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 10:14:03 -0500

--On Wednesday, 01 November, 2006 12:44 +0100 Frank Ellermann
<[email-masked]> wrote:

> That's of course unacceptable, it would be handled as net
> abuse, adding the IPs of the MTA sending those bounces later
> (that's not necessarily the same MTA as the backup MX) on
> block lists. After that some valid DSNs won't make it to the
> senders, their mail is lost in a black hole.
> 
> good as possible, rejecting anything that's "unclear" (e.g.
> from alleged "dynamic IPs", or similar black lists).  With
> TempFail or greylisting it can survive on its own for about
> 100 hours.
>...

Frank, 

This is a complex problem and, as has been pointed out, not one
for this WG.  Your insistent efforts to get your view written
into the standard is one reason 2821bis has been permitted to
quietly expire, but that is another issue.  I will tell you that
the notion of requiring the use of black (or grey) lists
supplied by third parties is going to be operationally
unacceptable to many server operators (and probably a
standardization showstopper as a result) unless there are clear
rules governing the behavior of those operators with clear lines
of responsibility and liability for their actions.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 10:48:04 -0500

--On Wednesday, 01 November, 2006 06:11 -0800 Harald Alvestrand
<[email-masked]> wrote:

> I think discussion shows that "final delivery MTA" needs a
> definition in section 1.3, but not much more needs to be
> changed; once that definition is clear, the text is too.
> 
> Makes sense?

Proposed definition (new third paragraph of section 3); tuning
welcome:

		However, the term "final delivery MTA" is used in this
		document in a fashion equivalent to the term "delivery
		system" or "final delivery system" of RFC 2821.  This
		is the SMTP server that controls the format of, and is
		permitted to inspect and interpret, local-part
		addresses.  It receives messages from the network for
		delivery to mailboxes, rather than relaying.  From the
		perspective of the network, any local delivery
		arrangements such as saving to a message store, handoff
		to specific message delivery programs or agents, and
		mechanisms for retrieving messages are all "behind" the
		final delivery MTA and hence not part of the SMTP
		transport or delivery process.

john

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 11:02:12 -0500

> The section will be deleted.

Done
    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 11:10:32 -0500

--On Wednesday, 01 November, 2006 12:23 +0000 Alexey Melnikov
<[email-masked]> wrote:

>> Not in the charter.  In other words, one thing at a time.  If
>> we can get this right for SMTP and then move toward
>> standards-track specs, certainly an LMTP upgrade should be
>> part of that effort.
>>  
>> 
> This is a one line change to LMTP, IMHO: "The same SMTP
> extension can also be used with LMTP".
> 

This, or something a little stronger, is IMO exactly right for a
standards-track document that updates both SMTP and LMTP.

>> techniques.  Do you think Sieve should be explicitly
>> referenced as an example and, if so, should the reference be
>> to 3028 or to something else?
>>  
> I don't think there is any need, but an informative reference
> to RFC 3028 would be fine with me.
> (IETF LC for 3028bis just ended, but it doesn't really matter
> which one is referenced)

Reference to 3028 inserted.  Please keep an eye on this -- if
3028bis is published before this doc, we should update it on
principle.

   john

---

From: Kari Hurtta <[email-masked]>
Date: 01 Nov 2006 19:06:57 +0200

> necessary, send it to me..), detailing one "something else"

See:

   <URL: http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.txt >
   <URL: http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.xml >

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Nov 2006 19:49:26 +0100

John C Klensin wrote:

>> I agree completely with our description of a backup MX

s/our/your/ - I hope that typo was obvious.

> This is a complex problem and, as has been pointed out,
> not one for this WG.

Only the terminology, "reject" vs. "bounce", is relevant.

Some say that the terms like "reverse path", "MAIL FROM",
"return-path", "envelope sender", etc. were always wrong,
and it should have been "bounces-to".  They say STD 10 is
or rather was wrong.

Others say these terms mean what they say, and that's no
bug.  Folks who had the misfortune to be hit by thousands
of "misdirected bounces" tend to think that that's wrong.

> Your insistent efforts to get your view written into the
> standard is one reason 2821bis has been permitted to
> quietly expire, but that is another issue.

I don't agree that it's only my personal view.  And nobody
could force you to write something into a draft-klensin-*
that you don't like.  I was perfectly happy with your plan
to get it in a shape with all listed and unlisted errata
fixed, and then start a WG taking that state as its input.

Compare <http://permalink.gmane.org/gmane.ietf.smtp/4832>,
you proposed to get rid of the term "bounce" in 2821bis-01

Reading some of those old mails, it wasn't me who started
that old (2005) "reject vs. bounce" thread.  And at that
time you wrote that you don't want to publish a -01 draft
before an 2822bis-00 is ready.  That was your decision, and
all I contributed to that line of reasoning was that I'm
not exactly interested in a 2822bis before USEFOR is ready
(at the moment it's ready but not yet approved).

> unacceptable to many server operators

They can use their own black lists.  "Greylisting" is a
local technique (unrelated to DNSBLs), for a definition see
<http://www.greylisting.org/>

And yes, I tried to get draft-irtf-asrg-dnsbl-02 published,
but it's trapped in some procedural limbo about IRTF RFCs -
or rather that's the last state I know (early 2006).

Nobody (or at least not me) would expect that a new 2821bis
would *_require_* specific wild and wonderful things like
"greylisting", DNSBLs, 4408, call forward, and what else.

I think you need a better reason than "Frank doesn't like
misdirected bounces" for the 2821bis issue,  I forwarded the
announcement of 2821bis-00 to at least four groups (RFCI, SC,
SPF, dan-am) as the most interesting IETF event for years.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Nov 2006 20:56:35 +0100

John C Klensin wrote:

>| However, the term "final delivery MTA" is used in this
>| document in a fashion equivalent to the term "delivery
>| system" or "final delivery system" of RFC 2821.  This
>| is the SMTP server that controls the format of, and is
>| permitted to inspect and interpret, local-part addresses.
>| It receives messages from the network for delivery to
>| mailboxes, rather than relaying.

Is that really the same as "A relay SMTP server is usually
the target of a DNS MX record that designates it, rather
than the final delivery system." ?  (2821 3.7)

There are only two "delivery system" in 2821.  2821 2.3.3
says: ''the final ("delivery") MTA would be thought of as
handing the mail off to an MUA (or at least transferring
responsibility to it, e.g., by depositing the message in a
"message store").''

What you describe above is apparently an MX or anything
behind an MX, or in other words a "mail receiving network".
Any MTA in the MRN can interpret local parts, e.g. replace
BATV local parts by the real local part, or do something
with "!" or "%" we don't need to discuss here.

The STD 10 definition is "final delivery" = "leaves SMTP",
and 2821 4.4 uses the same words:  "Here, final delivery
means the message has left the SMTP environment."

Apparently you don't like ''(sometimes called "MDA")'' in
chapter 3 of the framework draft, a simple fix would be to
remove it, the term MDA isn't used elsewhere.

And in chapter 5 "after delivery to the final delivery
MTA" just sounds odd, maybe "after acceptance by the final
delivery MTA" or "after forwarding to" is the same idea.

Frank 
-- 
 Found in <http://article.gmane.org/gmane.ietf.smtp/4754>:
| that patchwork effort, unsurprisingly, didn't result in
| completely consistent terminology.   As far as I'm
| concerned, 2821bis is our opportunity to smooth out
| whatever rough edges, especially those of terminology,
| that people can identify and think are work fixing.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Nov 2006 21:26:17 +0100

Harald Alvestrand wrote:

 [MDA] 
> We might be best served by avoiding the term altogether.

+1 (the email-arch-05 4.3.3 definition is of course fine)

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 15:42:34 -0500

> Only the terminology, "reject" vs. "bounce", is relevant.

The text has been clarified.  See previous note.

> of "misdirected bounces" tend to think that that's wrong.

Having been hit by thousands of such bounces in one capacity or
another, I continue to believe those terms mean what they say.

> fixed, and then start a WG taking that state as its input.

I didn't claim that it was only your personal view.  I claimed
(and claim) only that the amount of noise about changed
requirements and changed definitions caused me to reach the
point that I concluded I had more useful things to do with my
time.

> you proposed to get rid of the term "bounce" in 2821bis-01

Indeed.  And it was, if I recall, removed from the working
draft... before I gave up.

> that old (2005) "reject vs. bounce" thread.

That is correct, and I didn't mean to imply otherwise... only
that introducing it into yet another context is not helpful.

>  And at that

As you presumably know, 2822bis has been posted.  I don't know
what the plans are for processing it if any exist.

> SPF, dan-am) as the most interesting IETF event for years.

Again, I didn't mean to imply "Frank doesn't like it" or "Frank
is unhappy" was the issue.  The issue was the balance between
trying to deal with several proposals (from several people) that
seemed to have the tone of "unless these protocol changes are
made, 2821bis is just not worth the effort" and other ways to
spend my, and, to the extent to which I'm entitled to an
opinion, the IETF's, time.

Put differently, it is my personal opinion that there is no way
to advance either 2821bis or 2822bis without a fairly strong
community consensus that those documents will represent
clarifications and corrections to errors only.  If it is
necessary to have discussions about desired changes in
practices, or even about whether particular changes have already
occurred, then an update is fairly hopeless, at least given my
impression of the level of energy people are willing to invest.

   john

    john

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Nov 2006 21:49:41 +0100

John C Klensin wrote:

> Is the above text sufficient

It's good, but there are only four "bounce" in the document, and you can
replace them all without an extra definition:

- *  Bounce the message so that the sender can make another plan.
+ *  Reject or return the message so that the sender can make another
plan.

- available to reliably downgrade it, it MUST be bounced.
+ available to reliably downgrade it, it MUST be returned.

- o  Reject or bounce the message, requiring the sender to resubmit it
+ o  Reject or return the message, requiring the sender to resubmit it

= The first of these two options, that of rejecting or returning the

- the internationalized form of the message is rejected or bounced by
+ the internationalized form of the message is rejected or returned by

The "=" line meaning "as is", with that modification you can get rid
of the last statement in your proposed text:

- The term "bounce" is used informally below to cover both the rejection
- and NDN cases.</t>
+ </t>

If "bounce" is defined to be "reject or return" the existing "reject or
bounce" part would be strange.  The "MUST be bounced" (or returned) is
no EAI-specific MUSTard, it's a 2821-MUST, maybe add the source (= 3.7,
the famous "as indicated by the reverse-path" MUSTard).

Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 16:32:21 -0500

--On Wednesday, 01 November, 2006 21:49 +0100 Frank Ellermann
<[email-masked]> wrote:

> It's good, but there are only four "bounce" in the document,
> and you can replace them all without an extra definition:
> 
> - *  Bounce the message so that the sender can make another
> plan. + *  Reject or return the message so that the sender can
> make another plan.

Still have to carefully define "reject" and "return".  And
"return" is going to imply full text and attachments to many
people, which is definitely not a current requirement (and the
notification request machinery purports to control this). 

> + available to reliably downgrade it, it MUST be returned.

As I pointed out to Kari, while it would be unusual, there is
always a chance of arranging things so that they can be rejected.

I'll look at the rest of these.
Harald and XiaoDong??  Instructions?

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 01 Nov 2006 22:35:46 -0000

> it is inside on UTF8SMTP environment, but message/rfc822 can not be

Yes, that is exactly my view, so that makes two of us.

For encapsulation, we need something else, and it is likely to be somewhat  
ugly. But let us see your draft.

My view is that we don't need encapsulation (i.e. we haven't found a  
pressing need for it yet). Therefore, we should leave that issue alone  
until a pressing need rears its igly head. I think that was John's view  
too.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 01 Nov 2006 22:42:37 -0000

> 	rejection and NDN cases.</t>

I think I would prefer to use the word "bounce" for what you call NDN (and  
define it clearly so), and to use "reject" for when a 5xx response (or  
occasionaly a 4xx) is sent. And then to ensure all drafts follow that  
convention (that process of ensuring already seems to be under way).

My belief is that that is how "bounce" is usually understood "out there",  
and that the term "NDN" would not be so easily recognised if used in its  
place.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 01 Nov 2006 22:51:57 -0000

> 		transport or delivery process.

In addition to message store, handoff to POP3/IMAP, etc., there is also  
the case of "forward to another address" (whether as part of a mailing  
list expansion or not, and whether with some change to the message or not.

At that point (and especially where the is no change) it is back in the  
SMTP world, and becomes again subject to rejection, bouncing or  
downgrading, and finally arrives at yet another "final delivery MTA". I  
think your wording needs to include this case. In particular, it SHOULD  
NOT normally be upgraded at this point (that privilege should be reserved  
for the final final delivery MTA).

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Nov 2006 18:32:52 -0500

--On Wednesday, 01 November, 2006 22:51 +0000 Charles Lindsey
<[email-masked]> wrote:

> In addition to message store, handoff to POP3/IMAP, etc.,
> there is alsothe case of "forward to another address" (whether
> as part of a mailinglist expansion or not, and whether with
> some change to the message or not.
> 
> At that point (and especially where the is no change) it is
> back in theSMTP world, and becomes again subject to rejection,
> bouncing ordowngrading, and finally arrives at yet another
> "final delivery MTA". Ithink your wording needs to include
> this case. In particular, it SHOULDNOT normally be upgraded at
> this point (that privilege should be reservedfor the final
> final delivery MTA).

Charles, it is up to the WG as to where to draw the line, but
I'm personally reluctant to reprise the model structure --
either of 2821 or of the document Dave Crocker is working on --
in the framework doc.  Doing so would make the document longer,
encourage people to believe that they don't really need to
understand SMTP to understand this work, and introduce
dependencies that are probably best avoided.

It may be that some of the issues you raise should be addressed
in the downgrade or mailing list documents, but my personal
opinion is that we should keep "framework" away from
post-delivery analyses.

Again, just my personal opinion.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Nov 2006 01:07:56 +0100

> another, I continue to believe those terms mean what they say.

The "wrong" was about the "some" (e.g. Dave), not about the
"others" - it's good to hear that you're one of the "others".

> the amount of noise about changed requirements and changed 
> definitions caused me to reach the point that I concluded
> I had more useful things to do with my time.

I'd love to replace the 1123 5.3.6(a) "feature" more quietly.
Some good RFCs like 3834 depend on no-nonsense Return-Paths.

Unfortunately I found nobody interested to extract at least
the historical parts from 2821 (anything with source routes
+ SOML/SAML/SEND FROM cruft), in the hope that the rest might
be just manageable for a 2821bis.

> As you presumably know, 2822bis has been posted.

No, I missed that, I didn't look into anything IETF for some
weeks (April to July) after the IAB decision and 4408 AUTH48
for various reasons including a trailing dot - I found the 
SMTP-list thread where Ned convinced you to remove it again
from your 2821bis draft much later.

> I don't know what the plans are for processing it if any
> exist.

Apparently it's discussed "nowhere" (= not on any list I'm
aware of, and googlebot claims also nowhere else), strange.
If you say 2821bis was too noisy then the opposite isn't
necessarily better.  Maybe Bruce and others also missed it.

> it is my personal opinion that there is no way to advance
> either 2821bis or 2822bis without a fairly strong community
> consensus that those documents will represent clarifications
> and corrections to errors only.

2822 is fairly clear, either you like NO-WS-CTL, or you don't
like it, it can be fixed or kept as is, plus similar details.

The most exciting point could be "do we really want Resent-*
as specified, or can we please deprecate it ?"  Or in theory
"fix" it to be compatible with 4406.  Or if all fails update
4409 8.1, that's at least in a kind of "text proposed" state.

2821 on the other hand is a hard case.  It's long.  Everybody
has his or her favourite way to read it.  Splitting it into
smaller pieces might help.  E.g. it should be possible to get
a consensus for a clean ABNF.  

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 02 Nov 2006 08:03:55 +0200

> necessary, send it to me..), detailing one "something else"

First thing where these are needed are non delivery reports
ie. multipart/report.

Normally there is
     multipart/report
        text/plain
        message/delivery-status
        text/rfc822-headers

or

     multipart/report
        text/plain
        message/delivery-status
        message/rfc822

Either  text/rfc822-headers and message/rfc822 specification need
to be changed or these types need to be replaced with some other types.

draft-hurtta-eai-encapsulation-00  gives types

  text/rfc822-headers =>  text/utf8-header

  message/rfc822      => multipart/multipart/utf8-encapsulated; type=message

although these types was not proposed for multipart/report

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Nov 2006 09:19:17 +0100

Kari Hurtta wrote:

> http://www.elmme-mailer.org/ID/draft-hurtta-eai-encapsulation-00.txt

Thanks, I'm not ready with reading it, a first impression:

A mail with UTF-8 headers can be a mixture of "raw" UTF-8
+ MIME-encoding like 2047.  When it's downgraded some
UTF-8 headers end up 2047-encoded.  When it's upgraded
it will be again a mixture, but potentially a _different_
mixture, of UTF-8 and MIME-magic.

"Different" could cause havoc for signatures.  But with
encapsulation it's reconstructed as it was before the
downgrade.  Is that on track, one of the problems you
try to solve ?

The text/utf8-header for a multipart/report is clear.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 02 Nov 2006 10:50:51 +0200

> downgrade.  Is that on track, one of the problems you

Yes.

Another one was trying to not invoke signature checking when
message is downgraded.

There was also some other usages.

/ Kari Hurtta

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 02 Nov 2006 01:47:13 -0800

I think Frank has a point that you don't need the term "bounce", and 
it's easier to remove it than to define it (especially as that was 
already done in the 2821bis work).

I don't like "it must be returned" either, "an error report must be 
returned" is more correct (the error report may or may not include the 
whole message). If you want to define a term for "return an error 
report", that's OK with me.

Unless I hear shouts from the WG, you can take that as chair's guidance.

                         Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 02 Nov 2006 11:26:25 -0000

> dependencies that are probably best avoided.

I think the only point that needs to be made is that the "final delivery  
agent" as you have defined it may not be as "final" as it sounds, insofar  
as there may yet be a "final final delivery agent" (or even final**n).  
What I have in mind is simple forwarding by some /etc/aliases or ,forward  
file, rather than a full-fledged list expander.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Nov 2006 14:06:03 +0000

>to be changed or these types need to be replaced with some other types.
Correct.

Note that message/delivery-status has to be updated as well to allow for 
UTF-8.

Chris Newman and I are planning to discuss issues related to DSN reports 
next week.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 02 Nov 2006 06:31:32 -0800

Charles Lindsey wrote:
> In addition to message store, handoff to POP3/IMAP, etc., there is 
> also the case of "forward to another address" (whether as part of a 
> mailing list expansion or not, and whether with some change to the 
> message or not.
>
> At that point (and especially where the is no change) it is back in 
> the SMTP world, and becomes again subject to rejection, bouncing or 
> downgrading, and finally arrives at yet another "final delivery MTA". 
> I think your wording needs to include this case. In particular, it 
> SHOULD NOT normally be upgraded at this point (that privilege should 
> be reserved for the final final delivery MTA). 
If it is part of alias expansion (no change to envelope sender), the MTA 
is not final.
If it is part of mailing list expansion (change to envelope sender), the 
MTA is final.

The fact that it's hard to tell from a Sendmail aliases file which one 
is taking place is a Sendmail problem, not a problem with the Internet 
mail architecture.

                     Harald

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Nov 2006 16:27:06 +0100

> file, rather than a full-fledged list expander.

Yes, that's discussed in 2821 4.4, bottom of page 50, "it is sometimes
difficult" etc.  And at the begin, the abstractions like "final delivery
MTA" can depend on the circumstances (2.2.3), "However, while these terms
are used with the appearance of great precision" etc.

Is there something special wrt EAI ?  Kari's proposal that we might need
some ESMTP keyword for the MAIL FROM is interesting:

 EHLO i18n.client.example
 MAIL FROM:<[email-masked]> ALT-ADDRESS=[email-masked]
 RCPT TO:<[email-masked]>
 RCPT TO:<[email-masked]>

That's obvious, no extra keyword needed, the server can simply reject all
RCPT TO addresses where it knows that it can't downgrade for some reason.

Without optional ALT-ADDRESS it's not obvious, the server doesn't know if
it should reject the message to "un-downgradable" receivers:

 EHLO i18n.client.example
 MAIL FROM:<[email-masked]>
 RCPT TO:<[email-masked]>
 RCPT TO:<[email-masked]>
 DATA
 Header-Type: UTF8
[...]

In theory it could look "into" the mail, "see" the Header-Type: UTF8, and
say "thanks, but no thanks" after DATA for all recipients if some of them
are "un-downgradable".  But it should better get a clue before DATA in the
MAIL FROM, then it can reject RCPT TO selectively.

For an UTF-8 MAIL FROM:<äöü.üöä.example> that's overkill, the server
would "see" that this is not US-ASCII.  But for an ASCII MAIL FROM waiting
until DATA with "Header-Type: UTF8" is too late for selective rejects.

Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 02 Nov 2006 17:22:20 +0900

In this context, I'd like to reiterate my proposal for
making non-delivery reports standardized enough that
a MUA could automatically resend (or, as much as possible,
help the user to resend) a mail with fallback
addresses if it got stuck somewhere.

So the scenario would be:
Mail with UTF-8 address sent ->
passes some SMTP servers ->
hits an SMTP server that doesn't downgrade, but sends
    back a non-delivery report ->
report gets back, ultimately to MUA ->
MUA analyses, finds out that the report indeed is for a
   mail it sent (one has to be careful these days because of
   all the spam around) and that it's because of the UTF-8 address ->
mailer prepares the mail again, this time with the alt address ->
mail is sent again

I'm not sure whether or not this is already possible, but it
sure would help MUAs and probably also the adoption of UTF8SMTP
(an error that has an easy solution is much less of an obstacle
than an error without obvious solution for a non-expert user).

Regards,    Martin.

>although these types was not proposed for multipart/report

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Nov 2006 12:33:22 -0500

--On Thursday, 02 November, 2006 01:47 -0800 Harald Alvestrand
<[email-masked]> wrote:

> I think Frank has a point that you don't need the term
> "bounce", and it's easier to remove it than to define it
> (especially as that was already done in the 2821bis work).
> 
> I don't like "it must be returned" either, "an error report
> must be returned" is more correct (the error report may or may
> not include the whole message). If you want to define a term
> for "return an error report", that's OK with me.
> 

Since there were no shouts (other than from me), the term
"bounce" has been removed.    I have generally avoided "error
report" in favor of phrases such as "generate and return a
non-delivery message", which is consistent with the language of
821.  The WG will need to determine whether the style of those
comments is consistent and clear enough after seeing -03.

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Nov 2006 12:35:35 -0500

--On Thursday, 02 November, 2006 06:31 -0800 Harald Alvestrand
<[email-masked]> wrote:

>>> Proposed definition (new third paragraph of section 3);
>>> tuning welcome:
>>> 
>>>         However, the term "final delivery MTA" is used in
>>>         this document in a fashion equivalent to the term
>>>         "delivery system" or "final delivery system" of RFC
>>>         2821.  This is the SMTP server that controls the
>>>         format of, and is permitted to inspect and
>>>         interpret, local-part addresses.  It receives
>>>         messages from the network for delivery to mailboxes,
>>>         rather than relaying.  From the perspective of the
>>>         network, any local delivery arrangements such as
>>>         saving to a message store, handoff to specific
>>>         message delivery programs or agents, and mechanisms
>>>         for retrieving messages are all "behind" the final
>>>         delivery MTA and hence not part of the SMTP
>> there is  also the case of "forward to another address"
>> (whether as part of a  mailing list expansion or not, and
>> whether with some change to the  message or not.
>> 
>> back in  the SMTP world, and becomes again subject to
>> rejection, bouncing or  downgrading, and finally arrives at
>> yet another "final delivery MTA".  I think your wording needs
>> to include this case. In particular, it  SHOULD NOT normally
>> be upgraded at this point (that privilege should  be reserved
 
> If it is part of alias expansion (no change to envelope
> sender), the MTA is not final.
> If it is part of mailing list expansion (change to envelope
> sender), the MTA is final.
> 
> The fact that it's hard to tell from a Sendmail aliases file
> which one is taking place is a Sendmail problem, not a problem
> with the Internet mail architecture.

Agreed.  Unless I hear instructions to the contrary, I'm taking
this as "no additional textual change needed".

    johnb

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Nov 2006 13:03:46 -0500

--On Thursday, 02 November, 2006 17:22 +0900 Martin Duerst
<[email-masked]> wrote:

>    all the spam around) and that it's because of the UTF-8
> address -> mailer prepares the mail again, this time with the
> alt address -> mail is sent again
> 

Martin,

First, I think this would be a wonderful idea, and for far more
reasons than the i18nemail work.   The reasons for it are very
old, e.g., the thing that caused the idea of an error reply of
"user address changed, new address is..." to never work in a
reasonable fashion was that it fell apart in relay environments.

And, as you suggest, being able to get a reliable message all
the way back to a sending MUA (or sending submission server)
with instructions that it sort downgrade issues out would vastly
simplify our work.

However...

(1) It is not in our charter.

(2) Attempts to standardize things that much have met with slow
adoption and sometimes active resistance.  We've still got a
number of mail systems out there that do not support the NDN
formats that have been established for years (over a decade now
if one counts from RFC 1894).

(3) Given the current spam and malware environment, one would
have to address the question of the authenticity of such a
message with some care.  That question opens all of the PKI and
related cans of worms.   One would also have to figure out
whether an authentic error reply message in response to an
incoming message that could not be authenticated would be a good
idea.  I don't think it would make things any worse, but haven't
thought it through.

I suppose one could specify things so that any host that offered
the UTF8SMTP extension would be required to support a specific
NDN format for error messages, but I'd suspect that, in
practice, it would really slow down deployment of key features.

So, sadly, I don't see a practical way to do this.

Just my opinion.

    john

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 03 Nov 2006 23:09:39 -0000

On Thu, 02 Nov 2006 14:31:32 -0000, Harald Alvestrand  
<[email-masked]> wrote:

>> NOT normally be upgraded at this point (that privilege should be  
>> reserved for the final final delivery MTA).

> If it is part of alias expansion (no change to envelope sender), the MTA  

Exactly so. But the alias expansion cannot take place without looking at  
the <local-part>, and as John frequently points out to us, MTAs that are  
not "final delivery MTA"s are not supposed to look inside the <local-part>.

This is not a technical problem - rather a possible confusion of  
terminology. But it is worse in the case of UTF8SMTP because "looking at  
the <local-part>" may require a little upgrading first (but not of the  
rest of the message, because it may yet meet another non-UTF8SMTP MTA on  
its further travels).

That is why I think John needs to say something about this in his  
framework, just to make sure that nobody gets confused.

> If it is part of mailing list expansion (change to envelope sender), the  

Yes, in that case it is definitely a new message that is being constructed  
(usually) so the expander is definitely final (finally so).

---

From: Randall Gellens <[email-masked]>
Date: Fri, 3 Nov 2006 15:33:11 -0800

At 10:56 AM +0000 10/31/06, Charles Lindsey wrote:

>  So I think the most we can do is draw attention to these problems 
> under Security Considerations, in which case count me as +1 for (2).

+1
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
[P]olitics, as a practice, whatever its professions, has always been
the systematic organization of hatreds.
                                    --American historian Henry Adams

---

From: Randall Gellens <[email-masked]>
Date: Fri, 3 Nov 2006 15:53:49 -0800

At 12:44 PM +0100 11/1/06, Frank Ellermann wrote:

>  like "reject" instead of "bounce" where applicable.

I'm not sure "reject" is a neutral term, any more than "bounce".  One 
implies returning a error code during an SMTP transaction, the other 
sending a DSN.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If the code and the comments disagree, then both are probably wrong.
        --Norm Schryer

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 04 Nov 2006 04:31:14 +0100

> implies returning a error code during an SMTP transaction, the other

Yes, that's the (or a) common definition for the latter, but not the
2821-concept:

| Delivery SMTP systems MAY reject ("bounce") such messages rather than
| deliver them.

"Reject" is a very sound action from a sender's POV, at least the mail
didn't vanish in some black hole, and "the sender can make another plan",
as the framework draft put it.

With a "bounce" (your DSN-definition, not the 2821-reject-alias) on the
other hand the first question of innocent bystanders hit by it will be
"why on earth did they accept it, if they can't deliver it ?"

210,000 Google hits for "misdirected bounce", probably all talking about
unsolicited DSNs, a "misdirected reject" would be quite a stunt with SMTP.

A "cannot downgrade reject" is a bit like a "551 user not local".  Do we
need a kind of "251 attempting downgrade" reply ?

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 05 Nov 2006 00:08:39 +0100

Charles Lindsey wrote:
>
> Exactly so. But the alias expansion cannot take place without looking 
> at the <local-part>, and as John frequently points out to us, MTAs 
> that are not "final delivery MTA"s are not supposed to look inside the 
> <local-part>.
>
> terminology. But it is worse in the case of UTF8SMTP because "looking 
> at the <local-part>" may require a little upgrading first (but not of 
> the rest of the message, because it may yet meet another non-UTF8SMTP 
> MTA on its further travels). 
Charles,

PLEASE respect the decision of the WG to:
- abandon ATOMIC
- require use of ALT-ADDR for downgrading

Together, these two decisions mean that the idea of "upgrading" an 
address before an MTA takes action on it is totally, utterly, completely 
and unconditionally meaningless. There is no information in the 
local-part of the RCPT TO parameter that can be "upgraded".

                       Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 06 Nov 2006 10:51:20 -0000

> implies returning a error code during an SMTP transaction, the other  

We seem to have settled on "reject" and "return" as the two critical  
words. "Return" is fine, because it uses the correspondingly named  
"Return-Path".

But I just wonder whether "refuse" might be a better term than "reject"  
for giving a 5xx response, since it conveys the idea of something that is  
more "immediate".

---

From: "Yao Jiankang" <[email-masked]>
Date: Tue, 7 Nov 2006 21:20:56 +0800

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 04, 2006 11:31 AM
Subject: Re: [EAI] ISSUE: framework 4.1 - reject

> need a kind of "251 attempting downgrade" reply ?

the code "2**" normally means success. "251 attempting downgrade"  means
success to downgrade or failure to UTF8SMTP?
so "251 attempting downgrade" seems to have a little confused.

Yao Jiankang
CNNIC

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Nov 2006 19:23:18 +0100

Yao Jiankang wrote:

> the code "2**" normally means success. "251 attempting downgrade"
> means success to downgrade or failure to UTF8SMTP?

Yes, I try to explain it better.  Let's say [email-masked] has
a new address [email-masked], and the admin of there.example
agrees to forward mails to the new address - if the admin doesn't
want this he could still arrange a 551 reject.

So when you send mail to the old address [email-masked] one of
the SMTP servers at there.example accepts it with a...

251 user not local; will forward to <[email-masked]>

...so far it's a success, queued for forwarding.  That can take a
while and fail, and for you as sender it might be faster / better
to send further mails directly to [email-masked]

With downgrading it's a similar situation, for you as sender it
might be better / faster if you send further mails directly to
the alt-address in the traditional format (no utf8headers etc.),
because whatever the downgrading attempts to do, it could cause
havoc for your mails (destroyed DKIM signature or similar).

With a 251 the server could indicate that it tries its best, but
maybe you prefer to send your UTF-8 text as ZIP-attachement of
traditional mail in this situation, because you're not really
interested to find out what "some server trying its best" means.

Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Nov 2006 13:22:21 -0800

John C Klensin wrote:

>--On Monday, 30 October, 2006 20:03 +0000 Alexey Melnikov
>>Some minor comments:
>> >4.1.  SMTP Extension for Internationalized eMail Address
>> [...]
>> >   Some general principles apply to this work.
>> >
>> >   1.  Whatever encoding is used should apply to the whole
>> >       address and
>> >       be directly compatible with software used at the user
>> >       interface.
>>
>>Why? Can it be applied to LHS and RHS separately?
>>    
>>
>This was an attempt to explain, in short form, why it would not
>be reasonable to, e.g., require that the local part be in UTF-8
>while the domain part was in punycode.   If you can think of
>better wording, or think it needs to be made more explicit,
>please send text.  
>
Is the following any better:

  Whatever encoding is used should be applied to both the left hand side and the right hand side 
  of an address and be directly compatible with software used at the user interface.

?

(or change "left hand side" to "local" and "right hand side" to "domain")

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Nov 2006 17:59:51 -0500

Yes.  Done.
    john

--On Thursday, November 09, 2006 13:22 -0800 Alexey Melnikov 
<[email-masked]> wrote:

>> This was an attempt to explain, in short form, why it would
>> not be reasonable to, e.g., require that the local part be in
>> UTF-8 while the domain part was in punycode.   If you can
>> think of better wording, or think it needs to be made more
>> explicit, please send text.
>>
>   Whatever encoding is used should be applied to both the left
> hand side and the right hand side   of an address and be
> directly compatible with software used at the user interface.
>
> ?
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Nov 2006 17:55:12 -0000

On Sat, 04 Nov 2006 23:08:39 -0000, Harald Alvestrand
<[email-masked]> wrote:

>> at the <local-part>, and as John frequently points out to us, MTAs that  
>> are not "final delivery MTA"s are not supposed to look inside the  
>> <local-part>.
>>
Sure, I have accepted that. I had just not spotted that all possibility of
needing to upgrade a <local-part> had finally evaporated. But there is
still a problem even if the <local-part> is not involved in upgrading.

Earlier in this thread, you said:

If it is part of alias expansion (no change to envelope sender), the MTA is
not final.
If it is part of mailing list expansion (change to envelope sender), the
MTA
is final.

So consider the case where a message is forwarded through a series of MTAs
(by alias expansion using .forward files/whatever) before it finally
catches up with the final recipient. Various 'ordinary' MTAs too, any of
which might need to 'downgrade' from UTF8SMTP.

     MSA->MTA->MTA->aliasingMTA->MTA->aliasingMTA->MTA->finalMTA->MDA

So according to your definition, the ones marked 'aliasing MTA' are not
'final' - just the very last one. Hence there can only be one "final" one
in the chain.

But that is not what John's latest text in draft-03 says:

     [[anchor3: WGLC, Framework 5, Issue #1391]] However, the term "final
     delivery MTA" is used in this document in a fashion equivalent to the
     term "delivery system" or "final delivery system" of RFC 2821.  This
     is the SMTP server that controls the format of, and is permitted to
     inspect and interpret, local-part addresses.  It receives messages
     from the network for delivery to mailboxes or other local processing,
     rather than relaying.  From the perspective of the network, any local
     delivery arrangements such as saving to a message store, handoff to
     specific message delivery programs or agents, and mechanisms for
     retrieving messages are all "behind" the final delivery MTA and hence
     not part of the SMTP transport or delivery process.

For it states explicitly that only the "final delivery MTA" is "is
permitted to inspect and interpret, local-part addresses". But clearly the
ones that do the intermediate aliasing also need to "inspect and
interpret" the <local-part>.

So the wording is still inconsistent. It might be fixed in one of thwo
ways. My preference would be to consider each aliasingMTAs as "final", and
then to mention "forwarding" or "aliasing" as one of the things that might
come under "local delivery".