Re: User Blacklist Spamassassin Behavior
On Tue, 28 Jun 2005 00:38:39 -0600 Paul R. Ganci [EMAIL PROTECTED] wrote: Alan Premselaar wrote: perhaps all I am really asking is if there is a way to allow spamassassin to just stop processing a message that is in a blacklist to save the cycles? I am not asking for spamassassin to become an MTA/MDA. In that case it would be ultimately more efficient to add a rejection rule to your MTA (i.e. sendmail's access db) than to even rely on SA's blacklisting (even if it did stop processing after determining the blacklist hit) I agree but this would be on a site wide basis when I want per user. So do it at SMTP RCPT time; you can control per user then, assuming the blacklisted address is an envelope sender. e.g.: MAIL FROM: [EMAIL PROTECTED] 250 OK RCPT TO: [EMAIL PROTECTED] 550 Go away, blacklisted RCPT TO: [EMAIL PROTECTED] 250 OK It's very easy to do this with Exim; I'm sure other MTA's/software configurations must be able to do a similar thing. In addition I want the user to be able to control the blacklist ... I don't want to have to update the access db on his behalf. Write a script to generate the SMTP-time access file periodically, from individual user blacklists? Tim
Re: User Blacklist Spamassassin Behavior
Alan Premselaar wrote: perhaps all I am really asking is if there is a way to allow spamassassin to just stop processing a message that is in a blacklist to save the cycles? I am not asking for spamassassin to become an MTA/MDA. In that case it would be ultimately more efficient to add a rejection rule to your MTA (i.e. sendmail's access db) than to even rely on SA's blacklisting (even if it did stop processing after determining the blacklist hit) I agree but this would be on a site wide basis when I want per user. In addition I want the user to be able to control the blacklist ... I don't want to have to update the access db on his behalf. As an aside, I do keep quite a large, custom site wide access db. My (not so clear) point is that there may be situations such as Corporate Policy, for right or for wrong, disallowing the discarding of *any* mail prior to delivery. We certainly don't have that policy here, but I've seen it come up in discussion before. I'm certainly not saying it's a bad Idea, I'm merely expressing some of the points that have come up in conversation on the list previously. Yes this certainly could be sticky. In my particular case I administer a small, rural wireless network providing broadband to ~300 people in the Colorado Rockies. We have no such policy and in fact I raised this question only because I have been getting beat up over the issue. I have users who want anything on their blacklists to just disappear. The side question of CPU cycles came up while I was taking my abuse. I guess procmail will be my friend. -- Paul ([EMAIL PROTECTED])
RE: User Blacklist Spamassassin Behavior
Why is it not a good idea for Spamassassin to immediately send to /dev/null a message flagged in somebody's blacklist ASAP ... i.e. no further processing? Is the only way to handle this via a procmail recipe? Similar what about a whitelist ... shouldn't it be sent on as Ham ASAP ... i.e. a minimal of processing? How do others handle these cases? -- Paul ([EMAIL PROTECTED]) Unix logic: Small utlilities that do ONE thing, and do that ONE thing very well. Windows logic: Large program that does everything, and not a single one well. Thats pretty much what it all boils down to. Chris Santerre System Admin and SARE/URIBL Ninja http://www.rulesemporium.com http://www.uribl.com
Re: User Blacklist Spamassassin Behavior
Paul R. Ganci wrote on Mon, 27 Jun 2005 23:34:22 -0600: However, I don't necessarily agree with the above because while I can add a procmail rule to handle a specific user's blacklist I can't get back the wasted CPU cycles which spamassassin expended But that's up to *your* setup. If you want messages going to /dev/null etc. then set it up the way you want it. And, yes, you can also set it up in a way that no ressources are wasted. Simplest way is to put that user in the access list of the MTA. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de http://msie.winware.org
Re: User Blacklist Spamassassin Behavior
Paul R. Ganci wrote: This is somewhat a philosophical question, but I will ask it anyways. Recent discussions have occurred on this list regarding what Spamassassin should do with Spam. The recent consensus seems to be that it is only Spamassassin's job to tag Spam and that some other program should decide what to do about it. I can accept this argument especially in regard to the old spam_action config option especially when set to delete. However, I have a user who raises a good point. He has a blacklist in his user_prefs. Spamassassin processes his Email message and indeed finds this blacklisted message as USER_IN_BLACKLIST shows up in the header. In addition lots of other processing occurs before the final score of 99 is tallied. His question is simply this: Why does this message show up in his box at all? His point being the message was blacklisted. Why is it not a good idea for Spamassassin to immediately send to /dev/null a message flagged in somebody's blacklist ASAP ... i.e. no further processing? 1) /dev/null spamassassin itself CANNOT /dev/null a message. It's impossible. SA is a piped message filter. By definition of being a piped message filter, it can only modify the message. If SA tries to /dev/null the content, most programs that call SA will detect the dead pipe, assume the piped filter crashed, and recover the original message. This is why SA doesn't ever /dev/null anything. It can't. 2) aborting processing It might still be promising for SA to abort processing once it detects the blacklist and immediately spit out the message with a spam tag. However, there is a general axiom of programing that applies here. Often when you try to improve a rare case you wind up hurting the average case performance. This is counter intuitive to most people, but it's quite true. Performance tuning is much less straightforward than it seems. You have to keep an eye on how you affect the best, average, and worst cases. Sometimes it also pays to check the most common case(in statistics terms: the mode, as opposed to the average case being the mean). For example you might have to add code all over the place that checks to see if the scan's been aborted. These checks would have to run numerous times during the scan of a message, and would have to run for every message. That would add a small performance penalty to the normal message to gain a strong performance boost for blacklisted messages. You'd have to weigh how much penalty vs how much boost against the ratio of normal vs blacklisted messages. On average you might wind up with worse performance unless you have a significant number of blacklisted messages. For example if you normal message penalty is 1%, your blacklisted gain is 50%, but blacklisted messages are 0.001% of your mail, your server will on average run slower. I can't say what the impact here would be, but I can make the general warning that this kind of optimization doesn't always pan out. Also, a message can match both blacklist_from and all_spam_to, and the rules wind up canceling out. You'd have to insert more special case code to detect that.
Re: User Blacklist Spamassassin Behavior
Paul R. Ganci wrote: This is somewhat a philosophical question, but I will ask it anyways. Recent discussions have occurred on this list regarding what Spamassassin should do with Spam. The recent consensus seems to be that it is only Spamassassin's job to tag Spam and that some other program should decide what to do about it. I can accept this argument especially in regard to the old spam_action config option especially when set to delete. However, I have a user who raises a good point. He has a blacklist in his user_prefs. Spamassassin processes his Email message and indeed finds this blacklisted message as USER_IN_BLACKLIST shows up in the header. In addition lots of other processing occurs before the final score of 99 is tallied. His question is simply this: Why does this message show up in his box at all? His point being the message was blacklisted. Why is it not a good idea for Spamassassin to immediately send to /dev/null a message flagged in somebody's blacklist ASAP ... i.e. no further processing? Is the only way to handle this via a procmail recipe? Similar what about a whitelist ... shouldn't it be sent on as Ham ASAP ... i.e. a minimal of processing? How do others handle these cases? Paul, here's my take on it. keep in mind i'm in no way affiliated with the developers, it's just my opinion as a mail system administrator and SpamAssassin user. for one thing, SA has been designed for specific reasons *not* to process the mail, but only to add headers as necessary. One of these reasons is that SA can remain extremely versatile in this configuration. for instance, I use SpamAssassin via a call from MIMEDefang which runs as a Sendmail Milter. Others may call spamassassin/spamc from procmail, others may integrate with qmail-scanner or amavis-new (neither of which am I familiar with, but they get quite a bit of mention on this and other lists) For SpamAssassin to be able to do SMTP level rejections, it would have to *always* be integrated into the MTA. Granted there are tools to allow the integration of SA into the MTA, but they are designed and supported by third parties (and in my opinion, rightfully so). Philosophically, it makes more sense for SpamAssassin to focus on identifying SPAM, and let another application (MTA, procmail, etc) focus on what it was primarily designed for: processing (delivery,rejection,etc) of said email. It's certainly no more of a hassle to add a procmail rule to dump a blacklist hit to /dev/null than it is to add a procmail rule for other delivery options. There may be cases where it would be very inappropriate for *any* mail, blacklisted or not, to be dumped to /dev/null. having SA have to account for all possible handlings of blacklisted mail would add more bloat and logic requirements to the code which, in my opinion, aren't necessary. When you're dealing with mail delivery, you have to account for local delivery inconsistencies, whether the mail will be delivered to a remote machine anyways, etc. again, these types of situations make it more appropriate for applications written specifically to handle them than to try to add them to SA and pull the focus away from identifying SPAM to delivering mail. just my $.02 worth. Alan
Re: User Blacklist Spamassassin Behavior
Alan Premselaar wrote: Philosophically, it makes more sense for SpamAssassin to focus on identifying SPAM, and let another application (MTA, procmail, etc) focus on what it was primarily designed for: processing (delivery,rejection,etc) of said email. It's certainly no more of a hassle to add a procmail rule to dump a blacklist hit to /dev/null than it is to add a procmail rule for other delivery options. There may be cases where it would be very inappropriate for *any* mail, blacklisted or not, to be dumped to /dev/null. I don't disagree with most of what you said. However, I don't necessarily agree with the above because while I can add a procmail rule to handle a specific user's blacklist I can't get back the wasted CPU cycles which spamassassin expended ... perhaps all I am really asking is if there is a way to allow spamassassin to just stop processing a message that is in a blacklist to save the cycles? I am not asking for spamassassin to become an MTA/MDA. Privately Ed Kasky raised the good point about spoofing. I believe whitelists have to have the full weight of a spamassassin scan to catch messages with spoofed addresses. But blacklists ... I don't believe suffer this problem. Yes I might receive a spam message from somebody spoofing an arbitrary Email address. If that address happens to have @ebay.com then I am highly unlikely to blacklist it. If it is from @anybody.com then unless I have some reason to believe that I should expect legitimate Email from that address, I argue that blacklisting it does no harm and that any message found to be on a blacklist could be processed with the minimal of effort by spamassassin. But then what do I know? :) -- Paul ([EMAIL PROTECTED])
Re: User Blacklist Spamassassin Behavior
Paul R. Ganci wrote: Alan Premselaar wrote: Philosophically, it makes more sense for SpamAssassin to focus on identifying SPAM, and let another application (MTA, procmail, etc) focus on what it was primarily designed for: processing (delivery,rejection,etc) of said email. It's certainly no more of a hassle to add a procmail rule to dump a blacklist hit to /dev/null than it is to add a procmail rule for other delivery options. There may be cases where it would be very inappropriate for *any* mail, blacklisted or not, to be dumped to /dev/null. I don't disagree with most of what you said. However, I don't necessarily agree with the above because while I can add a procmail rule to handle a specific user's blacklist I can't get back the wasted CPU cycles which spamassassin expended ... perhaps all I am really asking is if there is a way to allow spamassassin to just stop processing a message that is in a blacklist to save the cycles? I am not asking for spamassassin to become an MTA/MDA. In that case it would be ultimately more efficient to add a rejection rule to your MTA (i.e. sendmail's access db) than to even rely on SA's blacklisting (even if it did stop processing after determining the blacklist hit) Privately Ed Kasky raised the good point about spoofing. I believe whitelists have to have the full weight of a spamassassin scan to catch messages with spoofed addresses. But blacklists ... I don't believe suffer this problem. Yes I might receive a spam message from somebody spoofing an arbitrary Email address. If that address happens to have @ebay.com then I am highly unlikely to blacklist it. If it is from @anybody.com then unless I have some reason to believe that I should expect legitimate Email from that address, I argue that blacklisting it does no harm and that any message found to be on a blacklist could be processed with the minimal of effort by spamassassin. But then what do I know? :) My (not so clear) point is that there may be situations such as Corporate Policy, for right or for wrong, disallowing the discarding of *any* mail prior to delivery. We certainly don't have that policy here, but I've seen it come up in discussion before. I'm certainly not saying it's a bad Idea, I'm merely expressing some of the points that have come up in conversation on the list previously. On the flipside, I handle all my don't need to waste processing time by calling SA type transactions from within MIMEDefang and have been quite happy with my configuration. I personally wouldn't benefit from this type of feature, but neither would I suffer. anyways, just my opinion. alan
