Darth Lists wrote:
> Unfortunately, this little MS-behaviour is very likely to be the "last
Well, I think greylisting is still useful. It is just that if you want
to avoid losing mail or having it too much delayed, you should adjust
the settings for greylisting from 1h/4h to 9min/36h. Many mailers have
their queue runners at 15mins. Putting 36hours allows you to get mails
from servers with common pools or weird retry delays. These values were
just deduced from trial and error. Also greylisting should happen at
RCPT TO, and probably not at DATA as there are some widely used MTAs
that are buggy and choke when a 4xx error is sent in the DATA phase.
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Antonio Almeida | HTB accuracy for high speed |
