----- Original Message -----
From: "Dan Boresjo" <dan(_at_)boresjo(_dot_)demon(_dot_)co(_dot_)uk>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, February 19, 2004 10:23 AM
Subject: Re: [spf-discuss] softfail considered harmful
On Thursday 19 February 2004 15:08, Hector Santos wrote:
With a SPF pass result, SMTP can not confidently make a decision to
reject
the message (which like you said, could be spam). But it must move on
to
the next step and if there is no other testing to be performed at the
protocol, then you accept it and let so post validation or mail filter
system take control.
This form of post validation operation is what the SORBIG-generation
email
viruses feeds on. They love systems that is going to try to bounce
mail.
If you reject at the protocol level, you have no bounce. That is a
major
big difference.
You can treat the return-path as 100% valid if SPF passes.
You mean you can treat it was a "no decision" to be made, i.e, you can not
reject. A pass can not be trusted. More testing maybe warranted.
If you subsequently wish to bounce the mail for any reason, that is OK
since
you know you are not bouncing to a joe-jobbed address.
Oh gosh Dan, no :-)
Ok, I think I am understanding the difference in philosophies here:
Dynamic SMTP validation systems vs Non-SMTP Post Validation systems
With Dynamic SMTP validation:
A SPF fail result provided 100% trust and a 55x rejection response can by
immediately provided at the MAIL FROM state point or RCPT TO: if the checked
is delayed to this point as recommended by RFC 2821. In this case
protocol level rejection, there is bounce in this transaction. SMTP is not
interested in your mail whether it is good or bad. In this case, a
"Receive-SPF: fail" header has no role or meaning.
A SPF pass result provide less than 100% trust in the result. You can not
reject and therefore send a 250 positive response. Assuming there is no
other check (like CBV) at the protocol level, you have no choice by to
"accept" the message and assume responsibility for delivering it or bouncing
it. This responsibility should not be taken lightly as it has legal
precedence behind it. In this case, a "Receive-SPF: pass" header has a role
or meaning.
A SPF softfail result provide a confusing set of logic for the dynamic smtp
system. The fact the ultimate intent of the SPF system with the softfail
result is to eventually turn it into a fail, provide some weight that the
sender is closer to a fail than a pass. But there is no way to validate
this, so you must accept the message with a 250 response and thus this
falls in the same category of the pass result where the system must assume
responsibility for delivering the mail. Again, the odds are good it is a
fail because that is the ultimate intent of the SPF softfail record, but
SMTP can not make that decision yet. This is now a HOLE into the protocol
level validation system. In this case, a "Receive-SPF: softfail" header has
a role or meaning but it is the same role as a pass.
Non-SMTP Post Validation systems:
With systems that do no perform SMTP level validation, you have no choice by
to accept the message.
For a post validation fail, you can skip the AVS skipping. A bounce is
desirable but questionable in the SORBIG-generation era. So you should just
reject the message in all cases. It has ECPA implications in the US but a
fail SPF record intent of the host should prevail in a tout case.
For a post validation pass, you still need to do AVS checking. Only
malicious mail should be discarded. SPAM probably can probably alter this
logic. A bounce is desirable but questionable in the SORBIG-generation
era. It has ECPA implications in the US especially if it turns out the mail
was actually good but discarded away. If you bounce (as SMTP requires you
for accepting the message in the first place), you limit your liability.
For a post validation softfail, you still need to do AVS checking. Only
malicious mail should be discarded. SPAM probably can probably alter this
logic. A bounce is desirable but questionable in the SORBIG-generation
era. It has ECPA implications in the US especially if it turns out the mail
was actually good but discarded away. If you bounce (as SMTP requires you
for accepting the message in the first place), you limit your liability.
So as you see, there is no difference between softfail and pass. they both
need to be treated the same.
Why?
Because you accepted the message in the first place at SMTP.
I will try to summarize this:
For softfail, a dynamic SMTP validation system should treat this as a pass
and accept the message and allow any post validation logic to handle the
softfail. The post validation logic should treat the softfail and pass
results with the same level of scrutiny.
The benefits of a new era of Sender validation concept should help in the
reduction of transactions and bounces. Bounces should be limited to what is
only necessary and possible. This is why our return path address validation
places such an important role in our own testing.
With that said, softfail is fine from a recording standpoint for the post
validation system, but it should not be treated as a pass and scrutinized
with the same level of effort.
I think if there is any suggestion for change, it should be that the specs
make it perfectly clear that softfail should be viewed as a temporary
operation only with a limited period of usage.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com