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

This is a discussion on RE: [courier-users] TO command not using SENDMAIL variable? within the Courier-Imap forums, part of the Mail Servers and Related category; Sam Varshavchik wrote: > Bowie Bailey writes: > > Sam Varshavchik wrote: > > > > > > maildrop is ...


Go Back   Usenet Forums > Mail Servers and Related > Courier-Imap

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-13-2006
Bowie Bailey
 
Posts: n/a
Default RE: [courier-users] TO command not using SENDMAIL variable?

Sam Varshavchik wrote:
> Bowie Bailey writes:
> > Sam Varshavchik wrote:
> > >
> > > maildrop is using SENDMAIL, however maildrop is also explicitly
> > > adding the -f "" flag also. Originally, this change was added to
> > > prevent maildrop from generating backscatter; but now that Courier
> > > has a real backscatter suppression filter, this is really no
> > > longer needed.
> > >
> > > However, you can replace "!<address>" with "| $SENDMAIL
> > > <address>", and get the same results.

> >
> > Things are starting to make sense now. That behavior should either
> > be removed (if it is not needed), or documented so it doesn't
> > confuse anyone else. Or possibly you could check to see if the
> > $SENDMAIL variable already set a -f flag and only do -f "" if the
> > flag is not already set.
> >
> > I did play around with the "| $SENDMAIL" construct and it works
> > fine. Unfortunately, that means I have to modify about 200
> > .mailfilter files as well as my program that maintains the
> > accounts. Can I modify the code to remove this behavior? If so,
> > where do I look?

>
> maildrop/deliver.C:
>
> cmdbuf=sendmail;
>
> cmdbuf += " -f '' ";
>
> Replace this with
>
> cmdbuf += " ";


Perfect. I'll give this a try.

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

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

--
Bowie


-------------------------------------------------------
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
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 10:05 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0