Re: Return path rewritten

Kristin Hubner wrote:
> 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.


Good morning Kristin,

I can assure you that the same alias file produced 
a different behaviour.

On the pmdf host, when the email is sent to this list
an error message is sent to the original sender only.
But on JES the error is sent to all emails in the group.

With pmdf, the email is passed to the directory channel.
Then the email is sent to a jes store that bounce back 
to the original recipient.

With jes, the mta sees that there are emails invalid
(inetUserStatus: deleted) and bounces back 
(without sending to the jes store) to the whole list.

What I am plannig to do is to add 
a chosen error-return-address to all my 400 groups
in my pmdf alias file.
When this works, I would migrate again this alias file
on my jes host.
Is there an easier solution?

Are there other things that I should care off when 
migrating aliases file from pmdf to jes?

Thanks in advance for your answer



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

--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

     Benoit Schmid              Tel: (++41-22) 379-7209
     UNIGE Postmaster

     University of Geneva - Information Technology Division

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/