TMDA / Challenge Response / CAPTCHA

This is directed to phoenix --

I researched out postgrey. Not bad, actually! I wonder if I could use this instead of TMDA. I'll have to think about that a bit. The only problem that I can think of now is that my current TMDA setup allows for a "pending messages" folder. Rather than actually completely rejecting the message, can postgrey actually accept the message if it's to a valid recipient address, but notify the sender of the temporary rejection, and put the email in some sort of pending location while it waits for the response from the sending MTA? That way, a user could optionally get their delayed message immediately.

not at present-but it would be a good place to start!

Postfix 2.1/2 actually has greylisting stuff built in postfix.org/SMTPD_POLICY_README.html#greylist
(though a teinsy tiny bit unstable at times because of some of the database methods used-don't worry not crash worthy-but it just fails to do anything usefull)
and 2.4 in v5 might have some more enhancements-I used to be a postfix fanatic (ok well still kinda am) /subscribe to all the mailing lists/read the enhancements but there's always so much to keep track of...especially when I moderate in a few other places...

There are other graylisting programs out there that do things like that, or deliver the message but apply a higher spam score until they get a response, etc. (ie put it in the junk/spam folder and move it out later or if the user moves it out.
As I actually wrote in the wiki: Some can be configure so that you hold the mail for up to xmin, (unless they get a reattempt response sooner), and then deliver it anyway with an additional spam score tacked on etc.

While these probably don't have those above desired features, I personally haven't used them in a while, so you might read up on the current status/functions of:
Connecting with SQLGrey - ZimbraWiki
Postfix Policyd - ZimbraWiki
gps - greylist policy service for postfix
Gld (good article at Greylisting Spams with Postfix + Gld | HostingFu)
anti-spam
tumgreyspf: Greylisting and SPF for Postfix in Python

Think it's time you make an RFE (or two/three) once you consolidate a list of desired features...
You might ask: "why don't I make it for you?" I'll of course subscribe to any links you post back, but that way you include the features you want, your notified when it get's worked on, + I can shoot the breeze on enhancement ideas all day-trust me.

Ok I'll look into those and see what I can figure out.

Another thing that might work is if the user himself could update their whitelist before the sender sent them something? Are there per-recipient whitelists or something, something an end user could edit?

-BJ

see, even you came back to the whitelists :p - remember that's why I said:

Quote:

---

Originally Posted by mmorse

Of course if you make any headway on your own sweet-also start an RFE. Might mark it dependent on Bug 6953 - Per user spam white lists in the UI because I still feel that's gonna be needed first for any good challenge-response system; it's not 100% required but it would ease people's mind's about the topic.

---

Ack! No! I *did* come back to whitelists, didn't I? For shame. :)

Anyway, any suggestion as to *which* greylisting option I should use? I looked at greylisting.org, and surprisingly, an implementation called "selective greylisting" was the only one that did any sort of, well "selective" greylisting. Looked good, but possibly unmaintained. Anyone have any luck with this one? All other implementations seemed to want to greylist the entire set of incoming messages. Wouldn't it be nice to only "greylist" messages that failed a spamassassin test or some RBL or reverse DNS lookup tests? Seems to be what the "selective greylisting" thing did, I just would have thought that the postgrey or sqlgrey implementations would have been advanced enough to filter out some messages that certainly don't have to be greylisted if they pass all the DNS tests and spamassassin tests with flying colors...

In the forums, you'll get the most support Improving Anti-spam system - ZimbraWiki
followed by Connecting with SQLGrey - ZimbraWiki
then Postfix Policyd - ZimbraWiki

See now your getting to the fun stuff!
And another loop on how they we're designed (it's what you get with independent systems).
Graylisting uses less cpu resources/time than spamassassin, your not crunching through the email just holding it and giving a 450 response.
Plus the designers of the graylisting programs are essentially designing to the mta software, if people can have all sorts of anti-spam stuff (whatever they want to use instead of spamassassin) one method of waiting for a yes/no spam score might not work if you have different AS software or have an edge mta that just processes, and a 2nd mta later on that does AS/AV work.
Which was why most were built with just manual & automatic whitelists instead of anything more complicated...

Well, that's true. I wonder about the "selective greylisting" at

anti-spam

So it doesn't give the incoming message the full SpamAssassin & AV treatment before it decides on whether to greylist the incoming email or not, it does some reverse-DNS/RBL/HELO sanity checks before it sends it off to be greylisted. I imagine that this would take care of at least most of the well-behaving mail servers, and they wouldn't have to worry about being delayed, even the first time.

However, this looks like a one-off deal, and I don't know if it's commonly used on a high-volume basis or if it's maintained. At the very least, it seems like the other greylisting daemons ought to use these kinds of heuristics, since it seems to make sense, and it makes me much more calm about the potential delay incurred with greylisting - an email only gets greylisted if it is potentially suspect in the first place. I think I can talk my users into the fact that they will only have to deal with a potential delay on emails coming in from new addresses for the first time and even then only if the sending email server is behaving badly in some way and making the email seem suspect. What do you think?

Is there some way to greylist only messages that fail a spamassassin test? I'm not as much interested in lowering resource usage as I am making sure my users get as close to *NO* spam as possible. I know the greylisting techniques mentioned here don't look like they'd do that, unless of course there were some way to run SpamAssassin at SMTP time, like SA-exim.

Ok so I found something called spampd, spamassassin proxy daemon. Apparently, according to Postfix Before-Queue Content Filter, one can add before-queue content filtering to postfix. Then maybe (at this point I'm lost) you could greylist *only* grey mail -- that is, emails that are over, say, 2.0 on the spamassassin scale, and below 5.0. Anything above 2.0 is assumed good and goes through immediately. Anything above 5.0 is assumed bad and we don't bother to greylist. Or we could anyway. Whichever. I care about the obviously good stuff. I don't want to potentially delay that.