Author: W B Hacker Date: To: exim users Subject: Re: [exim] suggestion for those implementing ACLs to suppress
backscatter bounces
Ian Eiloart wrote:
>
> --On 4 August 2006 02:03:00 +0800 W B Hacker <wbh@???> wrote:
>
>
>>Magnus Holmgren wrote:
>>
>>
>>>On Wednesday 02 August 2006 18:45, Jeremy Harris took the opportunity to
>>>say:
>>>
>>>
>>>>Chris Lightfoot wrote:
>>>>
>>>>
>>>>>No valid bounce will have >1
>>>>>recipient
>>>>
>>>>I think there are cases (mailinglists?) where that isn't so.
>>>
>>>
>>>Example: I send a mail somewhere with a group alias, like
>>>tech@???, as sender. It bounces. The bounce comes back,
>>>tech@??? is expanded into magnus@??? and
>>>chris@???, which are for some reason forwarded to
>>>magnus@??? and chris@???. Voilà, a mail with
>>>empty sender and multiple recipients.
>>>
>
Ok - but that has been 'masseged' and is no longer a valid 'bounce'.
The original, 'valid' or RFC-compliant bounce has already been accepted onto
your server.
Sorting out the expansion & forwarding rules is now *your* responsibility, not
that of the RFC (or 'default' Exim either).
>
> Damn, foiled again! See my email a few minutes ago in this thread, where I
> proved that this can't happen because a return path can only contain one
> address. Clearly, I didn't consider what happens to the bounce message
> after it's generated.
>
>
..er .. forwarded/expanded?
>>Is that seen as 'multiple recipients' on initial presentation to Exim?
>
>
> Yes, if Exim is handling the "otherexample.net" domain.
Not until it has hit the system/aliases router (or such).
> However, in this
> rather unusual(?) case, you might expect tech@??? to be monitored
> directly, and not reliant on the otherexample.net domain functioning.
> Perhaps it's time example.com got it's own IMAP server, and chris and
> magnus get themselves a shared mailbox.
>
>
Easily done by any of several means - not limited to ~/etc/aliases, either.
One of the oldest of tools - done in an MR/2-ICE MUA, for example, is to
'attach' the incoming to a new message, subject "Forwarded" and send THAT
onward. Voila - no longer an empty header (though, absent a footer, the body
might be).
A 'proper' MLM' with multiple admin's does similar things in generating
individual deliveries of bounces (Ecartis 'ccerrors' user class as well as admin
class).
>>The expansion could (should?) occur later, so 'not necessarily'.
>
>
> But possibly.
>
>
>>w/r Mailing Lists - to the extent that an MLM is intelligently
>>configured, any 'proper' bounces should come back in a format that the
>>MTA simply hands-off to the MLM for handling.
>
>
> So, we're not really talking about something as sophisticated as a Mailman
> list.
Yes, that covers the initial situation where an MLM list was posited as a source
of the problem (which they ordinarily are not). But the forwarding/expansion is
also an 'articifical' problem.
Correctly implemented, these do not create multiple-recipient 'bounces' either -
they simple carry the special-format bounce inside, or attached to, an
otherwise-ordinary message. Or have one or more headers added.
> Of course, this is a good argument for using a proper MLM, but if
> we're talking about a system adminstration alias, we might want it to
> operate properly even when the MLM isn't.
>
>
It can do - *IF* intelligently configured.
All that is needed is to treat the root cause, and in the proper place, rather
than the after-effects in Exim.
Trying to use Exim as an MLM is possible, but means re-inventing 10 - 20 or more
years of MLM-specific learning, alone, in the dark, and one stumbling step at
a time.
Hardly worth it, even for a list of two members, given the low resource load,
cost, and proven reliability of the top several MLM's.
