On 10/19/2011 11:05 AM, Martijn Grooten wrote:
There is a danger in specifying the precise details/tuning values
of a "standardized gray listing" mechanism. If it's too
predictable, you could probably come up with a simplistic mechanism
for defeating it without requiring the complexity of queuing.
"Hybrid vigor" is a good thing.
Good point.
I like the idea of a BCP though and I like the outline too.
<aol> me too </aol>
Some quick comments:
Do people apply greylisting post-DATA in practise?
milter-greylist supports greylisting during DATA (not sure if its at the
beginning of DATA or at the end, could try it easily enough and find out
though) by means of the dacl configuration directive (as opposed to racl
for greylisting during RCPT)
AFAIK the DCC also can perform greylisting during DATA.
Might be worth adding a section to for greylisting performed during DATA.
There's also some interesting archive discussion regarding it on the
Mimedefang list:
http://lists.roaringpenguin.com/pipermail/mimedefang/2009-May/034793.html
It would appear from that discussion that at least Roaring Penguin
probably does do so in practice.
Or is this really
only something only performed in labs as it is the only way to
determine whether causes false positives.
AFAIK one of the supposed benefits of greylisting during DATA instead of
RCPT is reduction of false positives.
It is hard to reliably determine how much greylisting helps on a
specific system, i.e. what difference it makes compared to the
hypothetical situation greylisting wasn't used. May be an idea to
include some caution about that.
Log delivery attempts that are greylisted. Log greylisted delivery
attempts that subsequently pass. Compare the IPs in question against
whatever DNSBLs are in use to determine if the delivery attempts would
have been blocked anyway (without resorting to computationally expensive
content filtering)....
Might also make sense to log the DNSBL result at the time that a
delivery attempt is greylisted, and then log delivery attempts that pass
greylisting but are rejecting due to DNSBLs, and thereby determine if
greylisting is effectively giving a recently gone-bad host extra time to
get itself listed.
"greylisting is more expensive than not greylisting"
Can you explain this?
"special actions to take if the same message is retried before the
time limit expires"
I assume by "message" you mean the (sender, recipient, MTA) triplet?
Or if performed during DATA it could mean the same message data or at
least sufficiently similar message data, or even sender, recipient,
message-id triplet, or some other combo.
--
Joe Sniderman <joseph(_dot_)sniderman(_at_)thoroquel(_dot_)org>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg