wayne wrote:
* 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.
I agree especially with the fact that verifying RFC2822 data is much
more complicated with all the headers involved and the lack of the
connecting IP address present. We need to separate the two problems -
RFC2821 verification and RFC2822 verification.
Why not the IP address via MTA-MARK/SS
* Receivers can already largely solve this problem today via DUL
lists.
It is more logical to have it in the IP address record itself - control
over rDNS space of an address is logically something that belongs to the
owner, just like forward DNS to domain owner. This allows people who get
dedicated IP addresses with rDNS control over them to mark them as MTAs.
* Senders can already largely solve this problem today via port 25
blocking.
Blocking has its problems and it is also not applied universally.
* 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.
The same applied for bounce addresses today :) As Phil mentioned
somewhere else if you give enough usefulness to it, the rDNS situtation
may improve since people will begin to use and maintain it. Another
possibility is an alternative place to store the data.
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.
I would add to this that even with RFC2821 verification you also happen
to verify one RFC2822 header - Return Path. This fact can be used by the
MUA to alert users.
Yakov