On Sun, May 23, 2004 at 05:59:43AM -0700, Justin Mason wrote:
|
| BTW, if we're talking about a new piece of SMTP-time data to be recorded,
| can we change that from a "Resent-Sender" header, which will be
| overwritten at each hop, and use a "(resent-sender <....>)" extension to
| the existing Received header?
|
| Received has the nice semantics that it is preserved across multiple hops.
| This means that it's usable in many more setups than a "last hop only"
| mechanism like a Resent-Sender header.
Daniel Quinlan is working on "Received" header standardization. I
think putting it into Received would work just as well as, if not
better than, prepending a header.
The Caller-ID algorithm for selecting the Purported Responsible
Address/Domain was derived empirically. Given a corpus of BIGNUM
messages, figure out the best method for obtaining the PRA; then we
enshrine that in an algorithm that we can use prescriptively.
We're still in the first phase, where we develop the algorithm based
on what's in the field. When we move to the second phase there will
be room to define new header conventions.
| Consider an org that has a firewall MTA, then a spam-checking MTA, then
| the internal MTA with user accounts. With a single "last hop only"
| header, the spam checking MTA cannot use that check; because the firewall
| MTA may have modified it. If the RFROM was recorded in the Received
| hdr, it still could use that (once the admin indicates that the firewall
| MTA is trustworthy).
|
| Sounds like "Resent-Sender" is now cast in stone though :(
Nothing's cast in stone yet; we're going to circulate more drafts for
comment and keep tweaking. It's only cast in stone when the RFC is
issued.
Before then, however, we do have to put out a set of use cases for
each constituency -- forwarders, web generated emailers, mobile
providers, ISPs, enterprises, mailing lists, John Gilmore, bulk
mailers, spammers, etc. We will iterate based on their feedback.
To keep from polluting the MXCOMP list with "subcommittee" work, I
would like this discussion to happen on the spf-discuss mailing list.
I will invite Jim Lyon, Bob Atkinson, and others to join here.
The requirements/specification procedure is complicated by the fact
that many of these constituencies are oblivious to the work we're
doing. Only when we start rolling things out can we expect them to
wake up, and then we might have to do another round of iteration just
to satisfy them. But, sigh, that's how software engineering works.