Re: Hiding one's email source username/hostname/ISP

[Bob Carragher]

(I've combined replies, but used the message ID of Tom's first
reply; hopefully that doesn't break the archive.  B-)

Thank you Tom, David, Krullen, and Ken, for your helpful replies!

Tom:  good point about false-looking Received: headers!  I
definitely want to avoid making my email look even more spammy
than it already is deemed by certain institutions.  B-[  Thanks
also for finding the "clientname" entry in mts.conf -- which I
had previously set to "Hikaru" because, without it, my emails
would use "localhost.localdomain" and look even more spammy.
(This was a fix that folks on this mailing list kindly gave me
back in 2018.  B-)

David:  thanks for the pointer to the "-client" option to
send(1).  (Actually, it's probably a reminder -- I feel like it
was mentioned back when someone gave me the "clientname" fix.)
I do see in the headers of your reply that the first "Received:"
header uses "HiddenHostname" ... but also the FQDM(?) of your
Verizon connection (and its IP address):

     Received: from HiddenHostname (pool-74-104-144-20.bstnma.fios.verizon.net. 
[74.104.144.20])
             by smtp.gmail.com [...]

So, while I could hide the hostname of my laptop, I wouldn't be
able to hide its "public"/ISP-assigned name (and IP address).

Ken:  I would not be opposed to documenting this particular
undocumented switch, though I can imagine why it was left
undocumented in the first place.

                                Bob

On Sun, 07 Mar 2021 11:14:44 -0500 Tom Lane <tgl@sss.pgh.pa.us> sez:

> Bob Carragher <dnc2dnc@gmail.com> writes:
> > In emails that I send, if you look at the Received: header chain,
> > you'd find a line that resembles,
>
> >      Received: from Hikaru (xxxxx.comcast.net. [IP-address])
> >             by smtp.gmail.com [...]
>
> Received: lines are generally added by each MTA that the message
> passes through.  In this case it was smtp.gmail.com that added that;
> it's not under your control.  You can probably modify the "Hikaru"
> part, as I believe that just comes from the HELO command your mail
> client uses.  I'm not sure which part of the nmh configuration
> that comes from, but it can't be too hard to find.
>
> Keep in mind that Received: lines that look falsified in any way
> are universally treated as a sure sign of spam.
>
>                       regards, tom lane



On Sun, 07 Mar 2021 11:56:31 -0500 Tom Lane <tgl@sss.pgh.pa.us> sez:

> David Levine <levinedl@acm.org> writes:
> > Tom wrote:
> >> Received: lines are generally added by each MTA that the message
> >> passes through.  In this case it was smtp.gmail.com that added that;
> >> it's not under your control.  You can probably modify the "Hikaru"
> >> part, as I believe that just comes from the HELO command your mail
> >> client uses.  I'm not sure which part of the nmh configuration
> >> that comes from, but it can't be too hard to find.
>
> > It derives from the (hidden/undocumented) client switch to send(1).
> > I'll try sending this message with "send -client HiddenHostname".
>
> Ah.  And after digging around a bit, I found this on my own machine:
>
> $ cat /etc/nmh/mts.conf
> # nmh mail transport interface customization file.
> ...
> # Name shown in HELO header:
> clientname: sss1.sss.pgh.pa.us
>
> which you can match up against the first Received: line in my own
> outgoing mails.  So that's probably a better place to configure
> it than messing directly with send(1) switches.
>
>                       regards, tom lane



On Sun, 07 Mar 2021 20:43:51 -0500 Ken Hornstein <kenh@pobox.com> sez:

> >It derives from the (hidden/undocumented) client switch to send(1).
> >I'll try sending this message with "send -client HiddenHostname".
>
> We should document that switch, I think.  Even internal switches probably
> should be documented.
>
> --Ken