ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-03-05 16:32:06

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

 > This isn't about any of that. This is about the operations an SMTP
 > server is allowed to perform on the addresses associated with other
 > domains that appear in MAIL FROM and header fields. RFC 5321 says
 > the only thing you can do with such address is copy them around
 > untouched. But the reality is these addresses are *compared*.

Excuse me if I am not following you, but the compares are
implementation specific.

RIght, and that's exactly the point. Right now RFC 5321 says they can't be.

 Like Finch pointed out, Sieve doesn't care.

That's wasn't Tony's point. His point was that Sieve breaks the RFC 5321 rule
by allowing scripts to assign whatever semantics they like to local parts of
external addresses. Sieve can be case-sensitive or case-insensitive (the latter
is the default) and even has an extension for extracting subaddress information
from arbitrary addresses.

What you are saying, I think, you know of a procedure that does care
what the input is. Right?

Nope. I'm saying that there's all sorts of stuff out there busily comparing the
local parts of addresses they don't own using all sorts of different rules. And
that stuff is in clear violation of RFC 5321.

 > we're not talking about any sort of modification - with
 > other addresses in ways which, like it or not, assign
 > specific semantics to local parts. And RFC 5321 says that's
 > not allowed.

I am not reading it that way.  I am reading it should not ASSUME a
case for the purpose of some unknown or out of scope process.
Preservation is the best policy.

The word "case" isn't even mentioned in the text in question, so I fail to see
how you can possible get such a reading out of it.

I have a perfect example.  Due the age of our software, there could be
versions out there that export mail and SMTP reads and sends mail out:

     MAIL FROM:<first(_dot_)last(_at_)example(_dot_)com>
     MAIL FROM:<FIRST(_dot_)LAST(_at_)example(_dot_)com>
     MAIL FROM:<FIRST(_dot_)LAST(_at_)EXAMPLE(_dot_)COM>

What is the receiver system to assume here?

Well, you'd better hope it doesn't follow RFC 5321 rules, because that would
imply a case-sensitive comparison be done against any stored authorized address
list. And that's going to cause at least one of these to fail no matter what's
on the authorized list.

In practice, of course, pretty much every autoforwarder, list server, and so on
out there does a case-insensitive comparison. And it isn't at all uncommmon to
ignore subaddresses too.

    Should it lower, upper, keep case before passing it to
    should avs, shim, script, acl queue?

I think SMTP is saying to KEEP is the best policy.

Of course it should keep the case. Again, modification of the address isn't
at issue.

>> I'm not sure what you are getting too but consider the alternative:
>
>>     - rule that states its one case over another and that all systems
>>       MUST compare, store and render displays in one case?
>
> No, I'm not saying anything like that. I want systems to have the
> freedom to perform whatever comparison operation they believe are
 > appropriate, including ones that assume case sensitivity, or
 > insensitivity, or which attempt to strip common subaddress forms,
 > and so on. Right now they are prohited from doing any of that.

Man, I really wish I understand you because I see no such prohibition
at all.  All it is saying is don't force it way way or another, keep
as is and hopefully before the entire process is complete.

Well, all I can say is that I sure see such actions as prohibited by the
current language. And it seems that most other people who have weighed in on
this at least agree it can be interpreted that way. You choose not to, and
that's certainly your perogative, but if it can be interpreted in a way that
causes various common operations to be considered incompliant I see that as a
problem.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>