--Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
Hello from a regular MARID poster!
Hi Matthew! Good to see you.
Meng's latest SPF plan (in which he has borrowed my idea of CSV semantics
using SPF records) was influenced by, among other things, a group of us
pushing strongly for HELO to always be checked. SPF already required
that the HELO be valid, so the change from saying that it MAY be checked
to it MUST be checked is not an issue, with respect to senders having to
comply with a new requirement.
I think the HELO aspect of CSV makes a good union with SPF. I'm sure you
agree too. What I didn't like about CSV is that it doesn't go far enough,
in my opinion.
The "unification theory" is about using the same tool set to check many
different identities. It's not about checking HELO and that's it.
LMAP proposals are many things to many people. For me in my role as a
domain owner, I would like to be able to protect against ALL phony uses of
my domain, whether in HELO, MAIL FROM, From:, Sender:, or any header that
users may see and think it came from me. That is the essence of
unification to me, that ANY identity can be checked.
If you are only checking HELO, what would you propose to do that would stop
someone from using a machine on comcast's network that HELO's as something
ending in comcast.net, and uses my domain nekodojo.org in MAIL FROM and
Sender:?
Remember, whatever the source for the domain that MARID validates,
blacklists and reputation services will be an integral part of the system.
A domain with a MARID record used in email with malicious forged From: is
gonna get in an RHSBL lickety-split: If you get word of From: forgery,
you're gonna be motivated to do a little work to get the spammer's domain
blacklisted, for example by putting him in your RHSDRBL (Right Hand Side
Distributed RBL), which will stop the forgery and phishing.
I agree that reputation systems will be important, but I think they should
not be the only weapon we have against forgery. I.e. if you get a passing
result from one identity, that's a great place to hook in a reputation
system... for example I believe AOL is planning to do something similar
with its whitelisting approach. However, if the sender is not known to you
and 100% trusted, you would be silly to stop before checking all the other
identities. A PASS result means that I can hold the domain owner
accountable for the behavior of the MTA, but a FAIL result should always be
questionable.
Put another way, if the reputation is snow-white, or you trust the sender,
go directly to accept. If the reputation is black or the thing is clearly
forged, go directly to reject. If it's in the wide gray area in between,
keep going and check the next identity... am I right?
OK Thanks for the note... I am hopeful that we'll all come to some kind of
agreement, and I think we're closer now than ever.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>