Laurent Fousse wrote:
> Hello,
>
> * Magnus Holmgren [2006-08-04]:
>
>>In my setup, procmail is run twice, once for each recipient.
>>Exim removes duplicates if two addresses are aliases of a common address, for
>>example if you have the following in /etc/aliases:
>>
>>bar: foo
>>
>>then a mail to foo and bar will only be delivered once.
>>
>>If you post the relevant parts of your configuration we can help you find out
>>what's wrong. Also, you have checked in the log that procmail is indeed only
>>called once, right?
>
>
> I have:
>
> testexim1: laurent
> testexim2: laurent
>
> in my /etc/aliases file. If I send an email to both
> testexim1@??? and testexim2@??? from
> another host, I see from the procmail log that:
>
> - procmail is run once,
> - the RECIPIENT variable is set to laurent@???
> which is the local recipient after alias expansion is done. The
> actuel recipients are stored in the Envelope-To header,
> - the exim log file shows only a delivery to one recipient:
>
> 2006-08-05 12:52:21 1G9JlV-0007gO-GV <= laurent@??? H=smtp.conuropsis.org (topaz.conuropsis.org) [217.115.192.216] P=esmtps X=TLS-1.0:RSA_AES_256_CBC_SHA1:32 S=634 id=E1G9JlU-00073E-3m@???
> 2006-08-05 12:52:22 1G9JlV-0007gO-GV => laurent <testexim1@???> R=procmail T=procmail_pipe
> 2006-08-05 12:52:22 1G9JlV-0007gO-GV Completed
>
> My system_aliases router:
>
> system_aliases:
> debug_print = "R: system_aliases for $local_part@$domain"
> driver = redirect
> domains = +local_domains
> allow_fail
> allow_defer
> data = ${lookup{$local_part}lsearch{/etc/aliases}}
>
> My procmail router:
>
> procmail:
> debug_print = "R: procmail for $local_part@$domain"
> driver = accept
> domains = +local_domains
> check_local_user
> local_part_suffix = -*
> local_part_suffix_optional
> transport = procmail_pipe
> require_files = ${local_part}:${home}/.procmailrc:+/usr/bin/procmail
> no_verify
> no_expn
>
> My procmail_pipe transport:
>
> procmail_pipe:
> debug_print = "T: procmail_pipe for $local_part@$domain"
> driver = pipe
> path = "/bin:/usr/bin:/usr/local/bin"
> command = "/usr/bin/procmail -p"
> batch_max = 1
> return_path_add
> delivery_date_add
> envelope_to_add
>
>
I've just run some tests with no procmail involvement and am getting a similar
result - but perhaps a new clue as to where the 'duplicate' is disappearing:
Background:
- 'Unseen' is used to chain both user-Maildir delivery and user-archive-Maildir
delivery routers and shell-Maildir delvery and shell-archive-Maildir routers.
- Shell archive and user-archive are separate routers, but (in this case)
deliver to the same Maildir. The alias points to the same Maildir as the user
being tested.
Test:
- I compose and send a message in Mozilla Mail with two 'To:' addresses. One is
direct to the destination Exim user, the other to a system alias on the same
server known to map to that same destination user.
- The ~/mainlog entry shows all four deliveries - user, shell, user-archive,
shell-archive.
The MUA sees ONE message.
In order to remove any receiving MUA filters from the equation, 'lynx' is used
to directly inspect the relevant Maildirs via ssh.
Weirdness:
- Two copies of the message, both with the same sending-MUA-assigned Message-ID
and same Exim-assigned queue ID are found in adjacent to each other in the
'shared' archive Maildir.
- Only ONE copy is found in the user-Maildir (with either the MUA or 'lynx'.
First Wrong Guess:
- Exim has made two 'writes' with identical generated filename to the
user-Maildir, thereby over-writing one with another, leaving one only, or IOW -
'stripping' the duplicate. Doesn't seem plausible. Hazel & Co. are smarter than
I am on that score.
Sure enough, further inspection finds otherwise:
- Exim has actually created a Maildir for the *unexpanded* alias address and
placed a copy of the message there. As no POP/IMAP is aimed at this
Maildir/account, it is 'invisible' until the mailstore is swept with 'lynx'.
('lynx' is used for primarily for ease of navigation in ssh vs an editor - the
messages involved are pure text).
This has not been an issue because this happens only with 'cross box' traffic.
External arrivals are handled differently on my servers.
Any chance of something similar happening on your system at the output side of
your procmail process? i.e. - an Mbox or Maildir being written to that is not
ordinarily being looked at?
HTH,
Bill Hacker
