Frank Ellermann wrote:
On 25 October 2011 20:31, Hector wrote:
retrytime = "retry=" min-secs ["-" max-secs]
min-secs = 1*digits ; minimum blocking time
max-secs = 1*digits ; optional retry expiration
Makes sense if the server has a plan *when* it intends
to purge pending triplets.
I will venture most Greylisting Servers had followed Harris's original
whitepaper which included a record expiration offering a time window
for the MTA to retry.
http://projects.puremagic.com/greylisting/whitepaper.html
Implementation Specification
In order to implement the Greylisting method, we will use some
form of database to hold a few pieces of information about a
specific mail relationship that is keyed off of the triplet
described above:
The time that the triplet was first seen (record create time)
The time that the blocking of this triplet will expire
The time that the record itself will expire (for aging old records)
The number of delivery attempts that have been blocked
The number of emails we have successfully passed
Our particular GL server stock setting covers the top three items:
Expire.block 55 # secs to block greylisted senders
Expire.record 2880 # mins to expire recording
Expire.pack 96 # hours to delete records and pack DB
The initial block is 55 seconds, 2 days of monitoring it and 4 days
when the backend automatically packs the database which can grow
pretty fast when 60% of the senders are "single shot" senders. What
is fascination is that 60% is pretty consistent with most of the
customers providing their logs for review.
I guess, technically, given a proposed SMTP Extension for Greylisting,
the tracking time limit (expire.record) of a triplet SHOULD match
RFC5321 recommendation of allowing a MTA a 4-5 days time window to
delivery the mail.
--
HLS