At 23:27 2002-01-24 +0000, Ian Chilton wrote:
** Please reply direct to ian(_at_)ichilton(_dot_)co(_dot_)uk **
Okay, I've cc'd you on the list reply. Keep in mind that because your
request is so far outside the scope of procmail that this should be the
only such reply you receive.
At the moment, I have a domain say mydomain.com which is hosted on my MX
server running postfix. Any mail for *(_at_)mydomain(_dot_)com gets put into 1
mailbox which I can collect by pop3.
"my MX server" sort of implies that it is *YOUR* machine and you have
administrative control over it. If this is so, this is great, considering
you'll be able to do what I suggest below without having to whine to
someone else to make changes on your behalf.
Every hour an NT box running MDaemon dials up, collects the mail from
[snip]
Bummer.
We were suposed to be getting a cable modem, so we built a linux box
with postfix and we were going to smtp the mail straight from the mx box
to this box on the cable modem so I have all the users setup ready.
So, set it up to use SMTP via an ETRN command issued by fetchmail (which is
totally separate and in no way related to procmail). You don't use
fetchmail to retrieve the messages, merely to sent the ETRN command that
tells the (what is supposed to be the BACKUP) MX server to process it's
queue for that domain.
However, turns out now that we can't get cable modems on that estate so
we are back to dialup :-(
Bummer for you.
Then in /home/mailsort/.procmailrc, I have stuff like:
* ^TO_ian@
/var/mail/ian
* ^TO_fred@
/var/mail/fred
..etc..
One: you're missing flag lines on those recipes. Two: mentally run through
the process if a message is addressed TO: Ian AND Fred. How about TO: Ian,
with BCC: to fred? Now, with that in mind:
PROCMAIL IS NOT AN MTA. ATTEMPTING TO USE IT LIKE ONE WILL RESULT IN
VARIOUS PROBLEMS WHICH YOU CANNOT EFFECTIVELY WORK AROUND AND WHICH ARE NOT
THE FAULT OF PROCMAIL, WHICH IS NOT AN MTA.
<http://www.professional.org/procmail/smtp.html>
Your real solution is to set your linux "client" box to be the primary MX
for the domain it is processing mail for, and the other box (the one you
refer to as your MX) set up as the SECONDARY for that domain. Now, when
your primary MX is unavailable (because it isn't on the dialup at the
time), mail gets delivered to the secondary, which holds it until the
primary is available (the secondary will process its queue every so often
as per its configuration and attempt to relay the mail to the
primary). When you dial up with the primary, either you have a static IP
(which would be best), and you're in business, or you'd run a ddns
registration script (and use a ddns service - do a websearch and you'll
find a bunch - you might even just run a ddns daemon directly on the
secondary MX box). Now, DNS of "host.domain.tld" resolves to the IP of
your primary MX host. Then you'd run fetchmail to issue an ESMTP ETRN
command (see the fetchmail documentation), which would tell the MX
secondary to process it's queue of held mail for your domain. It will then
send mail via (E)SMTP to the linux box where the *MTA* can properly deal
with delivering it to the indivdual users, invoking procmail as LDA or via
.forward for those individual users who choose to apply it.
Use the proper tools for the proper things, and you'll have goot
results. Procmail is an excellent tool - but it isn't an MTA. A
screwdriver is a great tool, but it sucks when used as a hammer.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail