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

[Patrick Domack via amavis-users]

Yes, I assumed normal rules of email applied. You should NEVER bounce  
emails received on port 25, and by the company, would be your client,  
and should be using auth on port 587, so bouncing there would be  
acceptable.


Quoting Patrick Ben Koetter via amavis-users <amavis-users at amavis.org>:

> * 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