At 12:26 2004-05-19 -0500, Jack L. Stone wrote:
I did not intend to give the impression that ALL dups are getting through
my dups recipe -- only that one sender.
Indeed, but do you _know_ you're getting other dupes: perhaps it seems that
this one sender is getting through when in fact they're your only real
source of duplicates?
Further, did you read that I have compared the headers (including ID) --
and displayed a copy of one such dup on a URL. They are exactly the same.
http://www.antennex.com/tmp/dups.txt
These (with added From_ header) chucked at the recipe (with some undefined
variables properly defined - $FORMAIL and $DUPS) seem to be identified as
dupes just fine.
I have performed every single one of those things you listed -- some
several times over the span of a year.
What you've posted thus far provides a rather incomplete picture of the
situation (such as no verbose logs of these two messages coming through
procmail), so all we've got is your word for it that there's absolutely
nothing wrong with your recipe and all the variables are defined, etc.
Indeed, I have asked the sender to check his email client setup more than
once because I suspected he was placing my address in the To/CC/BCC address
slots 2 or 3 times to create those extra messages -- and may be using a
template.
This would be _POSITIVELY_ ruled out if you've ever examined your MTA
maillog - no need to contact the sender if you KNOW they're sending only
one copy and the ncrpts=1.
FTR, unless you have a buggy MTA, your MTA should resolve the recipients
down to the UNIQUE addresses provided in the envelope, and deliver only one
copy. You should be able to verify this by connecting via a telnet session
with your SMTP server and punching in a complete SMTP dialogue.
Also, did you see my follow-up message? I diverted his messages to another
email account to "trap" them and found that I eas receiving TRIPLE copies
not just dups.
Sorry, but 'diverted to another account' is extremely vague - did you use
an MTA alias, forward in procmail, what? Is this other account subject to
a procmail filter? Do you have a GLOBAL procmailrc that could be causing
you grief?
If you're going to divert, just make an alias that includes a FILE
specification, so there's no LDA involved (and indeed, no need for another
user account).
Thus, the dups recipe must be catching the one copy and then
the other two get passed through.
If you say so. If the diverted copy is showing three, then there should be
THREE entries in the MTA maillog. How's about you excerpt this and publish
it on your webspace?
I am having another round of checking with the sender and have told him of
the triple copies. Although this is not a major problem, because I still
can delete extras as I have done for more than a year, BUT, when he sends
large attachments, this means a 1MB attachment is really 3MB.
Such things should stand out in the maillog when looking for dupes.
Lastly, of course all variables are defined and all recipes are working as
they should -- except this one single sender.... he is a technical author
of mine and is not malicious.
Well, if there were an MTA problem between your host and his, and his host
THOUGHT the message didn't get through and then re-tried, you'd get
multiples. But then, these would show up in the MTA maillog as unique
events AND the Received: chain would have different SMTP transaction ids.
So, it stands that there's a local duplicate being constructed. Either at
the MTA heading to the LDA, or within the LDA handling -- the
/etc/procmailrcs or the user procmailrc.
Have you tried, way up at the top of your procmailrc - before all the other
fun stuff, just putting a recipie to store this sender's messages? Even a
copy would be sufficient:
:0c:
* ^From:(_dot_)*some_yo_yo(_at_)domain(_dot_)tld
yoyomail.mbx
Then, you can refer to this mailbox and see how many copies procmail was
handed AT THE OUTSET. If there's only one copy of each message in there,
then your problem is a buggy use of a 'c' flag on a recipe later on (and it
stands to reason that would be AFTER the messageid cache recipe). A recipe
like:
:0c
{
:0
* some condition that just happens to NOT match your buddy's messages
mbx
}
will cause an additional message to creep in.
If you've really checked everything I posted, AND you're positive you have
no errant cloning recipes, then apparently gremlins are fidgeting with your
mailbox file. That's fine if you believe in gremlins -- otherwise, the
problem is that you haven't _actually_ checked everything you've been
advised to. You may believe you have, but you haven't.
I cited checking the VERBOSE log three times in that list because it isn't
something to be taken lightly - you have a mail problem - if you're logging
with VERBOSE, the cause of the problem should be very evident.
Running the messages against your .procmailrc running under a SANDBOX to
obtain that VERBOSE logging without logging interference from all the other
email you're handling.
Of course, since you have checked everything you've been advised to, that
means that you HAVE run a SANDBOX test. Please post the URL to the
unedited VERBOSE logs from that test - it should be a simple matter to
identify the problem.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail