From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
SPF classic validates the MAIL FROM identity defined in
RFC2821 by describing which IP addresses a given MAIL
FROM can originate from. Sender-ID validates a new identity
defined by Microsoft called "PRA" which is derived from
identities defined in RFC2822 via a patented algorithm.
Stuate, I just wish to make a small but critical point of clarification for
the readers. I know you understand this. I am just translating this into
into its technical details for general public to understand the key
difference.
There is no new identity in SENDERID that implies in any way, a new 2822
header exist such has:
PRA: <purported responsible address>
This does not exist.
This is important because a claim of a new entity (or element) in a total
process for a patent disclosure is one of the key ingredients in analzying
and validating the patent claim(s). This is extremely and critically
important and people should do not get the wrong idea about SenderID having
"something new" that cures the email problem. It doesn't.
So it more of a concept , a new acroymn and terminology or recommendation
for extracting (finding) the Purported Responsible Address (PRA) or sender
of the message 100% purely based on existing prior art (it was invented by
other people, not MS) 2822 headers.
Now the details. If you can skip this is you like, but it will show how the
statement "MS will not check MFROM" doesn't make sense and needs to be
clarified as to what they actually mean by that.
The PRA lookup order in the 2822 header is:
set PRA=NONE
if PRA=NONE and Resent-Sender Exist
then set PRA=Resent-Sender
if PRA=NONE and Resent-From exist
then set PRA=Resent-From
if PRA=NONE and Sender: exist
then set PRA=Sender:
if PRA=NONE and From: exist
then set PRA=From:
If none of these exist, then there is no "PRA" (PRA=NONE) according to
Microsoft Standards
However, by 2821/2822 prior art internet standards, the missing so called
"PRA" would the 2821. MAIL FROM, the envelope return address. If there is
no PRA, then MFROM is both the bouncing address and also the Author address
that is used for displaying on the screen.
This is why it doesn't make sense for Microsoft to make a technical
statement that they will not check the MFROM. I can only make sense of
this statement to imply they will not be doing the checking at the 2821 MAIL
FROM state, but rather at the 2821 DATA state or as a POST SMTP process.
But if they don't check the MFROM, and there is no PRA in the header, then
suddenly they let the bugs and snakes into the house if they don't check for
the Return-Path.
So this statement "will not check MFROM:" will only make sense if the above
PRA lookup order changes to:
set PRA=NONE
if PRA=NONE and Resent-Sender Exist
then set PRA=Resent-Sender
if PRA=NONE and Resent-From exist
then set PRA=Resent-From
if PRA=NONE and Sender: exist
then set PRA=Sender:
if PRA=NONE and From: exist
then set PRA=From:
if PRA=NONE and Return-Path: exist
then set PRA=Return-Path:
Or you can simplify and rewrite the above using a override concept in
reverse order:
set PRA=Return-Path:
if From: exist then set PRA=From:
if Sender: exist then set PRA=Sender:
if Resent-From exist then set PRA=Resent-From
if Resent-Sender exist then set PRA=Resent-Sender
A C/C++ class function to handle this would be:
char *CSenderID::GetPRA()
{
char *pra = Headers["Return-Path:"];
if (Headers["From:"]) pra = Headers["From:"];
if (Headers["Sender:"]) pra = Headers["Sender:"];
if (Headers["Resent-From:"]) pra = Headers["Resent-From:"];
if (Headers["Resent-Sender:"]) pra = Headers["Resent-Sender:"];
return pra;
}
If the MS statement is true, and they are not checking MFROM or the
Return-Path, then, change the above to:
char *CSenderID::GetPRA()
{
char *pra = NULL; // none
if (Headers["From:"]) pra = Headers["From:"];
if (Headers["Sender:"]) pra = Headers["Sender:"];
if (Headers["Resent-From:"]) pra = Headers["Resent-From:"];
if (Headers["Resent-Sender:"]) pra = Headers["Resent-Sender:"];
return pra;
}
If this is the case, they would have a significant design problem because
their C/C++ SenderID function will be totally useless when there is no PRA.
BOOL CSenderID::CheckSenderID()
{
char *pra = GetPRA();
if (pra == NULL) {
SetErrorMessage("No PRA - invalid message??")
return FALSE;
}
return PerformSenderID_SPF2_Check(pra);
}
See what I saying?
If they don't do this, then they lost all opportunity to do any checking at
2822 by not doing a check at 2821.MFROM.
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com