On Sat, 26 Feb 2005, David MacQuigg wrote:
Let me pose a different question. If a standard were adopted, and that
standard included only the three items I suggested ( IP address, domain
name, authentication result ), would the SPF community be able to work with
that? e.g. would you be able to produce an MTA that did authentication the
way you want, even putting other information in your own headers, but still
work with other MTA's that might use SenderID, or some other protocol that
communicated authentication information only via those three items?
Any authentication scheme that involves putting any information in rfc2822
headers (other than for tracing purposes) is competing with senderID and
DomainKeys, *not* SPF. SPF is an rfc2821 authentication protocol and takes
place before SMTP DATA, the same with SRS and SES (except that SES can
optionally use rfc2822 headers and message body for replay protection). The
only "headers" in rfc2821 are HELO, MAIL FROM, and RCPT TO.
I am not currently interested in rfc2822 authentication. But when
I need to do it, I would certainly prefer your system to Microsofts
if it is not patent encumbered, or at least provides a free
non-discriminatory (GPL compatible) license to implement the protocol
(and assuming it actually works).
This list is for discussing using and promoting SPFv1 for rfc2821
authentication. I'm not dissing your ideas - they are just off topic. If
you've got something better than the Microsoft senderID abhomination - more
power to you. But part of what makes the Microsoft proposal abhominable is
that it confuses the 2821 and 2822 layers of SMTP, both technically and
in their marketing FUD. SPFv2 and Unified SPF reuse the syntax and DNS
framework of SPFv1 to also handle rfc2822, but they carefully keep the layers
separate via scope modifiers.
Having said that, I should reevaluate your posts with the assumption that
you are actually talking about a senderID alternative, rather than
an SPF alternative. You might have some great ideas that would do
an end run around Microsoft. To an end-user, rfc2822 headers are
much more visible, and where the user needs the most help in
recognizing "phishing" attacks. I say, I *should* reevaluate your
posts, however, I'm not really up to speed on 2822 authentication, having been
concentrating on the 2821 end of things.
I notice that SRS uses a hash code. That isn't part of the standard, so your
MTA must work even with another MTA that doesn't use it.
The hash code for SRS and SES is only used by the senders MTAs. That
is why SRS and SES work perfectly even if you are the only domain in
the world to implement them. They do not depend on any cooperation
from other entities other than using return path for DSNs per rfc2821.
Neither SRS nor SES are part of the SPF standard, but each has its
own documents which do specify the hash code so that different implementations
are interchangeable on an MTA.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.