[Top] [All Lists]

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

2009-03-05 17:35:07

Ned Freed wrote:

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.

This is so odd.

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.

All of which would not be possible if SMTP did not preserve the address case.

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.

Again, all of which would not be possible if SMTP did not preserve the address case.

And that stuff is in clear violation of RFC 5321.

If SMTP did touch it, then it would be in violation or it might cause problems for software that may WISH to look at the case.

So I am really having a hard time understanding what you are talking about - or rather what you are proposing to see happen.

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.

Come on Ned, see section 2.4.

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.

But thats presuming there are significant # of mail-bots are still looking for specific case.

Would you should this the the norm? passe?

I will venture most systems have learn not to do case sensitive compares, including us.

In practice, of course, pretty much every autoforwarder, list server, and so on out there does a case-insensitive comparison.

I fail to see the conflict then. But you do make implementation assumptions that should be out of scope. What if there are auto-forwarders, list servers that do case sensitive compare? You are probably right, low chance. But SMTP should not be assuming one way or another in order to fix those that may be working with lower or upper case or not doing case-insensitive compares. It should not be SMTP concern.

I can only begin to better understand your point better if you are suggesting SMTP should be forcing a case - maybe to the common dominator of lower case addresses.

> 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.

Right, what is at issue is how you wish SMTP semantics to be changed to one that probably isn't very realistic.

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, I'm grown tired of this attacks. Its funny that I could of blabbed the same thing about you. So you beat me to it (although I wasn't planning to) and labeled me the odd ball here. Fine, its par for the course here.

But we are handling it right and that is all that matters - we are preserving it - at the SMTP level. So whether you believe 5321 is incorrect, as it was yesterday 2821 and today 5321, we are compliant.

What you have yet to explain is why it is important or broken for some specific auto-forwarder?

The reality is as clear you implied:

    Most systems do a case-insensitive compare

so its really a practical moot point.

It sounds like you are assuming all auto-forwarders with some "access controls" (whatever that means and doesn't matter) behave with the same logic and you know that is not true.

So this is an implementation issue, not an architectural issue and to assume that it is, is to presume that the entire network is operating under some specific constant level - which is not reality.

The architectural recommendation is preservation. That has always been the best policy across the board.

That does not mean you have to do case [in]sensitive compares. Thats out of scope and up to you.

Anyway, I don't see a problem with 5321 wrt to this issue.

So -1 on changing it.


Hector Santos

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