[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Garbage collect SENDMAILBUG code
From: |
Ralph Corderoy |
Subject: |
Re: [Nmh-workers] Garbage collect SENDMAILBUG code |
Date: |
Thu, 01 Jun 2017 10:43:48 +0100 |
Hi Ken,
> * It appears that some versions of Sendmail will return Code 451
> * when they don't really want to indicate a failure.
> * "Code 451 almost always means sendmail has deferred; we don't
> * really want bomb out at this point since sendmail will rectify
> * things later." So, if you define SENDMAILBUG, Code 451 is
> * considered the same as Code 250. Yuck!
...
> I think this is long-obsolete, and I propose we remove it.
> Objections?
Nuke.
RELEASE_NOTES from
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.15.2.tar.gz
has
8.7.2/8.7.2 1995/11/19
An SMTP RCPT command referencing a host that gave a nameserver
timeout would return a 451 command (8.6 accepted it and
queued it locally). Revert to the 8.6 behavior in order
to simplify queue management for clustered systems. Suggested
by Gregory Neil Shapiro of WPI. The same problem could break
MH, which assumes that the SMTP session will succeed (tsk, tsk
-- mail gets lost!); this was pointed out by Stuart Pook of
Infobiogen.
This suggests sendmail never really had a bug and it was MH that
couldn't cope with a 4xy response and retry, so used to pretend it got a
2xy? "Yuck!"
There's a more recent mention of MH in the file. (None of "nmh".)
8.14.8/8.14.8 2014/01/26
A new mailer flag '!' is available to suppress an MH hack
that drops an explicit From: header if it is the
same as what sendmail would generate.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy