On Tue, 30 Aug 2005, Philip Hazel wrote:
> On Sat, 27 Aug 2005, Steve Lamb wrote:
>
> > Yes, I get we're talking about mail which hits the
> > server and then is, I dunno, REDIRECTED to another address elsewhere. However
> > that mail is eventually read by, hmmm, A CLIENT. That means the terminology
> > of calling it a forward is misleading. Forwarding doesn't break.
>
> At the risk of getting caught up in this flame war...
OK. I'll be courageous too. :^)
>
> As far as I can see, forwarding DOES break. Suppose a server A sends a
> message from domain X to a server B, which is not configured to use SPF.
> Server B accepts the message, but the user at server B forwards the
> message to server C. Server C is into SPF, so it checks to see if server
> B is permitted to send messages from domain X; it isn't, so server C
> rejects the message. I call this broken.
Yes, for forwarded messages. But it's useful for non-forwarded
messages, and I think these are detectable.
If the message is forwarded mail, then on the final destination
machine, the $recipients (which ought to be only 1 in the case of
phish because phish tries to look personal) is not on the To: header.
So, if the message soft-or-hard-fails SPF we are safe:
1. rejecting in ACL_DATA if the To: header contains the one address
in $recipients, because it wasn't forwarded.
2. or, blackholing in the routers if $local_part@$domain is in the
To: header, because it wasn't forwarded.
Also, possibly, if I invite my customer to give me a list of the
addresses he forwards mail from, and, if one of those addresses is on
the To: header, then I can feel confident about parsing the top
Received header for the sending IP and checking that against the SPF
record. Possibly?
>
> > Now here's where you need to catch up. Bouncing/redirecting, either at
> > the server level (which is what you're talking about and I fully understand in
> > spite if your inability to grasp it) or at a client level... and read this
> > part carefully Tony as it's the part you are failing to grasp... is an
> > antiquated notion that could probably be done away with due to the realities
> > of modern clients which are fully capable of pulling from multiple sources
> > and... and (here's the amazing part) keeping those sources separate!
>
> I'm afraid you haven't considered the inertia of users and software. Not
> everybody uses a "modern client". Not everybody can set up their clients
> to do fancy things like pull from multiple sources. Not every source
> allows "pulling" (the system on which I do my email does not; I have to
> ssh login to it). "Doing away with" anything in the computing world
> usually takes a very long time indeed. Backwards compatibility is a
> great drag on progress, but we have to honour it.
>
> It is very common in the academic world in which I operate for people to
> set up email forwarding; students forward to their hotmail accounts,
> staff forward their email when they are visiting somewhere else for a
> year or a term, etc. Anything that stops this working is not going to
> be adopted in a hurry.
>
> Your "access multiple sources" solution also does not work when somebody
> moves employment and the company they are leaving is prepared to forward
> their email, but not to allow them to retain a local mailbox. And even
> if they do, if you've worked for 10 companies do you want to have to
> look at 10 mailboxes everytime you walk into an Internet cafe when you
> are travelling?
>
Yes. Another point, however, is that, for your bank, you might want
to give (just) them your unforwarded email address, or an address that
forwards from a system does rely on SPF, ... or you'll get phish
unless it is caught via some other mechanism. It's something to
suggest to customers who get phish forwarded to them.
So, unless someone has something specific to and technically valid
against these particular observations, SPF seems useful enough to not
deserve the treatment it gets here.
Disclaimer: I have nothing to do with SFP ... yet. It's just theory
for me.
Ready with my asbestos suit,
Marilyn Davis
>
--
