Greetings Mr. Chappa and the rest of the alpine-info mailing list!!, This is simply a follow up to a portion of a post I made quite some time ago. See further below for the full contents of that post, but I wanted to expand on this request with some new information:
> Another possible privacy related information leak can be found in the way > that Alpine can send your host in the SMTP EHLO or HELO greeting. > Can another option you can use to change it be added to handle this problem? > Or maybe Alpine can send a more generic host such as [192.168.1.1] with an > opt out option instead? I would still love to see this become configurable in Alpine, but I wanted to point out another interesting approach Alpine could possibly take by default: to use a host it controls, like maybe setting up a new ehlo.alpineapp.email or similar subdomain? This is an approach already used by Thunderbird, which sends ehlo.thunderbird.net, and FairEmail, which sends dummy.faircode.eu. Each of those hosts can actually be visited in a web browser to get more information on the privacy concerns behind their use. ***---> Perhaps Alpine can add a new option that offers three choices for what to send in the SMTP EHLO/HELO command: 1) choose the new default? behavior of sending an Alpine specific host, 2) choose the old default behavior of sending your real host, or 3) choose to enter a custom value? In addition, I had not considered this item in my original SMTP privacy leak assessment: > * Timezone: The sent date is usually encoded in the timezone of the sender. > By looking at the offset from the Greenwich Mean Time (GMT), the recipient > learns from which longitude a message was sent. In my opinion, mail clients > should always encode the Date field in Greenwich Mean Time. Found here: https://explained-from-first-principles.com/email/#sender-towards-recipients - Email explained from first principles Alpine does seem to have a "Suppress Timezone Comment When Sending" "[ Advanced User Preferences ]" option, but it only causes Alpine to strip out the parenthesized symbolic timezone comment from the mail it sends, in other words: Thu, 01 Jan 1970 12:00:00 +0000 (UTC) becomes: Thu, 01 Jan 1970 12:00:00 +0000 ***---> Extra feature request: add a new option to Alpine to force it to use UTC time in all relevant headers to mitigate this privacy leak. On 6/13/24 12:12, via Alpine-info wrote: > Greetings alpine-info mailing list!! > > Some time ago when Mr Chappa was adding oauth2 support for Alpine and had > been working on a privacy policy for it he made an interesting comment: > > Date: Thu, 11 Jun 2020 14:05:59 -0600 (MDT) > > From: Eduardo Chappa <[email protected]> > > To: Andrew C Aitchison <[email protected]> > > In-Reply-To: > > <[email protected]> > > Message-ID: <alpine.LNX.2.22.439.2006111239040.9525@linux-aknz> > > References: <[email protected]> > > Cc: [email protected] > > Subject: Re: [Alpine-info] Microsoft Outlook "Modern Authentication" > > > > - SNIPPED - > > In addition, Alpine discloses its name and version to IMAP servers that > > support the ID extension. I put this in a separate category of privacy > > disclosure. I think this information is valuable for the server > > maintainers, because it establishes our presence (in other words, it tells > > the ownser of the server that there are users using Alpine, and so they > > need to support us.) > > - SNIPPED - > > Does Mr Chappa still maintain this position or would he reconsider and maybe > make this feature something that you can change or opt out of even disclosing > at all as there are practical benefits too. > It can help work around buggy IMAP servers as seen here: > https://support.mozilla.org/si/questions/1275339 - How do I fix "Unrecognized > command: ID" | Thunderbird Support Forum | Mozilla Support > > Another possible privacy related information leak can be found in the way > that Alpine can send your host in the SMTP EHLO or HELO greeting. > Can another option you can use to change it be added to handle this problem? > Or maybe Alpine can send a more generic host such as [192.168.1.1] with an > opt out option instead? > > These changes would help mitigate the last low hanging fruit privacy leaks in > Alpine that I am aware of?: > - IMAP > > Current mitigations: > > > > ? > > > > Todo: add Suppress IMAP ID When Connecting option ? > > - NNTP > > Current mitigations: > > > > v2.26 added: > > * To protect the privacy of a user, the message-id of a message will be > > generated using the domain in the From field of the message. > > > > v2.24 added: > > * Modifications to protect the privacy of users: > > + Alpine uses the domain in the From: header of a message to generate > > a message-id and suppresses all information about Alpine, version, > > revision, and time of generation of the > > message-id from this header. This information is replaced by a > > random string. > > > > [ News Preferences ] > > [X] Hide NNTP Path (NNTP) > > > > [ Advanced User Preferences ] > > [X] Scramble the Message-ID When Sending (SMTP) > > [X] Suppress User Agent When Sending (SMTP) > > > > Todo: None ? > > - POP3 > > Current mitigations: > > > > ? > > > > Todo: None ? > > - SMTP > > Current mitigations: > > > > v2.26 added: > > * To protect the privacy of a user, the message-id of a message will be > > generated using the domain in the From field of the message. > > > > v2.24 added: > > * Modifications to protect the privacy of users: > > + Alpine uses the domain in the From: header of a message to generate > > a message-id and suppresses all information about Alpine, version, > > revision, and time of generation of the > > message-id from this header. This information is replaced by a > > random string. > > > > [ Sending Preferences ] > > [X] Do Not Generate Sender Header (SMTP) > > > > [ Advanced User Preferences ] > > [X] Scramble the Message-ID When Sending (SMTP) > > [X] Suppress User Agent When Sending (SMTP) > > > > Todo: add Change SMTP EHLO or HELO Greeting and or Use Generic SMTP EHLO or > > HELO Greeting option ? > > > I became interested in seeing these issues fixed after reading this article > which also notes other possible issues: > https://explained-from-first-principles.com/email/#sender-towards-recipients > - Email explained from first principles > _______________________________________________ > Alpine-info mailing list > [email protected] > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info > _______________________________________________ Alpine-info mailing list [email protected] http://mailman23.u.washington.edu/mailman/listinfo/alpine-info
