On Sun, 20 Feb 2005, David MacQuigg wrote:
I tried to make the point that it is impossible to forge a domain name when
sender and receiver both use SPF, and I challenged anyone to send me an
email at pobox.com with a forged name 'forged at amazon.com'. The email
came through!! At the top was the following header:
Return-Path:
<SRS0=ekIn=RC=amazon(_dot_)com=forged(_at_)bounce2(_dot_)pobox(_dot_)com>
This is very disturbing. I thought pobox.com would be a fine example of
how to set up a forwarder. If a forwarder doesn't actually do the
authentication, it shouldn't add this header, and most certainly not with a
forged domain name!!
Can anyone suggest a better way to do this demo?
It looks like pobox.com does not reject SPF FAIL. You should confirm this
by running SPF against the IP in the Received header from pobox.com. Until
pobox.com rejects SPF failures, they should not be a trusted forwarder. Did
you check whether pobox.com adds Received-SPF headers even though they don't
block SPF FAIL? If so, you could block failures yourself. Otherwise, you'll
have to blacklist pobox.com, since implementing SRS without also blocking SPF
FAIL creates an open relay for all practical purposes.
This is something the detractors of SRS have predicted would happen. But
it is not really the fault of SRS, but of a halfway implementation.
Apparently, people are afraid to reject SPF FAIL because the sender
might have screwed up their SPF record. Well, duh, the best way to
find out about your mistake is to get nice clean 550 rejections as early
as possible.
Ironic, considering that employees of pobox.com were instrumental in
creating SRS.
--
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.