Re: Duplicate Emails

Julian Bane via Fetchmail-users <[email protected]>
Newsgroups gmane.mail.fetchmail.user
Message-ID <[email protected]>
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 <[email protected]> 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 [email protected]  Fri Jan 29 07:38:31 2021
>>    < Return-Path: <[email protected]>
>>    < Delivered-To: [email protected]
>>    ---
>>> From [email protected]  Fri Jan 29 07:38:29 2021
>>> Return-Path: <[email protected]>
>>> Delivered-To: [email protected]
>>    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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users



_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.