----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
This is NOT a possible way to fix their PRA for v=spf1. For
the numerous examples with From != Return-Path without any
Sender it outputs a "From" instead of "Return-Path" address.
PRA is FUBAR by itself, applying it on v=spf1 makes it worse.
Frank,
Last night I wrote a C/C++ CSenderID class to process backup email
(including rejections) to begin an SenderID/PRA validation and efficient
test.
For now, the key question I just wanted to explore was the PRA extraction
using the "Six Steps" Program outlined in the path and compare it with
2821.MailFrom.
I ran a quick test on about 10K messages
The PRA extraction split was:
Pra From: : 17%
Pra Sender: : 83%
Pra Resent-From: : 0% (negligible, 2 hits)
Pra Resent-Sender : 0% (negligible, 20 hits)
and
2822.PRA = 2821.MailFrom : 88%
A good bit of the 12% where it was the same, were of course, mailing list
messages.
Gawd, look at the magic Pareto's Principle ratio! (80:20) <g>
I need to confirm this with a larger spread and collection of logs from
other sites, but I wasn't surprise with the expected result. It reaffirms
my concern that the payload based SenderID/PRA protocol will be a major
overhead on the internet network.
I am going to have much more results very soon with real SPF lookup
comparisons too.
PS: Here are some other quick summaries:
In PRA Step 4, the rule to extract the From: address says that there are
multiple From: headers, then go to Step 6.0. I got quite a few of these
and all of them were legitimate bounce messages, not spammers using a Null
Return Path.
I believe this is wrong, in fact, where is the justification and logical
reasoning for Step 1, 3 and 4? I have not studied this and matched it with
RFC 2822, but do you think the "Reasoning is adequate?" Obviously, I
can see a reason where if there two From: that it might considered a bad
message, but the logic I would add is:
Original PRA step 4.
4. Select all the non-empty From headers in the message. If there is
exactly one such header, continue with step 5. Otherwise, proceed
to step 6..
New ESPF SLA (SPF Lookup Address) From: field extraction logic:
- Extract all From: field.
- If only one is found, the SLA is found.
- If more then one and the Return Path is NULL, then select the
From: held which is not part of your local domain.
- If no From: field is found and Return Path is NULL, this
message is a candidate for a malicious Bounce Message.
If Return Path is not NULL, the SLA is the return Path.
<g>
Anyway, the above is probably not quite correct. The main point was to
adjust for the mailer-daemons sending legitimate bounces where it keeps the
original From: header and adds a new From: postmaster(_at_)mailer(_dot_)domain
Besides for a ESPF SLA logic, in my design, I would emphasize the Return
Path 2821 lookup first, and if this is neutral, software or even maybe fail,
then check for a different domain in the 2822 headers. This would make it
more efficient since atleast 80% or more of the time, it would produce the
result, and if not, then you can continue with the payload since you have to
receive it anyway at this point.
Remember Frank, we don't have to use PRA is it doesn't work. ESPF can do
something different and more efficient too.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com