Am Montag, den 05.02.2007, 11:25 +0000 schrieb David Woodhouse: > 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 > Are we really changing the default MTA just because of a cock-up in resolving dependencies? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
