by "identity", we refer to:
2821 HELO/EHLO domain
2821 MAIL FROM
2822 From:
2822 Sender:
There is a third way. The first way is for us to formulate some
prescriptive statement, endorsing "authentication" of one or
more of these
"identities". The second way is a purely descriptive
approach, describing
the outward MTA configuration for a domain (PHB, I think), and to be
agnostic on *use*.
I think it is reasonable to describe the expected use to be made
of the information, but trying to insist that the information only
be used in limited ways that permit a postcard sites and a tiny
number of geeks to keep on sending mail with unauthenticated
RFC 822 from addresses is futile.
A third way would allow a publisher to suggest (or even require) the
identities that the record should be applied to.
This is actually what I have been arguing for in the descriptive
approach. There being two basic configurations:
1) As the holder of domain X I will be held accountable for all email
provided they are authenticated (e.g. by the fact that the IP
address of the sending MTA in the set Y).
2) As the holder of domain X I assert that all email that purports
to originate from the domain (by reference to the From or Sender
address) is bogus UNLESS it can be authenticated (e.g. by the fact
that the IP address of the sending MTA in the set Y).
In model (1) the Helo or RFC 821 address is only used as a way of finding
out who should be held accountable.
In model (2) we have to do two separate checks, one on the Helo or From
address, this is probably done during the SMTP transaction, a second one on
the From: address.
These are both valid models and we should support both of them, the sender
should suggest to the recipient which should be applied. But the right to
override that choice must always lie with the recipient. For example, if the
recipient is 50% certain a message is spam, checking RFC822 from may well be
the criteria that tips the balance.
Model (1) does not check any data the user sees, it does not provide value
unless there is a way to know the likelyhood that the domain is being used
for spamming.
There are a bunch of corner cases here:
1) The most obvious way to set up a filter would be to test the HELO value
as soon as it is sent and only test the RFC-821 From if the HELO information
returned was unsatisfactory.
2) An email with a Sender: address is being relayed, most likely by a
mailing list. So if Sender is present we perform checking on Sender in place
of 822:From. There are a number of possibilities:
A) The email originates from a mail forwarder.
This is relatively straightforward from the point of view
of accreditation. Each individual will have a persistent
relationship with their mail forwarders. It should be easy
to whitelist these relationships, either by the end user or
through a third party accreditation. Alternatively a proof
of consent protocol could be used.
B) The mail originates from a mailing list.
This is slightly harder to deal with, but still it is a
straightforward problem.
C) Its a postcard type site.
This is problematic because the postcard sites do not in
general authenticate the forwarding requests and so even
a legit site can end up being used to spam on a small scale.
The real problem with these scenarios is that we depend on the party that
sets Sender to perform authentication checks on incomming mail.
I don't think that fixing mailing lists is a huge problem. In fact I expect
that mailing list admins will be the first to want to use these tools since
they often suffer the most as a result of spam.
Phill