K.J. Petrie wrote:
Or could it be an "NA" issue? For if I understand you correctly, you
are saying people publish FAIL not to reject mail originating from
spam/virus-type forgers, but to cause service denial to those using
forwarders which comply to the current version of SMTP, rather than a
previous, now deprecated version, which they think was better. Now
we may not agree with the current standard, but trying to force
change by denying service to innocent third parties who are using
standards-compliant systems is sabotage against the network.
Moreover, I'm not convinced that this has been explained to everyone
who publishes FAIL. I suspect some are being drawn unwittingly into
this attack in the belief publishing FAIL will protect them against
on-line identity theft, unaware they are being used as pawns in a
calculated form of Internet terrorism. If not following the
deprecated parts of RFC 821 can be called forgery, don't you think
engineering a protocol to break RFC 2821-compliant mail systems could
be described as network abuse?
This raises my proposal from a functionality fix to a security
consideration and makes it more urgent, if SPF is being used as an
attack vector against standards-compliant systems.
"..Being used as pawns in a calculated form of Internet terrorism...."
I beg to differ
We operate an opt in mailing list and mail forwarding has the potential
to causes problems for us that are not related to SPF but where SPF can
help. As far as we are concerned, the recipient has subscribed to our
service using an e-mail address that we have authenticated during the
sign up process as being valid and belonging to them. Once it is
forwarded on to a different address this process is devalued and open to
abuse for which we may be held accountable. If anything can be used as a
"vector for attack" I would suggest it is mail forwarding.
To give you just a couple of examples of the problems that forwarding
can create for us:
1) When the destination address it is being forwarded to is/becomes
invalid, the e-mail is returned undelivered to us. The non
delivery report does not always contain the e-mail address it was
originally addressed to, leaving us with no way of establishing what
user account this secondary address relates to in order to remove it
from our mailing list. However, failure to do so could result in any
future mail to that ISP being blocked.
Even worse, if the e-mail got delivered to a valid address belonging to
an entirely different person, due to a typo error in the final
destination address, it would have the potential to become a data
protection issue, quite apart from any annoyance caused to the recipient
of these unsolicited e-mails.
2) Our users do not always own the e-mail accounts they are forwarding
to and therefore do not have the consent of the owner to forward the
contents of their mailbox to that address. Of course the ISP that
provides them with the facility to forward mail without verifying that
it actually belongs to them is at fault here but I don't think this is
altogether uncommon - we were able to do so with our last (quite big +
not cheap) ISP. The end result is that some of our subscribers will
think nothing of forwarding all of their mail to the e-mail account of
the ship they are working on, leaving their employer's to pick up the
tab for downloading a significant amount of (mostly spam) mail via a
satellite connection. If no SPF checks are carried out it is conceivable
that in addition to the few solicited e-mails from our domain, they may
pay to download many others forging our domain as the sender due to the
combined effects of e-mail address harvesting and infected user systems.
It is not difficult to see how we could land up getting the blame for
user decisions over which we have absolutely no control. What makes this
potentially worse in our situation is that the owner of the unauthorised
destination address could be a client or potential client of ours.
So, whilst I can understand how SPF checking can cause difficulties to
some domain owners in your situation, there are other (equally
small)domain owners, like ourselves, who have legitimate reasons for not
wanting to be held accountable for mail that is forwarded to addresses
whose ownership and validity we have not been able to authenticate.
Claire Campbell
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735