Sean, thank you for your response.
I included my total config (well most of it), as I could not tell what
was going on, and as you point out I do have some sendmail issues to
clean up.
I am using Webmin to manage sendmail and procmail. I have been using
Webmin for other maintance and have found it easier that SSHing into
servers and using VI. So I just started with sendmail and procmail.
Webmin rebuilds sendmail.cf as you do changes.
The Webmin procmail screen just manages content of /etc/procmailrc file.
And as far as A, MX, and CNAME records go, at this jucture there are no
MX records for this host. CNAME works for a quick fix, though I could
just as easily gone the second A record route, I have for other things.
BIND I am kind of comfortable with sendmail and procmail are all rather
block-box to me and I need to change that somewhat.
So on to your comments, then some proper testing (rebuilding .cf first)
then if need as on a sendmail list and here...
Professional Software Engineering wrote:
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.
Actually Webmin mucks up some of my $ORIGIN stuff and I have to had
edit, but basically this is what I have.
You should be aware that Procmail is an LDA - Local delivery agent. It
knows _NOTHING_ of DNS or SMTP.
But if the mail does not get to the box, so I do need the DNS stuff.
Just added for an attempt at clearity. ;)
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:
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
MAILER(procmail)dnl
My sendmail.cf has the lines:
Mprocmail, P=/usr/bin/procmail, F=DFMSPhnu9,
S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,
A=procmail -Y -m $h $f $u
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
A=procmail -t -Y -a $h -d $u
: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.
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
header unaltered so that Asterfax knows where to fax the missive. Thus
you can't vary well create userids. That is why I have to get sendmail
to had off the mail to procmail before it checks for valid users or
fax.htt-consult.com. But I still have to have sendmail do its userid
check for mail to @sip.htt-consult.com
news: comp.mail.sendmail would be a good place to start reading.
Will look some more at sendmail alternatives.
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 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
community edition....
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.
I was shotgunning as to why the TO header was being changed.
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)?
Webmin has rebuilt all of the sendmail databases vary nicely for me.
I got this from what little Asterfax help with sendmail exists. To get
sendmail to hand off mail for fax.htt-consult.com to procmail, not to
process that mail directly.
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.
What 'evidence' will I find that mail went to the LDA? in maillog or
will there be some other log?
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.
Thought so. This seemed limiting to me, but pulled it from elsewhere,
the old cut-and-paste.
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`$$
Got it.
: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).
Gee that is what I had initially.
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).
They are there.
But more testing based on a few observations you made.
thanks for taking the time to review this.
____________________________________________________________
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