In <p06020403bc7be6e71cf3(_at_)[205(_dot_)214(_dot_)163(_dot_)2]> Ted Hardie
Working Group Goals and Milestones:
March 04 Discuss identities with which MTA authorization
should be associated
April 04 Working Group last call on which identities
used for MTA authorization
Ok, we are supposed to be discussing the identities with which MTA
authorization should be associated with.
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.
My reasons for this are more pragmatic than technical.
Why I think we should work first on the RFC2821 MAIL FROM and HELO domains.
* The MAIL FROM is where bounces go to and a lot of the spam that
makes it past SpamAssassin and into my inbox are bogus bounces/virus
* Both the HELO domain and the MAIL FROM show up in email headers.
When non-email-gurus look for the source of the spam, they are often
mislead into believing that the spoofed domains are the real source.
This causes bogus abuse desk complaints.
* A very large percentage of the email being sent now-a-days is spam
with forged MAIL FROM addresses. As a result, it is no longer safe
to accept email and then send bounces to the MAIL FROM address
without causing problems for innocent third parties. No other
header/identity is acceptable to send bounces to either. As a
result, we have effectively lost the ability to safely send bounces.
the best we can do is use a 5xx rejection code during the SMTP
session, and even that can cause innocent third parties to receive
The MAIL FROM address has basically lost all of its historical
usefulness. While we can not restore all of the functionality it
once had, we can restore a great deal of it.
* 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
* There are positive incentive for domain owners to publish
designated sender records and for email receivers to check them.
Besides the reduced number of bogus bounces and bogus complaints, by
publishing designated sender records, domain owners are making a
public notice to protect their brand names and their good good
reputations. This is kind of like putting up "No trespassing"
signs. Publishing records is a very low cost thing to do, even if
initially there isn't a huge payback.
For email receivers, the benefits for checking is pretty clear: it
catches spam, joe-jobs and phishing. It will never catch all of it,
but again, this is a fairly low cost thing to check. Even at this
early stage, SPF checks are stopping about 1% of the spam that
reaches my machine.
* With SPF having been in field testing for months, the problem space
is (comparatively) well understood.
* 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.
Why not the IP address via MTA-MARK/SS
* Receivers can already largely solve this problem today via DUL
* Senders can already largely solve this problem today via port 25
* 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.
Why not the RFC2822 headers:
* To be really effective at protecting the RFC2822 headers from
phishing and such, you need to changes to MUAs.
* 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.
* 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>
* 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.