On 4/15/22 10:15 AM, Matus UHLAR - fantomas wrote:
On 14.04.22 08:26, Emmett Culley wrote:
I recently changed the host name of one of the servers from one domain I am
hosting to another of the domains the server is serving.
Upon verifying the server I noticed that the Received: headers on email sent
via that server now have the new host name
This is completely irelevant to mail processing, unless the new mail server's
name does not exist in DNS, or has a SPF record that disqualifies the server
from announcing itself.
and so causes Thunderbird to show the from address in red for emails from
domains that are different from the server's hostname.
Sorry, I have no idea what you are talking about. Can you provide a screenshot
somehow?
Is there anything I can do to specify that the Recieved: headers have the
"correct" domain name depending on what domain is sending an email (From:)?
you do not need this. your problem apparently
I have DKIM working in such a manner. When an email is sent for domain.one
(From: domain.one) the dkim signature contains the signature for domain.one and
if sent for domain.two (From: domain.two) it contains the dkim signature for
domain.two. No matter what the server's hostname is set to.
I guess I am asking if there is any way to map the sending domain written to
the header (From.: domain.tld) to the domain the email was sent as? Similar to
how opendkim does when choosing the DKINM signature to add to the outgoing
email's header.
the domain in From: should be the one you or other senders have configured in
thunderbird or other mail clients, and is not related to the mail server's name.
This was caused by a missed configuration with my mail server's openDKIM
configuration. Thanks for the clue.
On 4/14/22 9:58 AM, Wietse Venema wrote:
The Received: headers contain the value of the "myhostname" parameter,
i.e. the identity of this Postfix MTA instance. This name should
match the IP address where the MTA sends and receives mail.
Postfix can send and receive email on behalf of many domains. Email
is not like HTTP, and there is no requirement that the Postfix MTA
identity matches the name of every domain that it handles mail for.
But it is supported ever since Postfix got SNI support a few years
ago.
On 14.04.22 10:02, Emmett Culley wrote:
Thanks Wietse. I will study up on SNI. I am working on new servers with
RockyLinux 8 and so will also be using a newer version of postfix.
SNI is only used when you connect to the server to send or receive
e-mail, and your customers have multiple servernames configured in their
mail clients.
If you have @example.com domain address and connect to mail.example.com, you
only need SNI if other users with @example.net address use mail.example.net
on the same server. This way, if you have separate certificates for
mail.example.com, mail.example.net etc, you need SNI.
If you have single certificate with alternative names mail.example.com,
mail.example.net etc, you do NOT need SNI.
Usually, people use mail.example.org as smtp/imap/pop3 server and
use @example.com or @example.net addresses, and server only needs
certificate for mail.example.org.
I see that I was concerned about nothing, simply because thunderbird had a working DKIM
checker. I had assumed it was a misconfiguration on the mail server that was causing the
warning. It wasn't until I looked a the header source for those emails that looked
"bad" that I found they did not have a dkim signature.
They all relay via my main servers and the "bad" one's were not listed in the
opendkim trustedhosts file on those servers, and so no DKIM signature was added upon
relay for those servers.
Emmett
