Hi,

I'm the one who originally had the idea to set a better hostname inside
the message id and therefore wrote the patch for go-message. After the
new release including the patch I was going to submit something here,
but your solution is already good IMHO especially that you even though
about backwards compatibility!

Thanks
j.r

Hi,

> Thanks, sent a v2.
Sorry for my mistake, but seems like it not only requires gpg for the
test, but the full gnupg metapackage because it also does signing etc.
Could you maybe send a v3?

Thanks
j.r

Hello Drew,

seems like this does fail because it's missing 

> checkdepends="gpg"

If I add this locally I could build the package.

Thanks,
j.r

On Sat Sep 4, 2021 at 5:30 PM CEST, Connor Kuehl wrote:
> Should this be upstreamed into go-messages instead then? Perhaps
> GenerateMessageID could be updated to take the hostname as an argument.
This sound resonable, yes, but then we would also need to update
go-message to the latest version. I don't know the codebase enough to
tell if this might break something.

j.r

go-messages GenerateMessageID does generate the Message ID based on the
hostname of the local machine. This is ok in this context because the
lib does not know really anything of the surroundings. But aerc does
know about the sender domain and could use this instead of the hostname.
This also aligns with the recommendation of RFC4322 to use a unique
domain name, to ensure the uniqueness of the whole Message ID [1].

A side effect of this change is that it also improves the score of some
spam filters a bit, if an E-Mail has a fully qualified domain name after
the @.

This patch fixes https://todo.sr.ht/~sircmpwn/aerc2/526

[1] https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.4
[message trimmed]

Hi Vladimír,

looks like there is already a ticket for tracking this feature and also
a bit of a discussion around how it would fit best into the UX:
https://todo.sr.ht/~sircmpwn/aerc2/94

On Fri Sep 3, 2021 at 11:39 AM CEST, Vladimír Magyar wrote:
> It's good to see that the progress on aerc is more dynamic in the last
> weeks. But one feature, a crucial one I would say, is to display
> messages in threads.
>
> It is too complicated to search for the previous mails, especially when
> they are already in archive or trash. Also many times I've seen comments
> that the lack of this feature prevents new people to use aerc.