On Fri, 29 Jul 2016 08:35:46 -0700 (PDT)
John Hardin <jhar...@impsec.org> wrote:
Greylisting means *you don't see the content at all during the
delay*. You tell the sending MTA to try again later when they first
connect and send the MAIL FROM and RCPT TO. If you implement the
delay *after* you've already received the content, then you're
totally missing the point of greylisting.
On 29.07.16 11:45, Dianne Skoll wrote:
Yes, that's what naive people think. :)
that's the most usual way to greylist, before data phase.
We do post-DATA greylisting for two reasons:
what do you use? DCC?
https://www.dcc-servers.net/dcc/greylist.shtml
1) If our customer has whitelisted a sender, but the whitelisted sender
is in the From: header and not the envelope, we want the ability to skip
greylisting in that case. Yes, I wouldn't choose to do that, but...
the customer is always right. (*snicker*)
does greylist produce that many problems that this is important?
2) Spammers sometimes send from the same (IP, MAIL From, RCPT To) triplet
but mutate the message subject. If you mix the message subject into
the greylisting criterion, it makes greylisting even more powerful.
I don't get it... when you greylist before the data phase, you greylist
completely unrelated on Subject...
A third reason which we don't yet implement because it's a bit of a research
topic at this point: It might be handy to feed greylisted messages into
Bayes if they never pass the greylisting hurdle after a certain time period.
DCC greylist feeds it at least to the DCC network, so the fuxxy checksum is
known immediately.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.
