Re: [Fetchmail-users] Duplicate Emails

[Julian B. <jul...@bt...>]

Hi Matthias,

Thanks for the feedback and appreciate that the original functionality was more applicable to a bygone era (older time). I will pass on the X-UID question; it’s all Greek to me ;-)

For those that may search and find this post. I think I have a solution to the de-duplication as I was always going to use dovecot as my LDA and find I can use a sieve filter to achieve exactly what I want along with setting Thunderbird labels. This is not a reflection on fetchmail but rather an observation on a pragmatic workflow in today’s era.

Thank you very much for your time.

Best wishes,

Julian

On 29 Jan 2021, at 18:38, Matthias Andree <mat...@gm...> wrote:
> 
> Am 29.01.21 um 08:59 schrieb Julian Bane:
>> Good morning Mattias and all,
>> 
>> I have managed to suppress the X-Original-To header by
>> setting*enable_original_recipient = no*" in the postfix configuration
>> file. But still don't get duplicate emails suppressed, though the
>> X-Original-To header is. (Matthias - I can send you the mailbox file
>> if you want).
>> 
>> I have cut out two emails and verified they still have differences in
>> the headers (some de-personalization done):
>> 
>>    1,3c1,3
>>    < From XXX...@co...  Fri Jan 29 07:38:31 2021
>>    < Return-Path: <XXX...@co...>
>>    < Delivered-To: up...@my...
>>    ---
>>> From jul...@co...  Fri Jan 29 07:38:29 2021
>>> Return-Path: <XXX...@co...>
>>> Delivered-To: do...@my...
>>    38c38
>>    < X-UID: 24
>>    ---
>>> X-UID: 23
>> 
>> It's hard to see how you could ever get two identical sets of headers
>> for de-duplication to work.
> 
> Julian,
> 
> As stated earlier, the deduplication code is from another era, when the
> envelope-recording headers such as X-Original-To, Envelope-To,
> Delivered-To were not in widespread use, and it was meant as a hack to
> avoid local spool explosions when fetchmail resorted to guessing
> recipients from the To:/Cc: headers (which breaks with Bcc: quite
> obviously) because then it did not have a 1:1 relationship between
> server-side message and message-to-ship-onwards.
> 
> About X-UID, is it actually transmitted over the wire, or will your
> server software suppress it? I guess it goes hand in hand with the
> folder-internal status message that is also not sent over the wire.
> 
>> 
>> Not wishing to either make trouble or make work for others but could
>> the documentation be reworded to reflect how the de-duplication works.
>> Currently it says "/A piece of mail is considered duplicate if it has
>> the same message-ID as the message immediately preceding and more than
>> one addressee/".
> 
> Definitely yes because what you quote is plainly does not refer to what
> the code does. I will see to fixing the manual page. I've filed an issue
> so I don't forget, because I can't get to it right away. This is 6.4 stuff.
> 
> https://gitlab.com/fetchmail/fetchmail/-/issues/29
> 
> Best regards,
> MNatthias
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users