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 entity is responsible for the message and should receive
the bounce, not the author of the message.
Nope. In most legitimate cases they can't or shouldn't even try to do
anything about it, and it's the original sender's mistake or problem to fix.
They didn't send it, they don't want to know what's in it, they're just
politely passing it along.
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.
<scarasm>How dare a(_at_)author risk mailing whoever c(_at_)recipient is THROUGH
b(_at_)forwarder, even though doing so is exactly what c(_at_)recipient WANTS
a(_at_)author to do!</scarasm> In many cases, a(_at_)author doesn't even know
that c(_at_)recipient is the final destination.
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.
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_)
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.
Andy.