On 2011-10-28 04:01:55 -0400, Hector Santos wrote:
Tony Finch wrote:
The original motivation for this draft was to work around problems
caused by silly retry or greylisting configurations. Fixing the silly
configurations is the right way to deal with he problem.
How do we fix the silly configs? With suggestions for values?
Ok, I bite, what are your recommendations for:
Blocking Time: ___ secs/mins
Something between ca. 1 minute and ca. 5 minutes to minimize delays for
If you want to use greylisting to delay unknown senders long enough for
them to get into a blacklist you probably have to block longer. 1 hour
seems about right for that but I don't have any experience with that.
Record (sender recording) Expiration Time: ____ secs/mins/hours/days
Significantly longer than the 4 hours suggested by Harris. 9 to 24 hours
works well IME.
- initial try ___ secs/mins
A few minutes. Probably more than 1 minute and less than 10 minutes.
- 2nd try ___ secs/mins
- 3rd try ___ secs/mins
- 4th try ___ secs/mins
Double delay with each unsuccessful attempt until the delay reaches an
upper limit of 1 to 3 hours. Then retry at that rate for 5 to 7 days.
and I presume the fix means that EVERYONE has to use the same values at
all servers and clients?
No, it means that there is a range of values where you can be reasonably
sure that all mails will get through in a reasonable time. If you retry
only once every 24 hours, you have must expect that your mails will
never be accepted by greylisting receivers. Similary, if you set your
timeouts too long or too short at the receiver side, you must expect to
_ | Peter J. Holzer | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR | "Netz der kleinen Geister".
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Oliver Cromm in desd
Description: Digital signature