At 10:38 2006-06-16 -0400, Robert Moskowitz wrote:
[snip]
Here is what I have and what I need and what did not work...
My server is sip.htt-consult.com
I have a CNAME of fax.htt-consult.com
To be clear, you have something like:
sip.htt-consult.com. A 65.84.78.218
fax.htt-consult.com. CNAME sip.htt-consult.com.
Though in the zone file, use of ORIGIN definitions would likely show a much
more simplified representation:
sip A 65.84.78.218
fax CNAME sip
As you have it worded, sip could be CNAME fax
You should be aware that Procmail is an LDA - Local delivery agent. It
knows _NOTHING_ of DNS or SMTP.
So I set up a local domain of fax.htt-consult.com and a (global?) procmail
command (in /etc/procmailrc) of:
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.
:0
*
^(To|Cc|<mailto:Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com>Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com
/var/spool/asterfax/inbox/
Why not use MTA aliasing to deliver to procmail to produce maildir files?
Incoming mail to
<mailto:747(_at_)fax(_dot_)htt-consult(_dot_)com>747(_at_)fax(_dot_)htt-consult(_dot_)com
gets rejected as user
unknown:
<mailto:747(_at_)sip(_dot_)htt-consult(_dot_)com>747(_at_)sip(_dot_)htt-consult(_dot_)com
The MTA has to know that the username is valid, or it'll never get as far
as invoking an LDA. Do you have specific addresses or domain wildcards set
up in virtusertable, or is 747 at least a local user? These are,
predictably, sendmail configuration issues.
If you read up in DNS, you'll find that CNAME isn't recommended for
MX's. Set it up as a second A record pointing to the same IP
address. Once again, this has nothing to do with Procmail.
news: comp.mail.sendmail would be a good place to start reading.
So it seems like something in sendmail is changing the address fromm fax
to sip? And procmail does not get run?
Well, that should be happening because of the CNAME, but ultimatley, it
seems your sendmail setup isn't recognizing the address as a local user, so
it doesn't invoke procmail.
So I take out the local domain entry. I add to /etc/mail/access:
fax.htt-consult.com OK
Please cite your logic for doing this? Let me reiterate that this is a
PROCMAIL list, not dns/smtp/sendmail.
and to /etc/mail/mailertable:
fax.htt-consult.com procmail:
Do you have a procmail mailer defined? What is it that you expect this
mailertable entry to accomplish? Have you rebuilt the sendmail databases
(simply keying that text into that file won't change anything about
sendmail's running config)?
Jun 15 17:26:15 sip sendmail[3252]: k5FLQFXX003252:
from=<mailto:asterisk(_at_)sip(_dot_)htt-consult(_dot_)com>asterisk(_at_)sip(_dot_)htt-consult(_dot_)com,
size=431, class=0, nrcpts=1,
msgid=<<mailto:1150406775(_dot_)3250(_at_)sip(_dot_)htt-consult(_dot_)com>1150406775(_dot_)3250(_at_)sip(_dot_)htt-consult(_dot_)com>,
relay=<mailto:root(_at_)localhost>root(_at_)localhost
Jun 15 17:26:15 sip sendmail[3252]: k5FLQFXX003252:
to=<mailto:747(_at_)fax(_dot_)htt-consult(_dot_)com>747(_at_)fax(_dot_)htt-consult(_dot_)com,
ctladdr=<mailto:asterisk(_at_)sip(_dot_)htt-consult(_dot_)com>asterisk(_at_)sip(_dot_)htt-consult(_dot_)com
(100/101), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30431,
relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection
refused by [127.0.0.1]
I do have sendmail listing on 127.0.0.1
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.
Now I do think I have found one problem with my procmail command, perhaps
iti should be:
myunique = `date +%s`
This really isn't _that_ unique, because you could very easily have two
messages arriving within 1 second. Even if you don't forsee that level of
traffic, if your server is unavailable for a period of time (say, network
routing problem), and then becomes available, a backup MX, or just a
sending MX with more than one message queued will dump their queue on you
and quite likely get several messages into your host within a short
span. If you tack the procmail PID to the end of that, then you're in
business, because each time procmail is invoked, that number will be
different. Combined with the time, you'd have to have 10's of thousands of
processes invoked within the span of one second in order to risk an errant
duplicate (and that still requires the first process to have terminated
before the same PID could be reused).
myunique = `date +%s`$$
:0
*
^(To|Cc|<mailto:Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com>Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com
/var/spool/asterfax/inbox/$myunique
Of course, you could just let procmail do maildir format...
:0
*
^(To|Cc|<mailto:Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com>Bcc)(_dot_)*(_at_)fax(_dot_)htt-consult(_dot_)com
/var/spool/asterfax/inbox/
procmail will automatically generate a unique filename for you. No need to
create myunique (which involves an external process).
But I don't think that is the problem, or I would be seeing SOMETHING in
/var/spool/asterfax/inbox
So perhaps this is a broader sendmail problem, but why is not procmail
being called, it seems?
You need to examine your sendmail config. Look for references to procmail
in the sendmail.mc config file (from which the sendmail.cf is generated).
---
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