spf-discuss
[Top] [All Lists]

Re: Re: RFC 2821 and responsibility for forwarding

2004-12-05 06:30:56
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>


That is not exactly so. Its always been a debate of SMTP experts if
forwarding is reinjecting or not and everyone is still devided. But
majority currently believe that automated forwarding does not constitute
reinjecting and forwarder is not a sender but intermediate transfer
agent. I personally decided to call such systems Mail Redirection Agents
to emphasise that they are changing course of email transmission
and its being done in automated way.

I have never understood why forwarding is such a problem - it is in the
hands of the receiver.  Anyone (even me) can set up various MTA's (my
ISP
maybe) to forward mail to them - and in doing so the responsibility for
ensuring that the mail is correctly sent on to the recipient falls fair
and square on the recipient.  It's the recipients decision to have his
mail forwarded/resent, so it's up to him to get it right.

You're forgetting that we have large installed base of such redirection
systems and while it maybe recepient's decision to forward the email and
their responsibility, because we're changing how email works, we end up
changing what they need to be responsible for.

So this means that we have a large infrastructure built on mistaken
foundations - that forwarding is not re-sending.  :-(


They are not bad configurations, they are perfectly well working
configurations right now. We're asking them to change for greater
good of making email more traceable and less vulnerable to spofing
of bounce message. We did ask people to change how email works once
- that is to close open relays, and it was a big deal back then but
at least then people undertood that open relays is a security issue,
they do not see it the same way for forwarding.

Understood - but I still favour "fixing" forwarding by making it compliant
with the concept of re-injecting mail ito the stream.


Well, we now have a serious problem - it's called spam,
SPF is NOT solution to spam!
Putting accreditation and repution on SPF is at best problematic
and is not a main goal of SPF community anyway.

Yea, yea - we all know that - and it's not what I said.

As an interesting note on this topic, my mail comes direct to my MTA
(Sendmail) on my own box, and I got a mail from my sister-in-law in Canada
with these headers (well, these relevant bits) -

Return-Path: <my_sister-in-law(_at_)ica(_dot_)net>
Received: from modus.ica.net (mail.ica.net [209.151.129.144])
 by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id iB4MBFW07628
 for <jpinkerton(_at_)argyllnet(_dot_)co(_dot_)uk>; Sat, 4 Dec 2004 22:11:15 GMT
Received: from hal (unverified [209.151.131.11]) by modus.ica.net
 (Vircom SMTPRS 4.0.330.8) with SMTP id 
<B0169823018(_at_)modus(_dot_)ica(_dot_)net> for
<jpinkerton(_at_)argyllnet(_dot_)co(_dot_)uk>;
 Sat, 4 Dec 2004 17:01:24 -0500
Message-ID: <000701c4da4c$d53c8760$0b8397d1(_at_)hal>

So, unless I am mistaken (which is always quite possible) this mail was sent
by my sister-in-law to hal (unverified [209.151.131.11] and *not* a FQDN but
presumably is her ISP) and they forwarded it to modus.ica.net before they
forwarded/resent it to my MTA (miranda.server-plant.co.uk).  This forwarding
is not in my control and I don't want it to happen - so what to do?

Or am I reading these headers standing on my head?  ;-)


Slainte,

JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492