Re: [AMaViS-user] To Warn Or not To Warn?
On Wed, 15 Nov 2006 [EMAIL PROTECTED] wrote: From: Noel Jones [EMAIL PROTECTED] My opinion is no, don't do this. Spam and viruses commonly have forged sender addresses, so your offsite warning will often just annoy some innocent third party, I fully agree. I still have some procmail rules to get rid of antivirus announcements, I usually complain with those who send them, and one of the requirement I put when we installed an antivirus here (which was well after we had antispam) was that no warnings were sent outside. I also don't like warning local recipients about blocked spam and viruses. Getting 100 hey, we blocked some spam addressed to you messages is nearly as annoying as getting 100 spam messages. I agree here too. Even shorter notices can be annoying (see below). Our former (pre-amavis and SA) local policy was to reject DNSBL blacklisted messages silently (for local users) and generate an SMTP error (per standard sendmail dnsnbl) with a customized text. Our current local policy (with SA and amavis as sendmail milter) is to reject and quarantine spam and virus (a standard SMTP error is generated for sender). We quarantine everything to an unix folder which is rotated daily by a crontab (we keep last 7). The crontab takes also a scan of the quarantine folder, and sends to each user a daily summary of the spam received (with apparent and real From and To and Subject). This should be enough for the user to reclaim a possible false positive (we get very very few ... 1-2 per month ?) Originally each user could receive several daily summaries, with a minimum of 2 (we have two entrance MX's), because an user could receive spam addressed to him, or as member of an alias mailing list. That resulted soon too annoying, so we changed the crontab to analyse the YP alias file and send the summary only to real individual users, or to list owners. Still for me it was quite annoying to receive up to 4 summaries per day (2 as me from the 2 servers, 2 as list owner), scan them, and pipe them to a statistics tool. So I ended in writing a procmail/awk rule which concatenates them together, saves the summaries to a set of rotated offline folders, looks at facts like repeated subjects or unlikely addresses, and send me a single compact summary which says just you received xx sure spam, xx very likely spam, xx likely spam, xx possibly not spam, xx likely ham. For the last 2 categories only I get details on address and subject ... but they are usually 2-4 and 0 respectively. It may be useful to warn both local and offsite about banned files. Hopefully this will just be a small fraction I've never really understood the fuss about banned files and bad header, at the end we decided to let them pass (we get about 2 bad header per day over 2000 spamham, and no banned files) silently. -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
Re: [AMaViS-user] To Warn Or not To Warn?
Lucio Chiappetti wrote: I've never really understood the fuss about banned files and bad header, at the end we decided to let them pass (we get about 2 bad header per day over 2000 spamham, and no banned files) silently. The primary reason for banned files checks is to be able to catch new viruses before they are being recognized by virus scanners - as a permanent or as as a temporary quick-fix solution. The primary reason for header checks from my point is to be able to spot in-house PCs with broken MUA (misconfigured or poor/old version or just plainly bad software implementation). In the last year or two the use of non-encoded 8-bit national characters in headers went down from substantial to almost nil here, to the benefit of recipients of such mail. Mark - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
Re: [AMaViS-user] To Warn Or not To Warn?
Andres, Well, I have this on my 50-user file config $warn_offsite = 1; Is this a good practice ? Or should I shut this down to lower the load on the MTA? (the load of sending warn emails to outside) The extra load is minimal, but the annoyance to recipients is non-negligible. On Wednesday November 15 2006 16:37, Noel Jones wrote: My opinion is no, don't do this. Spam and viruses commonly have forged sender addresses, so your offsite warning will often just annoy some innocent third party, or will be undeliverable and clog your queue while waiting to expire. $warn_offsite only affects recipient notifications (when enabled), and recipient address is by definition always genuine. Here is an oldish but still pretty much valid flow from amavisd.conf-sample (only mentions viruses, but is equally applicable to other tests): # Here is an overall picture (sequence of events) of how pieces fit together # # bypass_virus_checks set for all recipients? == PASS # no viruses? == PASS # log virus if $log_templ is nonempty # quarantineif $virus_quarantine_to is nonempty # notify admin if $virus_admin (lookup) nonempty # notify recips if $warnvirusrecip and (recipient is local or $warn_offsite) # add address extensions for local recipients (when enabled) # send (non-)delivery notifications # to sender if DSN needed (BOUNCE or ($warnvirussender and D_PASS)) # virus_lovers or final_destiny==D_PASS == PASS # DISCARD (2xx) or REJECT (5xx) (depending on final_*_destiny) I also don't like warning local recipients about blocked spam and viruses. Getting 100 hey, we blocked some spam addressed to you messages is nearly as annoying as getting 100 spam messages. If local policy requires the user to know about blocked mail, just defang the mail and pass it on rather than sending warnings. Right. Recipient notifications are almost always pointless. It may be useful to warn both local and offsite about banned files. Hopefully this will just be a small fraction of detections, and has a decent chance of going to the real sender recipient. Right. Mark - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
