At 15:13 2006-06-16 -0400, Robert Moskowitz wrote:
But if the mail does not get to the box, so I do need the DNS stuff.
Just added for an attempt at clearity. ;)
Yea, well the basic point is that the majority of stuff your system needs
help with is completely out of the scope of procmail.
The global procmailrc will only be used if the mail is delivered via
procmail. That means at some point, your MTA has to decide to pass the
message to procmail.
My sendmail.mc has:
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
My sendmail.cf has the lines:
Mprocmail, P=/usr/bin/procmail, F=DFMSPhnu9,
A=procmail -Y -m $h $f $u
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9,
A=procmail -t -Y -a $h -d $u
Ok, so local mail (that mail being delivered to RECOGNIZED LOCAL USERS -
people with accounts) will invoke procmail, and thus /etc/procmailrc. You
also (above that) have a procmail mailer, which doesn't need to exist if
you're using procmail as the LDA. using a procmail _mailer_ is like using
_uucp_, and the like. However, since you want to handle mail for the fax
domain _wholesale_, you could use the procmail mailer (as you've already
tried to, but incorrectly)
I've all too frequently relied on mailertable to deal with getting around
crappy MX setups at some braindead ISPs - where they have an MX host in
their lineup that ISN'T configured to accept mail for their own domain - by
using mailertable, I can force mail to go to a specific
mailhost. Alternatley, you could use:
so that all mail for that domain would automatically invoke the local
mailer and deliver to the given username. Basically has the same effect as
a virtusertable entry with wildcard.
I did not make too clear that regardless of the 'user' (i.e.
user(_at_)fax(_dot_)htt-consult(_dot_)com) all emails have to go into /inbox
with the TO
righto, but sendmail needs to know that the user it is invoking the LOCAL
DELIVERY AGENT (LDA) for exists. That's part of it's test for whether it
should deliver locally or not. SENDMAIL determines if it's a valid user,
header unaltered so that Asterfax knows where to fax the missive. Thus
you can't vary well create userids.
virusertable - create a wildcard for the host/domain that routes to a
specific local user (which you'd set up to deal with the asterfax
messages). OR, use a sendmail program alias to pipe messages:
asterfx: "|/usr/local/bin/procmail -m /etc/procmailrcs/asterfax.rc"
(note no need for a conditions line, though if your asterfax software is
prone to trip up, you might check for cleartext addressing of the recipient
and take anything where the @fax.htt-consult.com bit isn't in a cleartext
recipient field and deposit it elsewhere for examination)
fax.htt-consult.com. But I still have to have sendmail do its userid
check for mail to @sip.htt-consult.com
Which, not surprisingly, is a wholly separate fqdn.
Is the fax hostname in the local-host-names file?
news: comp.mail.sendmail would be a good place to start reading.
Will look some more at sendmail alternatives.
sendmail is a perfectly good MTA. I use it. As with ANY software though,
it must be properly configured. As it is a very powerful MTA, with a wide
array of extensions added to it - and the _oldest_ of the MTAs, there's a
lot of cryptic looking stuff in configurations.
So I will test with A records and see if sendmail is nice and leaves the
host portion of the address alone. Was not aware that sendmail was in
the habit of doing this, but then my regular mailhandler is SCALIX
"CNAME" means canonical name.
This is all sendmail stuff. Please seek out an appropriate sendmail forum
and sort your sendmail issues to the point that you have mail being passed
to the LDA.
What 'evidence' will I find that mail went to the LDA? in maillog or
will there be some other log?
Well, you could set up a LOG= line in the /etc/procmailrc file.
procmail will automatically generate a unique filename for you. No
create myunique (which involves an external process).
Gee that is what I had initially.
BTW, I hadn't examined your condition line, but it has syntax errors -
quite possibly introduced by your MUA in the process of HTML-izing some
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/