Subject: Re: [EAI] ATOMIC parameter

From: "Yao Jiankang" <[email-masked]>
Date: Tue, 21 Mar 2006 00:28:31 +0800

what you suggest is that "atmonic=no" is kept for use and "atmonic=yes" is
removed.

you mean that although atmonic value is not set, the default is "atmonic=y".
only in the situation where the utf-8 email address can not be safely
transformed to ACE, the atmonic value is set.

is my understanding right?

Yao Jiankang
CNNIC

----- Original Message ----- 
From: "Chris Newman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 20, 2006 4:22 PM
Subject: [EAI] ATOMIC parameter

> Although I'm sympathetic to the motivations behind the ATOMIC parameter, I
> believe it is an incorrect bias of protocol purity over operational
robustness.
>
> As a matter of operational robustness it is almost always better to move
> questionable email material forward than to bounce it.  If the recipient
gets
> something that appears to be corrupt, they will contact the sender to
resend
> the material.  If the message is important, the recipient will probably
have
> out-of-band mechanisms to contact the sender that are more likely to work
than
> the MAIL FROM address (e.g. a cell phone number, etc).
>
> On the flip side, it is quite easy to mis-configure the MAIL FROM address
and
> the problem probably won't be noticed unless the person who did so gets a
> complaint from a colleague which will only happen if the message moves
forward
> and the  colleague's attempt to reply fails.  We also have widely deployed
> systems that do inappropriate things with MAIL FROM that can cause loops
or
> other badness when a bounce happens.  And in the new world of Spam
blowback,
> many people simply ignore almost all bounces (myself included,
unfortunately).
>
> This is very unfortunate for those of us who care a great deal about
protocol
> purity.  It's really painful to pass non-interoperable junk forward but
the
> outcome for the users involved is more likely to be better, so it's
usually the
> right thing to do.
>
> Which brings us to the ATOMIC parameter.  We all like the rule which
forbids
> local part interpretation by remote systems and I respect the ATOMIC
parameter
> approach as a clever way to preserve that rule.  Unfortunately, ATOMIC=no
> leaves MTAs in an untenable situation: either ignore the standard,
downconvert
> and pass forward or bounce.  Unfortunately, robustness suggests the right
> answer is to ignore the standard.  Were I implementing a system, I'd
probably
> ignore the standard for this case by default and include an option to
follow
> the standard.  But having "do the right thing for users" and "comply with
the
> standard" as two separate settings is not something I like (how often do
people
> use the "strict ANSI" option on their C compiler?).
>
> Use of a UTF-8 local part should implicitly grant permission to use the
> 7-bit-encoded alias of that local part.  This is not significantly
different
> from the rule that [email-masked] implies the existence of
> [email-masked] and the converse is true.  Furthermore, if
> someone wants to use structured UTF-8 addresses for special processing and
do
> so while interacting with a 7-bit-only system, I believe it's reasonable
to
> insist they upgrade their special processing system to remove the 7-bit
> encoding prior to processing.  And as much as I like sub-addresses, their
use
> is simply not widespread enough to merit additional design complexity
simply to
> avoid requiring up-conversion at that point in the system.
>
> Finally, down-conversion is a non-negotiable feature for some implementers
> (myself included).  I have to be able to down-convert the UTF-8 local
parts in
> the headers, even if an alternate address is unavailable (and it doesn't
change
> things if the spec requires an alternate address be available, as we still
have
> to deal with the non-compliant case in quality software).  So I suggest
> ATOMIC=yes should be implicit from the use of UTF-8 and thus not necessary
to
> include in the protocol specification.
>
>                 - Chris
>
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ima
>

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