--On 30 June 2009 07:11:05 -0400 Rich Kulawiec <rsk(_at_)gsp(_dot_)org> wrote:
On Tue, Jun 30, 2009 at 10:55:04AM +0100, Ian Eiloart wrote:
However, I do believe that people should take SPF records into account
when deciding whether to generate bounce messages.
Despite the ostentatious claims made by its originator ("Spam as a
technical problem is solved by SPF"), SPF has no anti-spam value.
Given that you don't have a precise definition of spam, that's a pretty
strong claim in itself.
Nor should it be used when deciding whether to generate a bounce:
the answer to that is always "no". It's far better to reject (not
to mention far simpler, with any sane MTA) and thus greatly diminish
the possibility of outscatter/backscatter spam.
The point of SPF is to authenticate the sending domain. If the IP address
is authorised (by the domain owner) to send mail from the sender domain,
then bouncing mail into that domain isn't going to be causing backscatter,
unless the domain lacks internal controls over message submission. If it
does lack those internal controls, then the users of the domain can blame
the domain owner.
I guess there can also be issues where two distinct domains share the same
outbound IP addresses, through an email service provider. In that case, the
email service provider is the responsible party that needs to be held to
account. They need to ensure either (a) separation of domains by outbound
IP address combined with accurate SPF records, or (b) proper implementation
of MSA on all the domains that they provide service for.
Backscatter is a problem, but bounce messages do have advantages over 5xx
error codes when it comes to communicating with the sender. For example,
you can't know what the sending MTA is going to do with a 5xx error code -
they might just drop it. DSNs were invented for a reason, and it's a shame
to lose them entirely - even when you have reason to believe that the
return-path (or at least the return-path domain) isn't forged.
---Rsk
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg