----- Original Message -----
From: "Vivien M." <vivienm(_at_)dyndns(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, November 18, 2004 11:11 PM
Subject: RE: [spf-discuss] Electronic Frontier Foundation (EFF) Article On
Anti-Spam Technologies Mentions SPF
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Mark
Sent: November 18, 2004 4:37 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Electronic Frontier Foundation
(EFF) Article On Anti-Spam Technologies Mentions SPF
Most certainly not. If you have not authorized your friend's
pc to relay mail on behalf of your domain name, and you
published "-all", then SPF rejected your message for the
exact right reason. In fact, you should worry if SPF had done
something else.
If that scenario bothers you, then either publish "?all", or
include your friend's pc in your set of authorized relays.
I need to send a message urgently. It's really important.
Then use SMTP AUTH (preferably on port 587). Then you can
connect to your OWN relay, from a remote location, and get an
SPF "pass" because of being authenticated by a trusted mechanism.
I ask to send a message from their pc, and set the
rfc2822.From field
to be my actual email address.
In short, you did precisely what SPF is supposed to prevent:
domain spoofing in MAIL FROM (assuming your friend's relay
did not rewrite your envelope-from to a 'local' SRS domain).
And SPF caught you doing it. Rejoice! This is what you wanted
(according to your published policy).
And, once again, all of the pro-SPF advocates are absolutely ignoring the
key point here, which I made repeatedly about a year ago and, given that
it
would be easier to convince the nearest brick wall about this than the
members of this list, I eventually shut up about :)
What you're saying works very well, for a SMALL domain where the person
needing to 'spoof' controls the SPF record and/or the mail servers listed
in
it. That's great, put ?all, include the other places you may go to (e.g.
your employer, relatives, educational institutions, whatever) and send
mail,
and go on with life.
The problem comes when you're dealing with large organizations where some
IT
department (or ISP helpdesk) sets a -all policy, and you're too far down
on
the organizational hierarchy to do anything about it. (If you're the CEO,
you can call up the IT manager and be like "WTF is this SPF crap that
prevented me from sending email from the golf course?!?!? I WANT IT GONE
NOW")
Those individuals are constrained to using their email addresses in the
way
that this IT department or ISP wanted their domain to be used. The blindly
pro-SPF crowd with whom I (and others) argued last year will say "Tough
luck, you little spoofing SOB, you're using their domain, you play by
their
rules". But there are SO many 'grey' areas where people, especially those
without the technical background to understand the spoofing issues, will
be
hampered by this:
- the gazillion "send a <whatever> to your friend" web sites
- Mr. Crocker's scenario (aka "set up your IMAP account on some random
machine to send a few msgs and whoever hosts the account doesn't provide
SMTP AUTH")
- anybody else without SMTP AUTH accessibility to their domain (e.g.
people
working at home for an organization not providing SMTP AUTH, people
roaming
using a different ISP from theirs that doesn't provide SMTP AUTH, etc)
Surely an organisation which is big enough and sufficiently aware to publish
SPF records, could easily set up an SMTP-AUTH facility for it's people.
Either that or a simple web-based mail system - even *I* have built a simple
one of those - dead easy.
You appear to be speaking from some experience of this problem, but it has
to be borne in mind that the problem for the world is forged mailfrom: ,
that being a large amount of spam.
Given that mail nowadays has to *prove* that it is *not* spam, I think
there's going to be a lot of changes in the modus operandii of such
organisations as you describe.
If the IT manager is unable to cope with this - maybe he needs shouting at
;-)
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492
Those are things that work today, and those are things that the average
people on the street (aka, the people on whom at least some people on this
list depend for their paycheck) expect to continue working. They won't
understand that the greeting card from Aunt Mary who works at blah.edu
can't
be showing up as being from AuntMary(_at_)blah(_dot_)edu anymore (if you're
doing RFC
2822 checking) because there's a bigger spoofing problem to be solved.
Etc.
Yet, everybody on this list who will defend SPF to the death continues to
dismiss this as "they're spoofing and need to change their ways. The SPF
train must go on". It's not that simple in the real world, especially if
you're a third party. (E.g. you helped Aunt Mary use her blah.edu email
from
home using joeisp.net years ago, and now blah.edu publishes -all and Aunt
Mary yells at you when her email becomes broken. What do you tell her if
blah.edu doesn't provide an off-campus SMTP AUTH service and Aunt Mary
isn't
high ranking enough to make the IT dept set one up?)
Vivien (who, as usual, is speaking only for himself...)
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
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