Re: Return path rewritten

On Oct 29, 2007, at 10:11 AM, dan.newman-xsfywfwIY+M@xxxxxxxxxxxxxxxx wrote:

> On 29 Oct 2007 , at 7:53 AM, Benoit Schmid wrote:
>
> > Good afternoon,
> >
> > We are running:
> > Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 
> > 32bit)
> > libimta.so 6.3-3.01 (built 20:10:10, Jul 12 2007; 32bit)
> > SunOS zulu.unige.ch 5.10 Generic_125100-10 sun4u sparc 
> > SUNW,Sun-Fire-V440
> >
> > I am trying to debug a alias expansion problem.
> >
> > On a host I have defined in the alias file:
> > bioveg-all:     </path/bioveg-grp.dis, \
> >               [BLOCKLIMIT] 300
> >
> > This works fine except when there is an invalid address
> > in the dis file, an error message is sent to bioveg-all
> > because the return path is changed to bioveg-all.
> >
> > On our pmdf host the error message was sent to the sender only.

No.  On your PMDF host, such an error would not have been generated
at all -- it would instead have been silently ignored (other than being
reported by pmdf test -rewrite -check_expansions, if you tried that).
Some _different_ sorts of errors (such as delivery problems to group
members _after successful group expansion_) would have been reported 
(only)
to the original sender -- and that behavior is still the same in the JES
MS MTA.

> > Would you have an idea on this behaviour cause
>
> It's a matter of taste: some sites want the error to go to the
> sender at the risk of disclosing the list membership to senders.

> Other sites want the error to go to the error return address.

Dan mentioned "list membership" and "error return address".  But note 
that
you do not, currently, have a real "list" defined.  Instead, you have a 
"group"
defined. The difference is _exactly_ in whether you define an error 
return address
(which, by overriding the original envelope-from address, also controls 
where
error messages will go).

If you set an "[ENVELOPE_FROM] <some-sensible-list-owner-address>" 
clause in
your definition, then you will have a true list, and error reports will 
go
somewhere "sensible", namely to that "owner" address.  This will include
both delivery problems for valid addresses, AND reports of problems in 
the
list membership definition (obviously incorrect, e.g., syntactically 
illegal,
errors in the membership in the .dis file).

In contrast, for a group, there is no really good general answer for 
where to
send reports of problems in the list definition.  (Note that I am now 
speaking
specifically of problems in the list definition -- _not_ of delivery 
problems
to otherwise valid members, such as cases of a member being 
over-quota.)  The MTA
used to silently ignore such problems (_no_ report would be sent at 
all, to anyone,
in cases of "bogus" members as long as the membership had at least one 
apparently
valid address).  Actual delivery problems to apparently valid addresses 
were all
that would get reported to the original sender (though even that is 
questionable
-- about which, more below).

Now, as I have discussed on numerous occasions, use (I would say abuse 
or misuse) of
groups when lists (groups plus override envelope from address) would be 
more
appropriate is wide-spread.  Unless your case is one of the very rare 
cases where
a group is truly the "right" answer (in which case, reporting the 
definition error
to the entire group is also typically the "right" answer), then instead 
of what Dan
suggests below, you ought to instead change this to a list -- that is, 
add an
[ENVELOPE_FROM] clause -- which will fix other problems, as well as the 
supposed
"problem" you're raising currently.

Note that the important differences between a "group" and a "list" all 
lie in exactly
the case of membership and delivery problems.  Therefore, as long as 
everything is
"working", using a group (when you ought to have used a list) seems 
"just fine" -- no
problem is apparent. But it's in the problem cases where the 
differences matter.

Back to when is a group the "right" answer -- only when all the 
following criteria
are met: (a) small (under ten -- better yet, under five) membership, 
(b) stable
membership, (c) the definition has been checked (e.g., imsimta test 
-rewrite
-check_expansions), (d) the members are all very "close" in 
relationship (say
job-sharers, or a small, close-knit group of sysadmins, or merely just 
different
mailboxes for the same underlying human being), (e) really reliable 
delivery (for
example, no members hosted on remote, hard-to-reach/unreliable hosts, 
no members prone
to going over-quota, etc.)  Otherwise, it is better to define a list 
(add an
[ENVELOPE_FROM] -- or for LDAP-defined lists, an mgrpErrorsTo 
attribute) so as to
better handle cases of problems, both membership definition problems 
and actual
delivery problems.

Regards,

Kristin

> iMS does the latter.  Since, by default, the envelope From:
> address is the list, that's where the error goes.  To control
> this, specify an different error return address for the list:
>
> bioveg-all: </path/bioveg-grp.dis, [BLOCKLIMIT] 300, \
>     bioveg-errors
> bioveg-errors: some-address-to-send-errors-to
>
> Regards,
> Dan