Re: [courier-users] TO command not using SENDMAIL variable?

permalink · #1 (**permalink**) 04-13-2006

This is a multi-part message in MIME format.
--------------080003080505030508030906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>> 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/m...sg_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 jlee@pbu.edu, I forward all mail to
jlee@gmail.com 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 jlee@pbu.edu
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.
>
>

--------------080003080505030508030906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
 
<blockquote
cite="mid4766EEE585A6D311ADF500E018C154E3021338E7@ bnifex.cis.buc.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.

</pre>
</blockquote>
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
<a class="moz-txt-link-freetext" href="http://sourceforge.net/mailarchive/message.php?msg_id=11317249">http://sourceforge.net/mailarchive/message.php?msg_id=11317249</a>).  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 <a class="moz-txt-link-abbreviated" href="mailto:jlee@pbu.edu">jlee@pbu.edu</a>, I forward all mail
to <a class="moz-txt-link-abbreviated" href="mailto:jlee@gmail.com">jlee@gmail.com</a> 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
<a class="moz-txt-link-abbreviated" href="mailto:jlee@pbu.edu">jlee@pbu.edu</a> 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 
<blockquote
cite="mid4766EEE585A6D311ADF500E018C154E3021338E7@ bnifex.cis.buc.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Mail forwarding has always been clumsy.
</pre>
</blockquote>
<pre wrap="">
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.

</pre>
</blockquote>
 
</body>
</html>

--------------080003080505030508030906--

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=...720&dat=121642
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode