At 14:04 2005-03-23 +1000, Troy Piggins wrote:
> I have the server setup to filter the mail already but
> I now want to forward all mail to another server
> retaining the To field. So that it can be delivered
> properly on the 2nd server.
So is the filter server (server1, say) set up with server2 as its
smtp host? If not, won't you get loops?
In sendmail, using mailertable, you could set _this_ host up to use a
_specific_ mail host, regardless of what the DNS for that domain is set up
for. It's a handy feature for say, dealing with bonehead ISPs that have
backup MX's which don't accept mail for their domain - thus, when their
primary MX is overloaded, mail is rejected outright as incorrectly
delivered, rather than queued up on the backup MX, or simply remaining in
the senders queue. By adding the primary MTA host in a mailertable for
that specific domain, mail is *ONLY* delivered to that host - no other. I
do this for a few braindead ISPs, and have successfully used it to deal
with verizon's buttheaded blocking of european ISPs, by relaying to a
specific internal MTA on their network, though after a couple of months,
they finally plugged that hole, and currently, I'm using the technique to
"smart relay" to a host in the US (well, one of my hosts - the sending host
is for another site I admin for), which doesn't get blocked by Verizon,
since it isn't in the european IP space.
> What would the procmail filter be to forward mail to
> another server without changing the To address?
Why don't you just do what someone else suggested and set up server2
to fetchmail from server1?
That is pretty ugly though.
A mailertable entry should suffice:
.yourdomain.tld smtp:[internal.mailhost.yourdomain.tld]
There's also genericstable, which is specifically used to convert an
address into another form (which can change both the username and the
domain portion).
In addition, there is masquerading and userdb.
review "cf/README" in the sendmail source distribution.
In any event, the issue is largely outside the purview of procmail - it's a
matter for your MTA - the only involvement of procmail might be if you
choose to use a different hostname in the forward process, and that
presupposes that procmail was provided the delivery username to begin with
(DO NOT BE A FOOL AND USE THE TO: HEADER TO DETERMINE THE RECIPIENT --
PROCMAIL IS NOT AN MTA).
I'm guessing the reason for doing this is someone is running a non-*nix MTA
on their internal mail system and are unwilling to convert over to a
standards-based MTA on a *nix platform, which would allow them to just
accomplish all of this on *ONE* host without dicking around.
One MAJOR problem I forsee is that the filtering host is quite probably
accepting ALL mail for the domain, regardless of whether the specified
users are valid, and only the actual (second) mailhost is aware of what
users are valid. Or, one has to maintain user data on the gateway system,
which is a PITA unless you're using a db mechanism to publish the user data
from the second mailhost so that the gateway can validate them before
wasting bandwidth accepting the messages and processing them (not to
mention relaying them to the internal server).
---
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