[Greylist-users] relaydelay, TEMPFAIL and Sendmail 8.13.x

[Jim Miller]

Hello everyone,

For months now I've been using relaydelay-0.04 with out any issue (that I
was aware of) and have been very happy with it's performance.  However,
recently I made the mistake of improperly, manually, adding a record to the
relaytofrom table to whitelist a new VPN subnet.  After doing one additional
record was created and no more.  It just kept writing over the same record
over and over.  A couple of days later I reset the server and after that a
majority --NOT ALL-- but a large number of mail began being TEMPFAILed and
the sending SMTP servers (including SMPT servers on the local LAN) only
attempted to re-deliver the messages a few times (that I can tell from the
log files) and then stopped.  Unfortunately the problem began on a Friday
afternoon and wasn't noticed until Sunday afternoon.

I'm not an SMPT guru but I thought most SANE smtp servers (Sendmail, Exim,
Postfix, etc etc.) would attempt delivery for about 4-5 days (by default) --
(along with sending a message back saying it couldn't the send after 4hrs).
I'm very confused.

This morning I dropped and recreated the database and I've been watching the
growth of the records which has raised another concern.  There are records
where a triplet (ip address, from and to) failed many times (27 times in one
case) w/out a success.  Same sending IP, same from and same to address.
Again, I'm very confused.

I'm wondering if 4.7.1 is not the best TEMPFAIL code to use.  I was reading
http://www.sendmail.org/8.13.0.html and it have the following -- Do not use
4.7.1 as enhanced status code because some broken systems misinterpret it as
a permanent error.  Would reject=451 4.3.0 be more appropriate?

Finally, does anyone have a suggestion for monitoring the health of
relaydelay for problems/tempfail issues at the SMTP level?



Thanks,
Jim





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.puremagic.com/pipermail/greylist-users/attachments/20050208/0de15464/attachment.html