On Thu, Feb 19, 2004 at 11:08:14AM -0500, Hector Santos wrote:
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 the sending entity (the domain, not the user) tells you the host is
under control of said entity, you should be able to trust the message
envelope. The return-path _is_ valid.
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 :-)
Bounces are not evil. Bounces are a necessary part of todays email.
Without SPF, you have no way of knowing (for sure) if the bounce is
directed at the true author of the message. With an SPF-pass, you
know with a reasonable certainty the return-path is valid.
SPF-pass: 100% certain the message is legitimate
SPF-fail: near to 100% certain the message is bogus
SPF-softfail: message likely to be bogus, but far less than 100%
SPF-unknown: as if SPF were not there
A SPF fail result provided 100% trust and a 55x rejection ...
... In this case, a
"Receive-SPF: fail" header has no role or meaning.
Not 100%, not necessarily 55x rejection, "Receive-SPF: fail" won't be
generated if the mail is rejected but must/should be generated if the
mail is _not_ rejected (for whatever reason). SPF does not dictate one
should reject mail.
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.
There _is_ a difference. Softfail will give me, the receiver, a chance
to let you, the author, know you are doing something wrong.
(or maybe the domain owner is wrong, in which case you, the author, should
contact your provider).
Also, you can be sure I will (eventually) test a soft-failed message to
every blacklist/virusscanner/spamassassin and what more. I may opt to
use less lists (skip the expensive ones for instance) on SPF-passed mail.
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.
*THE* benefit of SPF with respect to bounces is that it limits bounces to
joe-jobbed messages. True bounces are not affected by it, at all.
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags