At 16:37 2009-11-16 +0000, David Carvalho wrote:
I have this same configuration for other users. Recently one person left
the company,
but we re still forwarding his mails to another account. The problem is that
sometimes mail to him stays in the mail queue for one or two days and I
believe
that it is spam that is also being forwarded, and those servers, unlike
mine, reject spam.
Worse yet, because YOU'RE forwarding the messages, you run the risk that
YOUR server will be flagged as a spam site. No truely operation that
understands such things would flag you for forwarding junk to ONE recipient
at their domain, but if you're forwarding a bunch of content, and/or the
recipient starts flagging it at their end as spam, it'd be easy to see your
host getting blacklisted.
After running a few tests, I ve found that the first file to be processed
is .forward and the second is .procmailrc.
If procmail isn't configured as the LDA in the MTA, people generally INVOKE
procmail via the .forward file. If it's the LDA, there's no need to do that.
Why not do the forwarding from within the procmailrc?
:0:
* spam conditions
/throw/to/spamfolder
# our former employee shouldn't be SENDING mail from the account, so it's
# unlikely they'll be getting legitimate bounces. However, WE could be
# getting bounces when forwarding - forwarding THOSE would invite a loop
# condition, so don't.
:0:
* ^FROM_MAILER
/dev/null
:0
! ex-employees-new-address
But this way I don t get mail.
Why are you trying to dork your .forward - isn't it someone else's mail
you're having an issue with forwarding?
A better way to deal with a former employee is to set up a virtusertable
entry (assuming sendmail is the MTA) that issues an error when the former
address is addressed:
dorkums(_at_)ourdomain(_dot_)tld ERROR:nouser dorkums is no longer with
this firm. If you have personal correspondance, you can reach him at
newaddress(_at_)hisdomain(_dot_)tld
Then, you're not _accepting_ the body of the messages, spam or otherwise,
and not involved whatsoever in relaying the messages to him - so he's not
cluttering up your mailqueue, your're not needing to send bounces off to
the original sender after his ISP rejects the message during your forward
delivery attempt, etc.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail