I'm still waffling as to the right solution for this.  There are
three basic options -- pass along the original $SENDER, as you're
doing.  I earlier believe that if that bounced, the backscatter will
get eaten, but I was wrong.  The forward message is really a new
message that originates locally, whose contents happen to be the same
as the original message, and its any bounce is not seen as
backscatter.  The second option is to set the return address to a
null, thus all bounces get discarded -- the current behavior. The
third option is to use the address doing the forwarding as the return
address, but this may result in mail loops. 
    

I'm not sure I understand why this would be considered backscatter.
This is what I see:

- Someone sends mail to one of my users
- I use maildrop to forward that mail to the user's preferred account
- Any bounces generated at any point in the chain need to go back to
  the original sender so that he knows the message was not received.

  
I believe Sam changed the sender on TO and CC because of problems I had awhile back, it had originally been set to the recipient address (See http://sourceforge.net/mailarchive/message.php?msg_id=11317249).  I was getting loops because of situations similar to what you mentioned.  Users were using the .mailfilter to forward mail to another account, if the account went down though (as freemail accounts regularly do), then either the local or remote server would generate a delivery failure which would need to be delivered to the recipient again, which the .mailfilter would try to forward and we have ourselves a loop.

I've been doing ok with < > although I think it means mail sometimes blackhole dissapears from a user's perspective.  I'm not sure about setting the recipient to sender.  Suppose the sender is a mailing list.  I'm subscribed to the list as [EMAIL PROTECTED], I forward all mail to [EMAIL PROTECTED] via a .mailfilter that sets the mail from to $SENDER.  Should my gmail account close down, the mailing list will get the delivery failure but they'll have no way of knowing it was [EMAIL PROTECTED] that is subscribed and has issues.  Same thing when you send a message to more than one person (although it might be easier to track down in this case).

I'm not sure there is a perfect solution in this case...

Jay

  
Mail forwarding has always been clumsy.
    

Agreed.  And now, with SPF, it is even worse.  Unfortunately, I don't
see the need for it going away anytime soon.  My problem is that I
host web and mail services for our customers' domains.  Quite a few of
them want me to forward mail from their domain accounts over to their
ISP account.

  

Reply via email to