Milter-greylist

After just updateing to FBSD-4.11, I was reviewing the DOCs on
sendmail-8.13.1 now in the base system and noticed this:

[...]Do not use 4.7.1 as enhanced status code because
some broken systems misinterpret it as a permanent error.[...]

So, was wondering why milter-greylist uses that???

Feb 15 08:49:50 sage-american sm-mta[97500]: j1FEnmoT097500: Milter:
to=<jack@...>, reject=451 4.7.1 Greylisting in action, please come
back later


Happy trails,
Jack L. Stone

System Admin
Sage-american

On Tue, Feb 15, 2005 at 08:57:49AM -0600, Jack L. Stone wrote:
> [...]Do not use 4.7.1 as enhanced status code because
> some broken systems misinterpret it as a permanent error.[...]
> 
> So, was wondering why milter-greylist uses that???

Because nobody ever read that doc here. What error code do you suggest?

-- 
Emmanuel Dreyfus
manu@...

> > [...]Do not use 4.7.1 as enhanced status code because
> > some broken systems misinterpret it as a permanent error.[...]
> > 
> > So, was wondering why milter-greylist uses that???
> 
> Because nobody ever read that doc here. What error code do you suggest?

The sendmail authors switched from 4.7.1 (transient error, security or
policy status, delivery not authorized) to 4.3.2 (transient error, mail
system status, system not not accepting network messages).

Details of enhanced status codes are in RFC 1893; while 4.7.1 is
technically correct, making the remote system think 4.3.2 applies is
friendlier to broken MTAs and shouldn't affect spamware significantly.
It might actually help since 4.3.2 as an enhanced status code is valid
for reasons other than anti-spam filtering (e.g. system load too high
to accept mail) and 4.7.1 is pretty much restricted to anti-spam
measures.

--
Dawn Keenan, IST, University of Waterloo

Dawn Keenan <dkeenan@...> wrote:

> The sendmail authors switched from 4.7.1 (transient error, security or
> policy status, delivery not authorized) to 4.3.2 (transient error, mail
> system status, system not not accepting network messages).
> 
> Details of enhanced status codes are in RFC 1893; while 4.7.1 is
> technically correct, making the remote system think 4.3.2 applies is
> friendlier to broken MTAs and shouldn't affect spamware significantly.
> It might actually help since 4.3.2 as an enhanced status code is valid
> for reasons other than anti-spam filtering (e.g. system load too high
> to accept mail) and 4.7.1 is pretty much restricted to anti-spam
> measures.

Right. Anyone wants to contribute an smtpcode option for the config
file? Something such as this:

smtpcode "451" "4.3.2"

Easy to code, useful for everyone.

-- 
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...