On Wed, Apr 17, 2002 at 08:47:12AM -0700, Tom Samplonius wrote:
> On Wed, 17 Apr 2002, Matthew Byng-Maddick wrote:
> > Erm, I'm sorry!?!? Do you run anything even remotely approaching a reliable
> > mail service? do you claim to? A human should look at bounced bounces and
> But in a double bounce case, there is no way to determine a delivery
> point, so how is a human supposed to fix this? I know it is a great way
well, it's pretty clear to me that xxx-teens-9478561@??? can go
straight in the bin, but <some potentially plausible localpart>@homtail.com
might be trivially switchable, or you may be able to mail to the appropriate
postmaster at the remote site.
> to justify admin time and bulk up staff, but it is valueless work. You
> are simply not going to get though messages through to anybody.
I'd certainly disagree that it's valueless, an admin may not know that he's
made a mistake in some configuration somewhere if everyone threw away all
their bounced bounces. If he is legitimate and not a spammer, then it's
quite possible to make mistakes.
> > And reliable as a chocolate teapot.
> 100% reliable for messages with at least a valid recipient or a valid
> sender.
Robustness Principle. If you didn't want to take responsibility for it at
SMTP time, that's different.
> > It pains me to see the number of people who don't take mail delivery
> > seriously, and I wonder why the standards even exist when people flout
> > them so blatantly.
> Hah! It isn't part of the standard for humans to examine double
> bounces!
True, but it's mentioned as something they consider sensible:
RFC2821 S4.5.5
| (If the
| delivery of such a notification message fails, that usually indicates
| a problem with the mail system of the host to which the notification
| message is addressed. For this reason, at some hosts the MTA is set
| up to forward such failed notification messages to someone who is
| able to fix problems with the mail system, e.g., via the postmaster
| alias.)
What they do say is that you take your responsibility to deliver the message
or the bounce *seriously*, which, to me, means doing everything you can to
make the end users aware that their message failed, if it didn't get through.
I'm happy with rejecting stuff at SMTP time and it never being my problem,
but once you've accepted it, you ought to take it seriously rather than just
dropping it on the floor because it has double bounced, where possible.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
