On Wed, 17 Apr 2002, Matthew Byng-Maddick wrote:
> 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.
It is not the postmasters job to fix addresses mistyped by incompetent
boobs. If you want your mail to go through, use the correct address.
> > 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.)
>
Ah, but that RFC talks about a different Internet, where MUA's ran on
multiuser machines which automatically enforced correct return-path, and
before people were trying to sell everything from weight loss cream to
ways to MAKE MONEY FAST by email.
These days, "if the delivery of such a notification fails, that
usually indicates" that the message is spam, or, less frequently, a
user-configuration error. For this reasons, there is the
ignore_errmsg_errors option, which gets this crap off your mailqueue
without wasting your time.
> 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/
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>
--
