On Sun, 2007-02-04 at 22:21 -0300, Horst H. von Brand wrote: > > Exim certainly does the job for me. None of the others do, as far as I > > can tell. I'd be happy to be corrected on that count though, so I'll > > elucidate... I note you make no pretence at claiming Postfix can do these things; only arguments that I shouldn't _want_ to. This despite the fact that they're only _examples_ of the kind of thing people do with mail servers, and the fact that these are the reasons people come to me and _ask_ for an account on my systems. But despite the fact that it's a complete digression and you seem to have already conceded the point I was making, it's a subject which interests me so I'll play along... > > I'd like to be able to do greylisting -- but not indiscriminately; I > > want to greylist only mail which actually looks suspicious in some way, > > rather than delaying perfectly genuine mail. Mail gets greylisted only > > if it has some SpamAssassin points, or it's HTML, or it comes from a > > machine with no reverse DNS or which is listed in a RBL, etc. > > The /point/ in greylisting is not to expend any effort on mail that comes > from suspect origins. Resources are cheap, right up to the point the mail is accepted and delivered to my mailbox. At _that_ point I start to resent it. The point in greylisting is very simple: it's to check that the mail is coming from a 'proper' mail server which actually does retry mail when you give a temporary rejection. Some people naïvely delay all incoming mail (and some outgoing mail too, if they reject at RCPT TO and the recipient uses callouts) by greylisting indiscriminately. I prefer mail to be fast in the common case, so I like to delay _only_ mail which actually looks suspicious in some way, and I prefer _never_ to greylist mail from a host (IP address) which was already observed to retry in the past. > Stopping mail from an RBLed origin or no reverse DNS > (or non-matching reverse DNS) are other, independent anti-spam > measures. Sure, they can be integrated into greylisting (milter-greylist > for sendmail integrates RBLs), but they are still independent. So is > spamassassin's score, etc. You may have been trained to treat them independently because that's all you're used to being able to do, but personally I don't want to be limited in that fashion. I _want_ to be able to combine SA score with other reasons for considering a mail 'suspicious', and use that as a trigger for stuff like greylisting. For someone else, I used a similar set of criteria to trigger Exim's 'fakereject' feature which allows one to give a 550 rejection but still actually accept the message. It was configured to 'freeze' the mail on the queue, and give a URL with the rejection message as well as an explanation. When the recipient of the bounce went to that URL they would get a far more coherent explanation of the offences which caused the mail to be 'rejected', and could complete a captcha to verify that the mail _is_ genuine and have it unfrozen for delivery. That's not something I would normally have done; I prefer just to bounce and let people fix their sending mail servers if they're broken enough to get rejected. But the client in this case was adamant that this was what they wanted, and it allows them to peruse the frozen spam on the queue for false positives. It's better than accepting it and putting it into a spam folder, because that way the recipient wouldn't get a bounce, so they might think their mail is actually going to be read. > > Is it possible to do that kind of thing in other MTAs? Without writing > > or installing external software (or, perhaps, calling out to Exim? :) > > Why is "installing external software" (specially if it is written to > standardized interfaces defined exactly for such uses) off-limits? I suppose it isn't off-limits if it's versatile enough to be tweaked to users' requirements and if it's shipped in Fedora. Standardised interfaces are fine, again as long as they're versatile enough. For a long time, Exim had SpamAssassin support (sa-exim) which used a similar interface -- running on the mail just after DATA and giving a decision about whether to accept it or not. That wasn't good enough for folks who were used to better things, and it was very quickly replaced with full content scanning support within the ACL language. We finally dropped sa-exim from the Fedora packages in FE6, after keeping it around for a long time for compatibility. http://fedora.redhat.com/docs/release-notes/fc6/en_US/sn-Extras.html#id2916368 > > I also need to be able to run virtual domains on the cluster of mail > > machines I operate, but I don't really want to set up yet another > > distributed database; I _already_ have DNS running, after all. I keep > > aliases for virtual domains in TXT records, > > Lousy missuse of DNS, if you ask me. DNS is a distributed database which automatically synchronises between all the machines in the cluster. It also allows me to give 'keys' to certain users in order that they can modify certain subdomains as they desire. It was already running; I didn't have to set up a new database. Yes, it's 'abuse of DNS'. It's also _extremely_ convenient. If I want bondage and discipline I'll go back to programming in Modula-3. > > and I use Dynamic DNS so > > that owners of a given virtual domain can update their forwarding > > records with a trivial script round nsupdate. Currently, that's handled > > just a few lines of Exim router configuration in the same directory as > > the above (routers-dns-virtual). Can I do this in any of the other MTAs > > on offer? > > Why does an MTA have to bend over to such abuse of DNS? An MTA should be flexible enough that the admin can do what he/she need to do with with it. Because of the way SMTP works, especially the need to avoid sending bounces _after_ accepting mail, stuff _does_ need to be pushed down into the MTA to be done at SMTP time. And in the current environment, you have to get more and more involved to stay ahead of the game. I've just highlighted a few of the things I do with it; that's all. It wasn't an exhaustive list; just a glimpse of how Exim makes the mail system work much better for _me_ (and my users) than any other MTA could manage. OK, so returning to the original topic... now I've got two kinds of responses. First the "oh, I think I'll switch to Exim" and now the somewhat more disingenuous "you shouldn't want to do that anyway" :) -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
