Greg Connor wrote:
Does that make any sense at all? :-)
Bruce mumbled something about RfC 724 on the rfc822 list, and
that got me to read this RfC, written 1977: What we do today
in mail is essentially still the same as 28 years ago. Okay,
we now use "@" instead of a verbatim " at ", somebody invented
the weird Resent-header fields because MIME didn't exist at
this time, and of course now we have SMTP istead of FTP / UUCP.
But otherwise From / Sender / Reply-To are still the same as
1979 and before. It's fun to read RfC 724. When you say...
I don't want to have the same argument over and over every
time a new header, ESMTP extension, or whatever thing comes
along.
...then there were apparently only three occasions in the past
30 years where they got you: 1: SMTP invented, 2: Resent-*
added, 3: Resent-* modified by 2822.
That's not over and over again, that's one new idea per decade,
and I wouldn't miss the old or new Resent-concept for a single
second, all it does is to confuse PRA and 2476bis, MIME is IMO
much better for resending mails.
But you say we get some new interesting mail "identities" soon.
That still doesn't change the fact that SPF is simply a way to
enumerate four sets of IPs, + ? ~ and -. The four IP sets are
defined by the "sender" (actually it's the owner of a domain).
This domain owner can define whatever he likes from +all down
to -all, in any case it's his POV. Behind the border of the
receiver for the case of messages (= 1st MX) the sender's POV
is meaningless, checking SPF later doesn't work. Always, it's
a feature and no bug, and it's _independent_ of the checked
identity, HELO or MAIL FROM or PRA or any new idea you have.
After the message crossed the border you can't check it anymore
- it's too late. You could replace the old identity by a new
identity for a later check, the SRS idea for v=spf1, or the
"add Sender or Resent-*" stuff for PRA.
But for a single header field like From that's not changed in
transit there's only one place to check it, the border MTA.
And by definition header fields are _never_ changed in transit.
The worst you get are added header fields, additional Resent-*
blocks, new timestamp lines, and Received-SPF. [[ BTW, ugly as
it is, Received-SPF is still a historical event, the first new
mail trace header field defined in an RfC for about 30 years ]]
Anyway, what I want to say, there are no new players on the
field of "mail identities" popping up from the woodwork, it's
a closed user group, strictly limited to HELO, MAIL FROM, and
the 2822-crowd also known as PRA.
And for "sets of + ? ~ - IPs defined from a sender's POV" you
have exactly one virtual point where the control shifts to the
receiver, behind that border the sender's POV is irrelevant.
IHHO SPF (+/- spf2.0) covers all reasonable was to do anything
with these fixed elements. Providing for unknown new elements
with unknown properties is a strange idea, given that there
were no new elements for decades.
What you want sounds for me like an attempt to allow for more
even primes than 2, just in case if somebody finds a new even
prime.
Sorry, I just don't see it. SPF is here to stay, when William
says 2 to 5 years, maybe it's a decade or longer, until SMTP
incl. MX itself is obsolete.
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com