Truncated received header

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Olm
Reply | Threaded
Open this post in threaded view
|

Truncated received header

Olm

Hi all!

Thanks to Wietse for Postfix, I still love the wrappers…

Let me first quote to a past (7 years ago) subject, where I found the one and only explanation for a problem I'm encouting :

>> I am running majordomo with postfix for a number of email list, and I
>> have some trouble tracking down bounces. I thought that if I could have some
>> customized Received: headers with the envelope receiver logged
>> eg by "for <user>" then I would be able to track some mutating adressees.
>> Seems like some postfixes do that, but mine does not.
>> I could not find something on it in the documentation or via google.
>
> Postfix logs "Received..for <recipient>" only if there is exactly
> one recipient.  Otherwise there would be a privacy violation of
> BCC recipients, including the addresses of mailing list members.

I use the "for <myrecipient>" information to deliver the messages in the right folder of a catch-many adresses mailbox.

In case the <myrecipient> address is in BCC, and the main recipient is not managed by my MTA (aka not in mydestination), there's no problem : the cleanup process calls back the complete Received header and I get what I need in the mail delivered to my catch-many adresses mailbox.  NB: there's no mention of <myrecipient> in the message received by the main recipient.

But if the main recipient's domain is managed by postfix, the <myrecipient> address still in BCC, the Received header called back by the cleanup process is truncated.  And now I know why !


So here's my question : Why can't I get no mention of <myrecipient> in the message received by the main recipient (as in the first case) in the second case ?
And , if there's no way to get it, is there any way I can split the message in two ?


I already spent a few hours tracing the problem, playing with 'cleanup -v' and filtering the logs, I'd be happy trying any suggested method…
Thanks!

--
Olivier Le Monnier — ☎ 023156.6209
Pôle Infrastructures — SysAdmin Linux
Direction du Système d'Information
Université de Caen Normandie
Reply | Threaded
Open this post in threaded view
|

Re: Truncated received header

Bill Cole-3
On 29 Nov 2017, at 4:05 (-0500), Olivier Le Monnier wrote:

> I use the "for <myrecipient>" information to deliver the messages in
> the right folder of a catch-many adresses mailbox.

That's a hard way to do this...

An easier way is to do this is to use the X-Original-To header, which
Postfix adds by default to every message when it is queued for local
delivery. If you're not seeing that header in delivered mail, you may
have enable_original_recipient set to "no" or may be running a
ridiculously old version of Postfix.

> In case the <myrecipient> address is in BCC, and the main recipient is
> not managed by my MTA (aka not in mydestination), there's no problem :
> the cleanup process calls back the complete Received header and I get
> what I need in the mail delivered to my catch-many adresses mailbox.  
> NB: there's no mention of <myrecipient> in the message received by the
> main recipient.
>
> But if the main recipient's domain is managed by postfix, the
> <myrecipient> address still in BCC, the Received header called back by
> the cleanup process is truncated.  And now I know why !
>
> So here's my question : Why can't I get no mention of <myrecipient> in
> the message received by the main recipient (as in the first case) in
> the second case ?

I think that lost something in translation...

Can you provide actual examples? I think you can solve your problem by
using X-Original-To instead of parsing Received, since this use case is
precisely why X-Original-To exists.

> And , if there's no way to get it, is there any way I can split the
> message in two ?

I don't recommend it, but you could set smtpd_recipient_limit to 1,
which causes Postfix to reply to the second and any subsequent RCPT
commands with a 4xx reply code. A well-behaved sender will retry the
message later for those recipients. In principle this works at the cost
of delaying delivery for some recipients of a multi-recipient message
for unpredictable periods. In practice doing that has historically
caused some cases of non-delivery for all but the first recipient,
however I expect that nearly all senders with that sort of breakage have
succumbed to natural selection. Depending on your local delivery setup,
you may be able to do the serialization of deliveries locally, reducing
delay and risk of non-delivery.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole