Am Sonntag, den 20.01.2013, 01:37 +0000 schrieb Pete Biggs: [â]
here but rather a very bad implementation decision in my opinion.It's the "normal" way of generating Message-IDs - I've seen lots of other MUAs use it.What I am trying to request here is that Message-ID should not use _plain text_ internal_hostname.internal_domainname. The simplest solution in my opinion is to use any kind of one way encryption for the existing right of @ part. This would preserve all existing Message-ID logic and completely hide internal_hostname.internal_domainname. Adding sender email domain (after encrypted part) aka Thunderbird is optional... Is my explanation clear?I understand what you are saying, I just don't think it's an issue. What is wrong with using the name of the computer in the Message-ID? The host is behind a NAT, so it's not as if you are inviting people to try and attack it. So yes, it exposes some information, but that information is, as far as I can see, fairly useless. Unless, of course, you have called your computer something really embarrassing ...
By the way, if I recall correctly, the same as Eugeneâs doubts were the reason, that some of Microsoftâs mail programs (I think Exchange, Outlook, â) do not include the header field `Message-ID` at all. Which is quite sad if you are using threading in your email program.
Nevertheless, if you think it's an issue, then file a bug report - it's the only way something is going to change. It's then up to the developers to decide if it's something they want to change.
Eugene, please reply with the ticketâs Bugzilla URL if you create it. Should you have programming experience you can even send a patch. 1. Check out the Git tree. 2. Find out were the message ID is generated and adapt the logic to a choice. 3. Add an option for the user to enable for example hashing of the hostname. Thanks, Paul
Attachment:
signature.asc
Description: This is a digitally signed message part