Ian Eiloart wrote: > > --On 4 August 2006 02:03:00 +0800 W B Hacker <[EMAIL PROTECTED]> 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 >>>[EMAIL PROTECTED], as sender. It bounces. The bounce comes back, >>>[EMAIL PROTECTED] is expanded into [EMAIL PROTECTED] and >>>[EMAIL PROTECTED], which are for some reason forwarded to >>>[EMAIL PROTECTED] and [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. Bill -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
