spf-discuss
[Top] [All Lists]

Re: SPF Forwarding Scenario

2005-04-11 10:39:36
Stewart,

Thank you for your feedback. I suppose I missed a detail or two in my scenario, sorry.

No, the original machines do not relay from untrusted sources - as you pointed out, that would be an open relay and obviously a very bad thing for the server operator.

In my scenario, a spammer actually constructs a header claiming to be the machine after the source sender, where they purport to have received the spam message from the victimized source - basically they determine the original MTA for the source victim's domain and include it as an in line received from prior to their send. In this way, it looks for all the world that the original sender was the SPF checked domain.

It would seem that perhaps it is appropriate to have an SPF syntax which can announce to end receiving MTAs that the original domain does not forward (except within the include: ), if SPF does not actually offer that today as part of the spec.

While this list has spent a great deal of time on how to accommodate forwarder scenarios (which is obviously an important topic needing discussion), it seems the heart and soul of SPF is to prevent domain fraud and misuse by identity theft. If that is still true, then how exactly can an SPF publisher announce that they do not forward beyond their SPF PASS servers, such that the final receiving SPF aware MTA can discover this and both block the message before it is sent to the end recipient and block sending the bounce back to the original sender whose information was fraudulently added to the message header?

Best,

Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


At 01:24 PM 4/9/2005, you wrote:
On Sat, 9 Apr 2005, Commerco WebMaster wrote:

> Given the txt records listed above, if the final receiver's MTA implemented > SPF properly, would it be able to realize that domain.tld would not forward
> via spammer.tld and thus would avoid making an attempt to deliver to a
> local user at 10.111.111.1 and not bounce from their end back to 10.10.10.4?

Short answer: No

Long answer:

Normally, "Forwarder" refers to an alternate email address setup by the
recipient, which forwards mail to another mailbox.  The setup you described
is an "SMTP service" for the sender.  If the SMTP service has no restrictions
on who can relay mail through their service (open relay), then you would be
better off with no SPF record at all - and most of the world will have that
service blacklisted, so good luck sending mail.  If the SMTP service is not an
open relay, then they will have some controls on who can relay: perhaps only
allowing authorized IPs, or perhaps requiring SMTP AUTH.  In that case, the
spammer would
NOT be able to relay through the SMTP service.

To round out the discussion, suppose there is a real forwarder set up
by the recipient.  This forwarder must check SPF before forwarding anything,
or else any mail sent to the forwarded address can forge any sending domain.
If the recipient checks SPF, and the forwarder publishes SPF, and rewrites
the MAIL FROM with SRS, this confirms that the mail really came from the
forwarder.  It does not, however, verify the original domain.  The forwarder
should have done that.  If a forwarder does not publish SPF, then the
recipient can trust that forwarder based on IP address, HELO name, or
whatever the forwarder provides that is verifiable.  But if the forwarder
does not check SPF, then mail to the forwarded address can still be forged.

In some cases, it is possible for the recipient to sort of check SPF
based on the Received header from the forwarder.  However, this is subject
to all the problems associated with "after SMTP" SPF checking.

Duh - I am tired of seeing critics point out that SPF is broken because
mail can be forged if a forwarder doesn't check SPF.  It doesn't help
that the supposed poster child for SPF forwarding - pobox.com - doesn't check
SPF by default.

--
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com




<Prev in Thread] Current Thread [Next in Thread>