[Mimedefang] Re: calling action_bounce() for viruses

[Sevo Stille]

Michael Sims wrote:

> What about .forward files?  Example:
> 
> ...  <user at example.com> has a
> .forward file that goes to <another_user at example2.com>.  The MX for
> example1.com accepts the message with the forged envelope sender, then
> attempts to hand it off to the MX for example2.com, but that MX reports that
> "another_user" is over quota.  Now example1.com's MX has to compose a DSN to
> the faked envelope sender.

True, but .forward files are strictly speaking at MDA/MUA level - they 
do forwarding on behalf and under control of the recipient. The "deliver 
or bounce" requirement for MTAs is the electronic equivalent of the old 
rule (bolstered up by what may be the oldest still valid international 
treaty) that the post office must make every attempt deliver all mail, 
or return it to sender. Whether the recipient doesn't ever empty his 
letterbox, has handed over control to an unreliable third party, or 
glues a paper shredder to it is beyond the scope of any requirement on 
post offices (or MTAs as their electronic equivalent) - legally, the 
mail has been delivered at that point, and if the recipient chooses to 
discard it, he will have live with the consequences if important mail is 
lost.

Of course, it would be desirable if SMTP were to be extended to allow 
for passing delayed reject messages to upstream MTAs, as only the first 
MTA in any chain _must_ know the authenticated ID of the initial MUA - 
but given that exploitable systems would inevitably be the last to 
upgrade, we'll be stuck with the current state, and must live with a 
limited amount of .forward-and-fail bounces.

A better policy on all non-rogue systems, that is, recipient validation 
at all perimeter MTAs complete with immediate rejection, and bounce 
generation and delivery to the authenticated sender rather than the MAIL 
FROM at the first stage MTA would already reduce the number of erroneous 
bounces by magnitudes, within the scope of the existing protocol.

Sevo

-- 
Sevo Stille
sevo at radiox.de