From: Frank Ellermann
Sent: Thursday, October 21, 2004 10:50 AM
Seth Goodman wrote:
The more we can reject during SMTP, the more the original
assumptions behind SMTP can be trusted.
Okay, but please make sure that this is only an option. If a
mailer treats anything between DATA and "dot" as unidentified
garbage and adds only his time stamp (Received:), then that's
not "wrong".
Nothing in SPF forces a recipient to reject anything. What a recipient does
with any SPF result is up to local policy.
First of all, it is the sender's option whether or not they enforce
submission rights. I wish that were not so, but it is. It is the sender's
further option whether or not to publish the fact that they enforce
submission rights. Even if the sender enforces submission rights and
publish that fact, it is _still_ up to the recipient to decide what to do if
the 2821 and 2822 identities don't match. Taking it one step further, even
if the recipient has a local policy to reject on SPF fails based on the
proposed modifier that says the 2821 and 2822 identities are supposed to
match, they can still whitelist. Every step in this process is voluntary.
If as a sender, you don't want to make this assertion for whatever reason,
you don't have to.
Very good idea, William! This beats the heck out of PRA, and
I'm delighted to see it.
Indeed. The "Sender-ID" fans had enough chances to fix their
algorithm using the Return-Path, but they ignored it. What
William did is essentially an opt-in solution for those who
really need and want it.
Exactly. I think a lot of domains that responsibly control submission
rights would take advantage of it. This is a very potent tool to stop
phishing without anything as heavyweight as DK.
I'm pretty confident this is free and clear of Microsoft's
IP.
My copy of STD 11 says "David H. Crocker", August 1982. They
didn't invent this "Standard for ARPA Internet text messages",
That's my basis for this thinking, as well. It is a straightforward
application of these original RFC's and their replacements. The meaning of
the headers is respected and taken directly from the standards and existing
SMTP practice, where it is different from the standards. There is no new
invention, but a very intelligent rediscovery of what we've had all along.
the situations where people can't send mail with the same
2821 and 2822 identities are becoming less and less common.
Here I strogly disagree, but it's no problem, because it's an
opt-in idea.
Note that I didn't comment on the fact that many people can't set both 2821
and 2822 identities to anything they want. My comment is that most people
_can_ set them to both be the same, though they may not like the address
they are restricted to.
Mailing lists are already compliant.
No, some use Errors-To.
Good point. I think we can come up with a relatively short list of common
practices that are not RFC-based that this scheme would still respect.
There's nothing wrong with recognizing and respecting de facto standards.
Though people might disagree about a header used in some obscure and ancient
MTA, the list of commonly used de facto standard headers would not be hard
to identify.
Both the traveling salesman and vanity domain problems can be
solved through the use of SMTP AUTH.
Is that RfC 2476 "MAY add Sender" ? Then I know one MSA which
enforces submission rights, but does _not_ manipulate the DATA.
That might be even illegal and / or a privacy issue (IANAL).
<IANAL> AFAIK, ISP's are not responsible for traffic originating from their
facility unless under specific court orders. If they were, there would be
many fewer ISP's and a lot less spam. </IANAL>
But there's something I definitely don't understand. When you say that a
particular MSA enforces submission rights but does not manipulate data, are
you saying that it simply rejects non-compliant messages? Without changing
a header or rejecting the submission, how else can they enforce submission
rights? Or are you saying they require authentication but then allow
forgery, which is quite common today.
If not having the two identities match resulted in some mail
not getting delivered, this would produce the necessary
"encouragement" for providers to implement SMTP AUTH
"MAY add Sender" and "enforce submission rights" are _options_
in RfC 2476. Authentication alone is not good enough. With
"enforced submission rights" you get a valid MAIL FROM for SPF.
This is self-evident. No one with any clue would publish the 2821=2822
header equivalence modifier if their MSA did not enforce submission rights.
It's the sender's responsibility to decide if they want to publish this more
stringent requirement. It is also to their great advantage if MUA's can
ever display that the assertion has been met.
With "MAY add Sender" you get Wiliams's "equivalent header",
and maybe some discussions with privacy officers. And this
"equivalent header" (= Sender) is technically redundant, which
is not exactly any "encouragement".
Anyone who's MSA does not actually enforce submission rights by either
rejecting non-compliant mail or changing headers to make it compliant would
be making a big mistake to publish the 2821=2822 equivalence modifier.
Don't publish a sending policy that you don't adhere to. To the extent that
people have more trust when a sender makes the equivalence assertion and the
message passes that test, this will encourage domains to try and accomplish
this. If nothing else, it should be worth a couple of points in
SpamAssassin. Of course, that's up to the recipient. They are free to
ignore it if they wish.
But companies hit by phishing attempts will of course love it.
And they won't be disappointed if this breaks posting to some
moderated newsgroups. But William's proposal is _not_ suited
for average users. It's for those who desperately want it.
Anyone who can enforce submission rights for their domain would want to do
this to hinder 2822 joe-jobs. I don't agree that you have to be desperate
to want that. This is just an extension of the original goal of SPF:
preventing 2821 joe-jobs. What's great about this is that it is completely
optional, yet when a domain is able to make the assertion, it stops 2822
forgery at compliant recipients. It sure beats the heck out of DK to
accomplish most of the same thing. Team this up with SES and you have a
solution that doesn't break forwarding, doesn't require any new ESMTP
parameters, doesn't break any non-compliant legacy SMTP system, doesn't put
a heavy crypto load on either sender or recipient and prevents _both_ 2821
and 2822 forgery at compliant recipients.
Adding both SES and William's 2821=2822 equivalence modifier to SPF turns it
into an end-to-end authentication scheme for both identities _and_
completely obviates the need for PRA. Now _that_ is really big news. I
don't see any losers in this scenario, except for a spammer or two. Sorry,
guys.
--
Seth Goodman