----- Original Message -----
From: "Andy Bakun" <spf(_at_)leave-it-to-grace(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 06, 2004 2:30 AM
Subject: Re: [spf-discuss] Re: RFC 2821 and responsibility for forwarding
On Sun, 2004-12-05 at 18:39, Nico Kadel-Garcia wrote:
> And yes, this is important. The forwarding machine may be allowed to
> send
> a message authored by me, it may not pretend to >be me< while sending.
Perhaps, but this is how email reflectors (or more commonly known as
forwarding) works right now. Saying "it may not do this" has nothing to
do
with what you, as a sender of email, desire. It has to do what what the
recipient desires to have happen to his email. You as a sender have
little
to no control over this.
If original senders have little to no control over what forwarders do,
then your response immediately after the above doesn't make much
sense...
The forwarding machine is the problem of the recipient. You as the sender
have little control over it.
The author/original-sender can not fix anything that is an issue with
the forwarding. In the forwarding setup:
a(_at_)author -> b(_at_)forwarder -> c(_at_)recipient
it's not a(_at_)author's fault or mistake if:
* c(_at_)recipient's mailbox is over quota
* b(_at_)forwarder put c(_at_)misspelleddomain in their .forward file
* c(_at_)recipient doesn't exist
* recipient is down or inaccessible
* c(_at_)recipient is no longer a valid mailbox
* c(_at_)recipient mailbox or recipient domain is not accepting mail
from b(_at_)forwarder or forwarder domain.
* a DSN generated after b(_at_)recipient has accepted the mail with a
2yz response code.
And you expect b(_at_)forwarder to do anything about it? In most cases, there's
nothing broken about the forwarding itself, it's the c(_at_)recipient setup
that's broken. The only one where b(_at_)forwarder might do anything useful is
the misspelleddomain example, and that's more likely to be fixable by
a(_at_)athor contacting the person out of band.
No, this is what SES and SRS are for: they make sure that all these broken
messages can get back to a(_at_)author, who is the one who needs to know about
it. It's not usually b(_at_)forwarder's problem to deal with.
I don't think we're that far from agreement here in the underlying issues.
At the very least, a(_at_)author needs to be notified that mail they sent was
undeliverable, so they can communicate through alternative channels if
need be and email doesn't get lost in the system, but none of the normal
"legitimate cases" for DSNs after b(_at_)forwarder has accepted a(_at_)author's
message for delivery are the fault of a(_at_)author(_dot_) In none of the above
cases can a(_at_)author do anything, other than contact, out-of-band, the
actual person they are trying to send email to and tell them they can't
do it.
Of course a(_at_)author can do something about most though not all of these
cases. They can check the typing of the email address, cross the namem off
their list of contacts, try sending a smaller message, wait a few hours to
send again, or do any of the things we normally do to get our email through
when initially balked. Some of them are out of band.
They're often, though not always, in a wildly better position to act on it
than is b(_at_)forwarder(_dot_) And they're the one who needs to know that their email
bounced.
In many, if not all, of the above cases, the forwarder CAN and SHOULD do
something about the DSN, if they want forwarding to actually work. Part
of the problem here, though, is that there is no-one to actually READ
b(_at_)forwarder's email, because it all gets forwarded to
c(_at_)recipient(_dot_) Some
of these issues are postmaster(_at_)forwarder or postmaster(_at_)recipient's
responsibility. But they are not a(_at_)authors(_dot_)
But b(_at_)forwarder doesn't normally have the resources. I've been
postmaster(_at_)forwarder for something like 20 years, and I've never had the
time or resources to deal with all those cases. It's just been established,
from the bounce message, that c(_at_)recipient can't get the email, so forcing
b(_at_)forwarder to go out of band to contact c(_at_)recipient is a very unreasonable
burden. They're especially unlikely to have the contact information if they
allow their b(_at_)forwarder users to arbitrarily set c(_at_)recipient addresses.
I fully acknowledge that SOMEONE MUST see the DSN, and it makes sense
for the original sender/author to see it (even though they can not
necessarily do directly do anything about it), mainly because that's how
the system has traditionally worked. But if someone has configured
forwarding it should be their responsibility to get the DSN to the right
place by taking responsibility for the act of forwarding, rather than
just re-injecting the mail into the Internet and forgetting about it.
Well, yes. This is why I'm pushing SRS and SES.