Professional Software Engineering writes:
At 17:37 2010-01-08 -0500, Richard B. Emerson wrote:
Er, that's not my intent. My plan is to look at each message after it's
been collected and fine tune the destination based on either the problem
with the Delivered-To field
I remain in the dark as to what the "problem" with the Delivered-To: field
is.
The problem is I'm not successful in writing a recipe that re-directs mail from
one place to another, based on the Delivered-To: field.
Question: What procmail recipe is used to perform final delivery of
the mail when the To: header actually does have the local user address
in it?
AFAIK, that's sendmail's job.
Sendmail is the MTA. Procmail is generally an LDA (if not a general
purpose mail filter - though if you have something in /etc/procmailrc,
you're invoking it much as an LDA), and most assuredly should never be used
to perform the duties of an MTA.
And some days ya needs to pop a can lid and all ya got is chisels. ;-)
I agree that the problem may well be caused by sendmail.
You're foisting the blame where it isn't deserved.
Er, blame? No... can't say as I think that. Something's broken, procmail
isn't it, so that leaves the MTA. And, honest, my error for not taking better
care to avoid a problem.
The short-term goal is building a workaround for a special case
(ill-formed mail list mailings).
The mailing list headers are not ill-formed. Excepting _some_ lists, the
vast majority of lists deliver messages BCC - recipient addresses appear
nowhere within the headers. If your mail system can't grok BCC, you have
an issue. Chances are, your old approach was reliant upon some
characteristic of the email which your upline provider inserted into
messages, and they've changed what they're doing. In a STANDARDS BASED
delivery setup, this wouldn't matter - but you're relying on nonstandard
headers.
The whole (fetchmail -> procmail -> mailbox) for multiple users through one
invocation is a very delicate kludge. fetchmail for individual user
accounts is reasonably reliable, but using it in place of SMTP for an
entire domain is riddled with issues, many of which you have no control over.
Why does your machine not receive email via SMTP? Are you not on a static
IP assignment?
If you have a static IP assignment, or use a dynamic DNS service to
register your IP, you should be able to make arrangements with your current
mail provider to act as a secondary MX, then when your server goes online
and registers its dynamic IP, you issue an SMTP "ETRN" command to their MX
host, and they process their queue. Whenever your host is up and working
properly, arriving email just shows up directly, rather than via your
secondary MX. This is a quick tweak to your DNS ZONE (to change the MX
hosts). Then you'd do away with fetchmail (though, actually, you'd still
use it for "tickling" the backup host - fetchmail can be used to issue the
ETRN).
I'm sorry but the horse is dead, the knackers are pulling up to the gate to
cart poor horsie away, and, truly, I have a plane to catch.
I was hoping for a quick fix. It isn't happening so I'll deal with the
consequences as best I can. :-)
"So long and thanks for all the fish." - - Douglas Adams
Cheers,
Rick
---
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
____________________________________________________________
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