|
Re: SPF Forwarding Scenario
2005-04-11 11:07:55
SRS and SES are solutions to this issue. Much discussion of pros and
cons of each are in the archives.
Terry
Commerco WebMaster wrote:
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
-------
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
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085
|
|