I see, ok. Now I see the path the message is taking.
Just for reference because I know there are other people out there
trying to cope with sendmail's small...err, "manhood", here is a
procmail script that I use to *HACK* the information TMDA wants.
Just remember everybody, this is a HACK and is PRONE to
MISINFORMATION. In other words, it just isn't possible for procmail
(or any other MDA) to reliably recreate envelope recipient information
when using sendmail. In particular, there are a number of reasons why
this will fail and they all result in the Received line not having the
"for xxx" information. I'm strongly considering building a milter
plugin that triggers on the envelope callback and inserts a
Delivered-To header. Don't ask me why sendmail _still_ doesn't supply
this information either in headers or environment variables.
/etc/procmailrc, trimmed
PMDIR=/etc/mail
INCLUDERC=$PMDIR/procmail.get-recipient
INCLUDERC=$PMDIR/procmail.virus.rc
INCLUDERC=$PMDIR/procmail.spamassassin.rc
INCLUDERC=$PMDIR/procmail.tmda-prep
procmail.get-recipient, full
SHELL=/bin/bash
verb=$VERBOSE
VERBOSE=yes
# *** WARNING ***
# This does NOT work reliably, does NOT get BCC information
# In other words, tell sendmail folk to put the d*mn envelope
# recipient in the environment. This makes grand assumptions
# about the intended recipient and is a HACK, not a solution
:0
*$ ^Received:.*for (<|)\/[^> [EMAIL PROTECTED]> ]+\.[^> ]+[>]?
{
R="$MATCH"
}
:0 E
*$ ^To:.*\/[EMAIL PROTECTED]> ,]+
{
R="$MATCH"
}
:0 E
*$ ^Cc:.*\/[EMAIL PROTECTED]> ,]+
{
R=$MATCH
}
:0
* ! MATCH ?? ^^^^
{
RECIPIENT=$R
:0f
|formail -I "Delivered-To: ${R}"
}
VERBOSE=$verb
and finally, procmail.tmda-prep
## Set the necessary environment variables.
EXTENSION="$1"
:0
* EXTENSION ?? .
{
DELIMITER="+"
}
# hopefully the recipient was pre-set in the hack file
:0
* ! RECIPIENT ?? .
{
RECIPIENT="[EMAIL PROTECTED]"
}
SENDER=`formail -x Return-Path | sed 's/[<>]//g;s/^[ ]*//'`
Remember folks, this is a HACK, not a solution.
What it does:
a) tries to get the recipient via the first available Received line, or
b) tries the first To line, or
c) tries the first Cc line
If this doesn't yield something, then the default [EMAIL PROTECTED] is
generated and used. If it did yield something, that something is
inserted into the message for a Delivered-To header, replacing any
existing Delivered-To header.
David
p.s. feel free to tidy up and put into a "why sendmail sucks for
envelope information" section in the FAQ.
Tim Legant wrote:
David Ford <[EMAIL PROTECTED]> writes:
Yes, I'm using sendmail and the end recipient address wasn't correctly
assumed. (don't go there, i don't like sendmail's lack of this info)
Ah. I didn't notice that in the message headers.
However, my DELIVERY method is procmail, why would tmda be calling
sendmail for final delivery?
DELIVERY = os.path.expanduser("|/usr/bin/procmail
~/.procmailrc-tmda-delivery")
When a message is confirmed (or released from tmda-pending/tmda-cgi),
TMDA "delivers" the message by re-sending it to the original
recipient. When the re-sent message comes back through the delivery
process, TMDA recognizes it as a successfully confirmed (or released)
message and at that point uses the DELIVERY configuration option to
actually perform final delivery.
The problem you ran into was at the re-sending stage, when TMDA was
trying to send the message to the address in X-TMDA-Recipient. The
message was apparently getting lost before reaching TMDA the second
time and therefore the real delivery was never happening.
Tim
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
|
