----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, June 22, 2005 1:21 AM
Subject: Re: [spf-discuss] Problem with SID
On Wed, 22 Jun 2005, Hector Santos wrote:
In short, if they don't do a MFROM check and don't correct this with a
2822
Return-Path check, then their Sender-ID implementation is broken.
Since their software runs in the MUA, they are probably counting on
the MTA doing an MFROM check before it ever gets to the MUA. This is
completely reasonable.
Not sure if I follow this.
If you mean the CLIENT will do the SPF/SENDERID check after or duing a
POP3/IMAP mail pick up, then they need to be careful that this is already a
patented process. Not that it is enforceable, the patentee has already made
noise that Microsoft has stepped on its patent with MUA FROM checking.
But I believe this issue with hotmail is that they will be doing SENDERID
checking with incoming messages to HOTMAIL.COM accounts.
So at this moment, assuming the hotmail MX host servers are MS exchanges,
Microsoft already has a "hook" concept into various points of the SMTP state
machine. Given then the benefit of the doubt (good engineering), they
will be adding a hook at the DATA stage. But then again, that is how we do
it so I assume this is the most logical place to do mail content analysis -
not post smtp.
The only unreasonable thing they are doing is using SPF classic records
for PRA checks.
Why is this unreasonable?
My instincts tells me that the only danger this presents is that it is will
help complete the Coup D'etat for the inevitable 100% complete ownership of
the SPF concept.
In my view, you will have no choice but to do something with 2822 headers
to address the forwarding problem in SPF1.
It doesn't have to be the PRA method. It can be something else.
This is where "ESPF" (Extended SPF) comes into play for future R&D.
The longer you guys get bogged down with IETF related issues on SPF specs
endorsement, the more it becomes questionable.
You really want create a stir?
Create an alternatively SPF1 2822 header checking concept to address the
forwarding problem. The PRA is not it. SRS is not is. If it was, we
wouldn't be having this discussion. :-)
You got to look at this from a systems (or software) engineering standpoint
where you look at all the integrated parts and then begin to look at the
integrated interface consistencies, as well as interface inconsistencies and
use these facts to develop a scheme that optimized the reliability of the
solution.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com