[amavis-users] amavisd 2.7.x final_virus_destiny and rfc 5321 section 2.1

[Patrick Ben Koetter via amavis-users]

* Patrick Domack via amavis-users <patrickdk at patrickdk.com>:
> That just seems so wrong on many levels.
> 
> You mean a company, wants to NOTIFY their customers that they are  
> infected and sending their customers viruses? And would perfer to do  
> this?

I do have a different understanding how the use case "virus sent to customer"
should be handled, but basically: "Yes, if it is legal and if they want it, we
will do it." Of course we will notify or even warn them that their way may be
unpracticable or will cause them other problems. By the end of the day it is
their own policy.

> Instead of have it bounce back to the sender, so the sender can clean  
> up his virus issue and resend a NONvirus email to the customer?

Bouncing back virus messages may be applicable in a controlled environment
where you have mechanisms in place that really let you identify the originator
of a message. It will notify the senders that they are having a problem.

Bouncing it back in general of course is a bad idea and I don't recommended
it - especially not when handling inbound messages from the Internet to
someones local network.

It is safe to assume that most if not even all virus infected messages abuse
someone elses identity (read: envelope sender address) to hide their real
origin. If you bounce such a message you will notify the wrong sender and your
message is very likely to be considered backscatter.

Stripping of the message part that is banned or considered to be harmful and
then deliver the rest is not the way most of us handle unwanted content, but
it can be done.

Personally I don't see the benefit and when in doubt I'd rather stop the
transport, have the content inspected by some human and only then decide upon
further delivery, but others may want to handle this differently.

We have built milters and one or the other amavis custom module to deal with
such cases. Usually we don't remove the content in doubt, but replace it with
a stub (text) file that carries a notice which tells the recipient the original
content has been removed because it violates the companies content policy.

p at rick



> Quoting Patrick Ben Koetter via amavis-users <amavis-users at amavis.org>:
> 
> > * Andrey Repin via amavis-users <amavis-users at amavis.org>:
> >> Greetings, Jonathan Siegle!
> >>
> >> > In the RELEASE_NOTES under "COMPATIBILITY WITH 2.6.4 / 2.6.5 / 2.6.6",
> >> > there is discussion on why the default for $final_virus_destiny was
> >> > changed to D_DISCARD from D_BOUNCE.
> >>
> >> > When people talked about this, was RFC 5321 section 2.1 brought up? An
> >> > archive thread on this is just fine.
> >>
> >>
> >> > Why would it be bad to accept the virus e-mail and then do the following:
> >>
> >> > Strip off the virus.
> >> > Send the rest of the e-mail to the original recipient?
> >>
> >> Because you're not supposed to modify the message in transit, except for
> >> purposes necessary for complete, intact delivery.
> >
> > That depends on the legal context (company/private) and country you are in.
> > We do have customers, who asked for this and we delivered such functionality.
> >
> > p at rick
> >
> >
> > --
> > [*] sys4 AG
> >
> > http://sys4.de, +49 (89) 30 90 46 64
> > Franziskanerstraße 15, 81669 München
> >
> > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> > Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> > Aufsichtsratsvorsitzender: Florian Kirstein
> 
> 
> 

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein