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: > > > I'm still waffling ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Sam Varshavchik wrote:
> Bowie Bailey writes: > > > Sam Varshavchik wrote: > > > 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. > > Replace the "someone" with "spamware that uses a forged return > address". > > Now, you have backscatter. Ok. The brain is working again. That makes sense. > > > 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. > > You will simply need to tell your users that if they want their mail > forwarded, it's their onus to make sure that their ISP receives their > mail and delivers it. If their ISP drops the ball, their mail will > disappear. Try explaining that to people who barely even know how to use Outlook Express to read the email. Since I'm providing the email address, I'm the one they yell at when it doesn't work. That being said, it doesn't really happen that often. > That's simply just the way it is, and the way it has to be, since the > alternative is going to be backscatter. And, what's worth, Courier > will not be able to detect it as backscatter, and nuke it, because of > the internal forward. > > You will change your mind fairly quickly once someone sends a few > hundred thousand copies of penis pill spam to one of your users, his > ISP's spam filter properly rejects it, and you end up dumping the > whole kit and kaboodle to <postmaster@fbi.gov>. > > You might've gotten away with it up until now, mostly because you're > not really on anyone's radar in the grand scheme of things, but > something like this is just inevitable. It's only a matter of time. I'm still trying to remember why I put this setting in to begin with. I may change it back once I get this server online and see what happens. I may be wrong, but I seem to remember that I was having a problem with some ISP rejecting mail with an empty sender address (Yea, I know it violates the RFCs, but I think there was someone doing it anyway). It seems that I'm stuck between the possibility of generating backscatter and the possibility of losing valid email. At the moment, I consider the second to be a much more serious problem. -- 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 |