----- Original Message -----
From: "Andy Bakun" <spf(_at_)leave-it-to-grace(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, December 05, 2004 10:33 AM
Subject: Re: [spf-discuss] Re: RFC 2821 and responsibility for forwarding
On Sat, 2004-12-04 at 17:02, Frank Ellermann wrote:
Andy Bakun wrote:
The problem with forwarding is not forwarding within an
organization, it's re-injecting the mail back into the
Internet.
That's true, but from the sender's POV that's none of his
business, he can't do anything about it in a sender policy.
I know, we're talking about forwarders, not senders.
is it reasonable to expect big email providers will have
what amounts to B2B help desks for getting mutual trust
relationships setup?
Not sure, but the original sender isn't in the position to
do anything about it, so that's something the receiver and
his providers (forwarder and final destination) must solve.
The sender is busy with figuring out MSAs and RfC 2476 ;-)
I know, we're talking about forwarders, not senders.
My message wasn't in the context of senders, and neither was
<41B1AABC(_dot_)239A(_at_)xyzzy(_dot_)claranet(_dot_)de>, which is what I was
responding to.
This entire thread is about forwarding and forwarders, hence the
subject. Is this some kind of round-a-bout way to suggest that this
thread is off-topic because it doesn't specifically mention "sender
policies"? I thought this thread was on-topic, as "what is SPF going to
do about forwarding" directly relates to SPF.
Just a small comment here -
Surely a forwarder *is* a sender - he receives an e-mail and re-injects it
into the system - with various manglings of the headers according to his
whim. The re-injection of an e-mail is "sending" an e-mail - therefore he
is a sender.
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.
There seems to be a discussion point about how "friendly" we have to be to
forwarders, and *that* is perhaps the real debate here. How long do we
accomodate bad configurations of all sorts of things, and the answer is
surely simple - until those bad configurations cause the rest of the
world-at-large as serious problem. Well, we now have a serious problem -
it's called spam, and those people with bad configurations should be doing
something about it. If they don't, which would be from their own choice,
they are left out in the cold along with the spammers. The choice is
theirs.
IMHO our job is to evangilise the solution to forwarding/resending. The use
of the "correct" method to re-inject mail so that it passes SPF checks at
the next recipient. It's so easy to do it's ridiculous, so they really have
no excuse.
Bounces are the responsibility of the sender/resender - and have to be
"reflected" back to the originator of the mail is it isn't delivered *to the
address the originator used*. That means if I have an address at gmail
which is forwarded to my personal domain on my own MTA, incoming mail
addressed to me at gmail, which at fails the gmail checks will bounce to the
originator, but a failure between gmail and my domain on my MTA will bounce
to gmail *only*. The originator sent it to gmail and it was received
successfully, so no bounce there, the fact that my own domain's mailserver
was down and didn't get the forwarded mail is *my* problem, and I wouldn't
want to trouble the originator with a bounce. I daresay that
resenders/forwarders could have an option to pass bounces back to the
originator, but it would be an option only, *not* a standard.
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492