Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] Re: How does blacklist support work? (Feature request)

2005-08-15 by Dawn Keenan

On Mon, Aug 15, 2005 at 05:04:37PM -0000, bytemastr wrote:
> Now, I have not thoroughly delved into the RFCs to see if what I
> propose would break standards, but it is my opinion that legitimate
> (non-spam) hosts would attempt to redeliver on the order of minutes
> (say 10 at the least, but I'd argue more like 15.)

Matthias Scheler replied:
> Queue handling in "sendmail" works differently. It doesn't remember when
> to retry delivering a particular e-mail. It will instead try to redeliver
> every queued e-mail in regular intervals. An e-mail that got rejected
> by greylisting 1 minute before the next global queue run will therefore
> be redelivered 1 minute later.

Sendmail does remember the last time delivery of a particular email
message was attempted.  It has a tunable parameter MinQueueAge which
can be set to avoid the situation where a message delivery attempt
failed and then a queue run makes another delivery attempt shortly
thereafter.  The default value of MinQueueAge is 0 (always try to
deliver all messages in a queue run regardless of how recently the
last delivery attempt was made).

The default behaviour is as you stated:  email rejected by greylisting
just before a scheduled queue run will have delivery attempted twice
within a short period of time.  Because of this default, requiring three
delivery attempts within a short period of time (is there any vendor
shipping an MTA with a default configuration that will cause a message
delivery to be retried three times in less than 15 minutes?) would be a
reasonable minimum requirement to blacklist a server or tuple.

Section 4.5.4.1 of RFC 2821 states in part:

   The sender MUST delay retrying a particular destination after one
   attempt has failed.  In general, the retry interval SHOULD be at
   least 30 minutes; however, more sophisticated and variable strategies
   will be beneficial when the SMTP client can determine the reason for
   non-delivery.

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  The
   parameters to the retry algorithm MUST be configurable.

--d

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.