Re: [Exim] Re: Limit on message size for filtering?

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Alan J. Flavell
Ημερομηνία:  
Προς: Exim users list
Αντικείμενο: Re: [Exim] Re: Limit on message size for filtering?
On Wed, 17 Dec 2003, Alexander Sabourenkov wrote:

> > If you can't reject them at SMTP time, then you need to drop them.
>
> I found that this is not enough, because the collateral spam will instead be
> generated by the servers that try to relay the viruses (that have no virus
> scanner installed and are trying to relay them).


But that's *their* problem, not yours.

At least if they don't launder the virus, but do a straight rejection,
we'll happily reject their non-delivery report on the basis that it
contains a virus. End of story (unless the idiots put a non-null
sender address in the envelope of their non-delivery report,
sheesh...)

The situation of junk fragments from laundered viruses is rather
harder to deal with, but some of them can be spam-rated effectively
enough, and if a particular MTA gets to be too much of a nuisance,
they can be blacklisted for sending unsolicited non-delivery reports,
it seems to me.

> Not that the majority of virus payloads experience more than one hop over
> SMTP, but the collateral spam is there with SMTP-time rejection too.
>
> Had to add a regex match on virus name and silently drop messages laden with
> viruses that propagate via mail.


But ignoring their suboptimal behaviour won't go any way to persuading
them to stop doing it.

> A flag in the virus scanner reply that says something along the
> lines of 'This virus propagates via email and forges sender address'
> would be nice though.


That might as well be the default nowadays. Maybe they could do the
converse: add a flag saying "this virus appears to generate genuine
sender addresses", since most of them nowadays don't.

> Hope antivirus people implement that sooner than later.


First priority is to get the message to those commercial antivirus
package vendors and ISPs which are causing the problems - whether by
laundering virus-infested mails and passing them on, or by sending
non-delivery reports about viruses which counterfeit the sender
address.

Try this for sighs:

If a virus, worm, or other security threat is found, Road Runner
cleans or deletes the infected attachments as necessary, but
continues to send the original message content to the recipient.

Anyone within reach of those lot with a clue-by-four? That
unsolicited report came as the accompaniment to several fragments of a
widely-known virus that ought to have been exterminated at source, not
transmitted across the Internet. And it went on to say:

Further information on this initiative can be found at
http://help.rr.com/faqs/e_mgsp.html.

Well: that web page gave me a redirection, unsuccessfully hurled
a cookie at me, gave me another redirection, and then displayed an
error page, complaining about my choice of browser/settings but
telling me nothing about their stupid "initiative". Sigh.