On 3/27/2004 6:10 PM, wayne sent forth REPOSTED electrons to convey:
...I've thought about this for well over a year now, and my opinions
haven't changed, despite all rehashing of stuff that was discussed on
ASRG many moons ago.
So, I might a well state my opinions and be done with it
*** I think the identities that we should consider are the RFC2821
*** MAIL FROM and HELO domains names.
First, let's confirm some common ground: I agree that these are highest
priority.
* I believe that the this is an easier problem to solve than the
RFC2822 header spoofing problems. The RFC2821 data is handled
almost entirely by programs and thus lends itself to verification
via programs.
I don't buy this. Besides which, RFC2822 headers are also handled almost
entirely by programs too.
* There are positive incentive for domain owners to publish
designated sender records and for email receivers to check them.
* I believe that rolling out a system that validates the RFC2821 data
can play an important part in the process of validating the RFC2822
data. I don't think we need to get into bogged down in exactly how
this will work right now. Let's pick the low hanging fruit first.
If we can use the incentive to get a single software update to spread
quickly that has a bigger impact on the spam problem, but has a
little-benefit-to-early-adopers-problem, perhaps we should.
Why not the IP address via MTA-MARK/SS
* Receivers can already largely solve this problem today via DUL
lists.
* Senders can already largely solve this problem today via port 25
blocking.
* I see little reason why owners of IP space who don't publish DUL
lists or do port 25 blocking would do MTA mark. There is no
incentive for them, this is something that they will have to spend a
great deal of time doing in order to help out other people.
* The rDNS space is a mess.
Good arguments that MTA-Mark won't help much. (MTA-Mark adds one DNS
query per email to do its work, right? My email is currently filtered
by a system that does perhaps a dozen checks on each IP in the header,
of which there may be several. It's better than DUL lists - no
unnecessary concentration of power. IP space owners don't publish DUL
lists. DUL list maintainers do. IP space owners do publish rDNS entries
that sometimes indicate DUL status - just clarifying.)
Why not the RFC2822 headers:
* To be really effective at protecting the RFC2822 headers from
phishing and such, you need to [have] changes to MUAs.
What? Why? If paypal says accept no email RFC2822 From us if it's not
from our servers, BAM! Effective paypal phishing antidote. Applies to
the two points below too.
* There are several decimal orders of magnitude (hi Ted) more
installed MUAs than installed MTAs.
* We have far less influence in the MUA market.
* Solving the RFC2822 data spoofing is a much harder problem
* There are too many different headers created by too many different
programs and that creates too many different cases to analyze.
It just doesn't seem that complicated to me.
* The RFC2822 headers allow comment string, so if you really want to
tackle phishing and spoofing, you have to figure out how to block
email claiming to be from things like this:
From: "Paypal Security Desk" <abuse(_at_)paypalsecurity(_dot_)com>
This is a weak argument. Most people will notice that this is not from
paypal.com. Those that don't won't be helped, even by a scheme that
completely replaces SMTP with something much better that's been designed
well, from scratch. Is this the MUA change you're referring to?
* I don't believe the RFC2822 spoofing problem space is as well
understood as the RFC2821 problem space.
Even though this is a fairly long post, it really only covers the
surface of why I am convinced that the RFC2821 data is the thing to
tackle first. While I'm certain that, for each point mentioned above,
there are people who disagree with me. I'm certain that there are
people who disagree with all of this. However, to change my mind
after studying this problem for as long as I have, you would need to
come up with some pretty strong arguments. If such arguments
existed, I would likely have heard them before now.
So, with two weeks to go before a "last call" on this issue is needed,
I'm ready to put my two cents in.
-wayne