On Mon, 2004-12-06 at 06:27, Nico Kadel-Garcia wrote:
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.
In most cases, b(_at_)forwarder and c(_at_)recipient are logically the same
person, or at the very least have a stronger relationship to each other
than either has to a(_at_)author(_dot_)
I don't think we're that far from agreement here in the underlying issues.
Neither do I.
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
This is the one I don't understand. If a(_at_)author mistypes b(_at_)forwarder,
the email will never be received at b(_at_)forwarder, so b(_at_)forwarder's
forwarding setup will never come into play. Regular DSNs would come
into play (unless the mistyped address actually exists, and performs
forwarding, and has forwarding issues -- either way, these are outside
the scope of b(_at_)forwarder's setup).
, 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.
Of course, the first party to actually DO something is a(_at_)author, once
they receive the DSN. But putting on my pragmatic hat, a(_at_)author just
tells c(_at_)recipient out-of-band that mail is not getting through. "Some
guy named 'Mahler, Damon', uh Damon Mahler, sent me a message saying
something about being out of quota, whatever that is, I think I sent too
many message today or something. So I can't send you that report, I'll
try {insert favorite email alternative here}." It's c(_at_)recipient that
needs to do something to the configuration of b(_at_)forwarder or contact
someone @forwarder to get it fixed or get c(_at_)recipient receiving email
again.
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.
Agreed. I think we are using slightly different definitions of
"responsibility" and are talking past each other. Really, I'm focusing
on responsibility for forwarding on b(_at_)forwarder such that it is the
b(_at_)forwarder's job to see to it that a(_at_)author gets the DSN. With SRS,
that happens automatically, so really the person behind b(_at_)forwarder
(which may be c(_at_)recipient) or the help-desk or postmaster @forwarder has
nothing to do. There is also the responsibility for getting the problem
fixed. This falls squarely on the shoulders of parties other than
a(_at_)author once a(_at_)author has done the job of notifying c(_at_)recipient
that
things are not working -- ALL a(_at_)authors have to do this, it is the
default if they actually want email to work, the variable part is what
happens after that. I drop a letter in the postal mail to you and the
postal service picks it up and tries to deliver it. You recently moved
and notified the post office of your new address, which happens to be
undeliverable. The letter comes back to me, I call you and say that I'm
having trouble sending you something, it came back because your new
address couldn't receive it. You have to contact the post office and
figure out what is wrong. Imagine the conversation had I contacted the
post office:
"Hi, I'm trying to send this letter to Nico Kadel-Garcia at 1234
Anystreet, Anytown, but it keeps coming back."
"Mmmh, lets see here. Our records show that we're having
trouble delivering mail to his forwarded address 4321 Nostreet,
Notown. Not much we can do about it until he tells us what he
wants us to do."
Quite ineffective.
(although this may be a questionable analogy -- I believe the postal
service in the US may just deliver it to the old address, and consider
it delivered. This is acceptable because the final recipient would know
to somehow check his old address for any missed mail).
Andy.