Re: [spf-discuss] Is this Network Abuse? (from Fixing Forwarding with RP

K.J. Petrie (Instabook) wrote:
> On Friday 17 November 2006 00:43, Claire Campbell wrote:
>   
> > 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.
> >
> >
> >
> >     
> Yes, but blame should really be attributed on the basis of IP addresses, 
> though I appreciate not everyone realises that. For most people E-mail is a 
> form which opens when they click "New" in their client. That's why I'm so 
> unhappy when spammers spoof mine, (especially if the DSN contains enough 
> information to let me know I'm a victim of forgery but not enough to enable 
> me to report it) but I don't want a remedy which wrecks the system. I want 
> one that works with the standard, not against it.
>   
The problem with attributing blame on the basis of IP addresses is that 
the punishment is then extended to others sending mail from the same IP 
address, who have no relationship whatsoever with the person/forwarder 
responsible for creating the problem. Most ISP's do attribute blame on 
the basis of IP addresses. However, most recipients will simply blame 
(or blindly trust) the address that is displayed to them as the sender.  
For us SPF is a nice and simple solution to this problem.     
> I do think it's odd forwarders don't use the kind of opt-in confirmation 
> mailing lists use. I suppose it just hasn't been such an issue because 
> pointing another address at someone's mailbox isn't such an attractive attack 
> vector as signing them up to an irrelevant mailing list. But you're right, 
> they really ought to check the recipient is happy to accept the forwarding 
> and not activate the forwarding until they've received confirmation. It just 
> hasn't become the convention, unfortunately.
I would consider this kind of zero authentication/zero accountability 
forwarding a perfect vector of attack if I belonged to the trilogy of 
spammers/phishers and virus writers.

Claire



-------
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