procmail
[Top] [All Lists]

Re: Badtrans signature for local-rules

2001-11-28 11:32:51
On 28 Nov, Lars Hecking wrote:
|  
| >    Does it make sense, with any of these viral traps, to send a note to the
| > sender telling them they are infected?  I mean, if it might help, I'd be 
more
| > than happy to spend a little bandwidth to send a note back, but _does_ it
| > really do any good? Does the poor schlub really go for days not knowing s/he
| > has the thing (I've never had one, since I don't allow the Win boxes here to
| > connect to the Net)? And what happens in the event of a false positive
| > (although it wasn't a viri filter, I once had a filter misfire everytime
| > there was a pipe in the subject, so even with the best-laid plans...)?
| 
|  My take on this (but I'm biased - www.amavis.org :-):
| 
|  - yes, it does apparently happen that someone's PC keeps sending the stuff
|    for days and days without the user noticing; I've had one particular case
|    where the same virus-infected message (same message-id) came in for about
|    ten days. The envelope sender was empty, and the message was relayed 
through
|    a hosting service, so I couldn't tell by the headers who the original 
sender
|    was. I sent email to and even rang the ISP numerous times, but it took
|    almost two weeks before this was stopped.
| 
|  - virus scanning _should_ be done in the MTA, and not at local delivery time
|    by procmail. This is much more efficient. Alternatively, one can use the
|    MTA's access rules (if such features exist) to block certain content, then
|    the sender will receive the usual SMTP error message.
| 
|  - our amavis software has configurable notification options. My config here
|    is to notify sender, intended recipients, and local postmaster. So yes,
|    I think notifications are useful :)
| 
|  - one false positive is more acceptable than one trojan or worm getting
|    through and roaming your organisation. Anti-spam alone creates a lot
|    more false positives in general than anti-virus.
| 
|  YMMV.

And it does. ;-)  First, I appreciate the disclaimer. Second, I can
happily and truthfully exclude amavis from my complaints. I've observed
none of the boorish behavior from amavis that I have from others even
though I'd guess it's in wider use. I strongly suspect the reason is
amavis is free software and the others are presumed commercial.

IMO, sender notices are ineffectual and closer to being part of the
problem than the solution. With the "runaway" PC described above, no
number of notices is going to help. If anything, the recipient has a
better chance of finding some effective (and possibly alternative) means
to contact the sender than does the provider. There are two separate
relationships and sets of issues - provider to recipient, and recipient
to sender. There is no corresponding relationship between sender and
recipient's provider, and I see nothing to be gained by those notices.

Lastly, I also object strenuously to notices injected into my system as
MAILER-DAEMON. That hasn't been suggested here, but I have observed
it. Notification of *suspected* viruses does not rise to the severity
level of delivery failures, for which that facility should be reserved.
Virus notices should be delivered as any other "normal" message. Abuse
of MAILER-DAEMON in this manner is no better than spammers doing the
same. Considering these "notices" are beginning to look more and more
like advertising anyway, the line is becoming seriously blurred. I've
begun seeing these notices spewed to lists and that's inexcusable as
anything other than spamvertising, and then it's just plain inexcusable.

IMO, sender notification raises far more issues than it could pretend
to solve, even with reasonable implementation (e.g. no notices to
lists), and should be avoided.

-- 
Reply to list please, or append "6" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail