CC destinations dropped

[Eric Luyten]

On Fri, July 20, 2012 1:01 pm, Adam  Tauno Williams wrote:
> On Thu, 2012-07-19 at 19:22 -0400, brian wrote:
>
>> A client of mine is complaining about not receiving certain messages.
>> Her colleague is also being sent them and receives them just fine. She
>> insists that they are not being sent to her junk folder and that she has no
>> filters that might be moving them elsewhere.
>
> You can check for existence of a SIEVE [filter] script
> in /var/lib/imap/sieve/{letter}/{username} [you path may vary a little, but
> something like that].
>
> You can grep -d recurse
> {message-id} /var/lib/spool/imap/{letter}/user/{username}/* to see if it
> is really there.  It may be there event if deleted and expunged if
> delayedexpunge is enabled.
>
> Otherwise it is almost certainly an MTA issue.
>
>
>> I believe the problem does not involve postfix, as pipe appears to be
>> sending both. It looks to me as if lmtpunix is looking at just the one
>> address and thinks there's a duplicate. Note the two duplicate_check lines,
>> both of which reference the julia account. I've sent a test message and
>> indeed the duplicate_check again referenced only the julia account again,
>> and admin did not receive it.
>
> Where is the e-mail coming from?  It is possible it really is a
> duplicate message-id?  some real-world devices recycle message ids
> [our Xerox document centers do].


Hear, hear.     Exchange "re-send", anyone ?


>> postfix/pipe[26606]: 66E757A25FC: to=<admin at DOMAIN.ORG>,
>> relay=procmail, delay=0.2, delays=0.16/0/0/0.04, dsn=2.0.0, status=sent
>> (delivered via procmail service)
>> postfix/pipe[26606]: 66E757A25FC: to=<julia at DOMAIN.ORG>,
>> relay=procmail, delay=0.2, delays=0.16/0/0/0.04, dsn=2.0.0, status=sent
>> (delivered via procmail service)
>>
>
> "delivered via procmail" ???


On the day I cut procmail out from between our Postfix and Cyrus, all
(well, one major, causing newly arriving messages to disappear) delivery
mysteries disappeared.
The less components stacked one upon another, the less issues you're
likely to witness.


Eric Luyten, Computing Centre VUB/ULB.