[SOLVED] Setting correct SMTP HELO host, domain name, PTR records for e-mail server

[royceb (Royce)]

@Andy_Wismer

Sure a PTR of a Mailserver should match the helo, but I would make sure the helo is exactly mail.domain.com, and nothing else! If needed, I’d adapt the helo, but NOT the PTR!

Thank you for clarifying for me. For starters, I do tend to follow what you describe above planning names, DNS, and such using that networking spreadsheet you shared with me as a template (thank you!).

Help clarify if I am wrong but from my understanding of a PTR record in this case is used to verify a 1 to 1 relationship that an ip address of w.x.y.z maps to a given record like demo.example.com. The PTR record is something set by those who own the IP (usually ISP) address of w.x.y.z from which we want our nethserver email to be sending from. I think what you are saying is that the expectation of the PTR records for email servers should be close to or if not exactly mail.example.com. It is also true that is much easier to modify the HELO record on Nethserver.

I supposed my clarified point for @michelandre would then be that these two records must match (your HELO and PTR records) and that the default HELO record when deploying NS comes from it’s FDQN host name.

[michelandre (Michel-André)]

Hi Andy,

@Andy_Wismer

but I would make sure the helo is exactly mail.domain.com, and nothing else! If needed, I’d adapt the helo, but NOT the PTR!

I tried to change the myhelo A record to point to mail.domain.com but it is refused as it requests an IP address or @.

Is that the way to do it or there is another way ?

Michel-André

[Andy_Wismer (André Wismer)]

@royceb

Hi Royce

@royceb

The PTR record is something set by those who own the IP (usually ISP)

This is only true for dynamic addresses, and for static addresses where the user has not yet required a PTR record. And these PTR Hostnames are all on the dnsbl Blacklist, by the providers using these IPs for their clients. As soon as a client requests a PTR, the name is usually taken of the dnsbl list - the provider knows you want to run mail there…

@royceb

from my understanding of a PTR record in this case is used to verify a 1 to 1 relationship that an ip address of w.x.y.z maps to a given record like demo.example.com.

Almost correct, but not quite. Mailservers check this, the reasoning is if the sender’s mail clains to be coming from john.doe@doe-home.org , and the sending mailserver resolves to a same Domainname like server.doe-home.org , then the chances are very high it’s legit mail, and not spam!

Now, if helo answer and PTR correspond, it’s almost 100% legit. Sure, something could be spoofed, but PTR is hard to spoof.

I do have some clients servers who do mail, and are NOT called mail.domain.ch or whatever, but a “normal” servername. In such a case, I’ll have the real FQDN as A record, but also mail.domain.ch as A record. PTR would be mail.domain.ch, and the same goes for the helo. The real FQDN could be - for the internet a CNAME of mail.domain.ch…

Mail is the one DNS thing that really needs special attention, and I go by the rule that it should be mail.whatever.com, as it concerns mail, not generic server access. This usually implies setting the helo and PTR and at least one “A” Record accordingly.

Here is a swiss example…

Green (green.ch) is a medium sized swiss provider.
Their mailserver is called: mail.green.ch.

Here I’m quering google the forwards and reverse lookups:

And here the telnet query to port 25…

As you can see, any way you look at it, this mail server has really optimal A, PTR and helo!
All answer to the same name.

A lot of larger providers, or Google and other large companies usually have a mail-cluster, and each node has mx-name or something. This takes a little more effort, but Gmail works (usually well!)…

My 2 cents
Andy

[Andy_Wismer (André Wismer)]

@michelandre

Hi

I would keep the mail.domain.com as A record, and if possible change the helo to reflect this!
The PTR already says mail.domain.com…

An A record MUST point to an IP.
Only a CNAME can point to an A Address.
And mail MUST use an A record!

If it’s not possible to change the servers helo, you’ld need to use myhelo as A record with the right IP.

My 2 cents
Andy

[michelandre (Michel-André)]

Hi Andy,

At the ISP, the PTR record is set to main.toto.org
There is an A records for toto.org pointing at the right IP.
There is an A records for mail.toto.org pointing at the right IP.
There is an A records for myhelo pointing at the right IP.

@Andy_Wismer

If it’s not possible to change the servers helo,

I have access to the server console, how can I change the server helo record ?
If I change it on the server, then I have to delete the myhelo A record ?

Michel-André

[Andy_Wismer (André Wismer)]

@michelandre

To change the helo, see the top of this topic, MrMarkuz posted it:

Customizable Postfix SMTP banner host

The default SMTPD banner in Postfix is $hostname ESMTP $mail_name, which normally translates to something like <your_host_name> ESMTP Postfix. If the internal server name does not match the public DNS, the SMTP shows a hostname which may be incorrect, and make some email services reject messages or mark them as SPAM. It would be useful to have a way to override the default Postfix smtpd_banner configuration option. This can be done as easy as including a new template snippet named /etc/e-smit…

The myhelo A DNS entry can be kept or deleted, as mail does not use it anymore…
But maybe the name is used for other things as well… (No need to delete, you can if you want…).

Hope this helps
Andy

[michelandre (Michel-André)]

@Andy_Wismer,

How about changing the HeloHost with a setprop ?

# config show postfix
postfix=service
...
HeloHost=myhelo.toto.org
...
#

Michel-André

[royceb (Royce)]

@Andy_Wismer

As you can see, any way you look at it, this mail server has really optimal A, PTR and helo!
All answer to the same name.

I think you and I are functionally talking about the same process except with an attention to naming convention and norms; mail.example.com vs random-name.example.com for helo/ptr setups. Do you have any resources I could study up on for best practices regrading these naming conventions?

@Andy_Wismer

Not sure if that would work, but it’s worth a try.
It’s also possible to use cockpit, apparently…

Custom HELO can be set via Cockpit under the Relay section.

[Andy_Wismer (André Wismer)]

@michelandre

Not sure if that would work, but it’s worth a try.
It’s also possible to use cockpit, apparently…

[michelandre (Michel-André)]

@Andy_Wismer

Source of the mail sent to my friend Frederic:

ORIGINAL:
…
Received: from myhelo.toto.org
…

After changing it with a setprop:
…
Received: from mail.toto.org
…

Maybe a simple solution ?

But I have to wait for tomorrow as I already used my 3 tests at https://www.mail-tester.com.

Michel-André

[Andy_Wismer (André Wismer)]

Patience again…

But looks good!

[michelandre (Michel-André)]

Thank you @Andy_Wismer, @royceb and all other for your great replies.

This forum is really the best one…

Michel-André

[Andy_Wismer (André Wismer)]

@michelandre

You’ve also got to admit, looking at a mail header and seeing mail.domain.something does look much better (and more serious) than myhelo or say “testserver”…

And if you want three more tests, I can give you remote access from here…

[michelandre (Michel-André)]

Salut @royceb

@royceb

Custom HELO can be set via Cockpit under the Relay section.

I do not user Relay, maybe that’s why it’s diplaying nothing under it.

Michel-André

[michelandre (Michel-André)]

Hi all,

My sincere thanks to @Andy_Wismer.

The most simple working solution is to use a setprop command.

1 → At the ISP (the real owner of the IP address):

• The PTR record is set to mail.DomainName.

2 → At the domain registrar for the DNS records:

• There is an A records for DomainName pointing at the IP.
• There is an A records for mail.DomainName pointing at the IP.
• There is an A records for myhelo pointing at the IP.

3 → At the NethServer console:

The default HeloHost:

# config show postfix
postfix=service
...
HeloHost=myhelo.DomainName
...
#

Using setprop:

# config setprop postfix HeloHost mail.DomainName
#

# signal-event nethserver-mail-server-update
#

The new HeloHost property:

# config show postfix
postfix=service
...
HeloHost=mail.DomainName
...
#

4 → https://www.mail-tester.com/:
The orange check mark is due to the fact that I didn’t include an unsubscribe link in the email I sent for the test.

●●● Maybe ask the developers to change myhelo.DomainName to mail.DomainName because it is recommended to always use mail and never myhelo as @Andy_Wismer explained.

Michel-André

P.S. The next problem will be with multi-domains, but this is another story by itself…

[royceb (Royce)]

@michelandre

I do not user Relay , maybe that’s why it’s diplaying nothing under it.

@michelandre

●●● Maybe ask the developers to change myhelo.DomainName to mail.DomainName because it is recommended to always use mail and never myhelo as @Andy_Wismer explained.

This setting affects your LOCAL HELO settings without you having to create a custom SMTP banner or change the host name of the Nethsrever install. I was confused at first being that it was in the Relay section but this was incorrect on my part. The picture above that has the WHAT.the.fudge HELO response after I changed the Custom HELO message to WHAT.the.fudge and would be the solution you were looking for without needing the custom SMTP banner changes that Andy suggested.

[michelandre (Michel-André)]

Hi all,

I am now writing a document on how to setup DNS records for a mail server.
This document has to be 100% correct and cointains no errors.

From: ClouDNS: What is an MX Record?

FAQ

Question: Do I need an “A” record for my mail server alongside with my domain’s MX records?

Answer: If the mail server is part of the same domain namespace (lies in the zone), then an “A” record is required.

Everything is working correctly and my DNS records are now:

I have a little doubt about the imap, smtp and pop DNS records.

QUESTIONS:

● Is this the right way to describe these imap, smtp and pop records with CNAMEs ?

As stated in the above link:
“…alongside with my domain’s MX records”…,

● Do I have to add an MX record for mail even if it already has an A record or the addition of a MX mail record might fool the DNS request from the mail receiving server ?

All comments or suggestions highly appreciated.

Michel-André

[Andy_Wismer (André Wismer)]

@michelandre

Salut Michel-André

Actually, strictly said, the IMAP, SMTP and POP entries are not really necessary.
SMTP “looks” nice, but’ that’s about it.

-> However, for ALL users of mobile phones, and most Mail Clients, having those three entries as CNAME or A records just makes it easier to add in an account, as most mobiles (Android, iOS), and Desktop Mail clients probes for those names… No idea about obsolute stuff like Blackberries or MS-Phone.
These do not work when using .local or .lan pseudo domains.

To add a historical note:

Up until around the Millenium / the Dot.com Dot.gone crash, the standards used to be:
Incoming: pop.domain.tld
Outgoing: smtp.domain.tld

IMAP wasn’t still very common, some providers also had
imap.domain.tld

And: Incoming and Outgoing were very often different servers. Servers were a lot less powerful in those days!

A very common, very insecure auth scheme for SMTP was “pop before smtp”…

My 2 cents
Andy

[Andy_Wismer (André Wismer)]

@michelandre

Salut Michel-André

Forgot the last question:

To be correct a mail server MUST always have an “A” record AND a “MX” Record.
In larger environments, these do not have to be within the same domain, but the mail server still needs at least one of each.
The MX tells were to dump mail, and the A record tells where to find that server!

My 2 cents
Andy

[capote (Marko)]

I have a multi-domain server with three different domains including mail

I received 10/10 points for all mail addresses.

My configuration:

Nethserver: srv01.mymaindomain.tld

DNS mymaindomain.tld:

mymaindomain.tld.	86400	IN 	MX	10 mymaindomain.tld.
mymaindomain.tld.	86400	IN	TXT	 v=spf1 a:srv01.mymaindomain.tld mx:mail.mymaindomain.tld ip4:123.456.789.10 ?all
mymaindomain.tld.	86400	IN  A	
mymaindomain.tld.	86400	IN  CAA 0 issue "letsencrypt.org"
*.mymaindomain.tld.	86400	IN 	A	123.45.67.10
_dmarc.mymaindomain.tld.	86400	IN	 TXT	v=DMARC1;p=reject;pct=100;ruf=mailto:abuse@mymaindomain.tld;fo=0:d:s;aspf=r;adkim=r;
default._domainkey.mymaindomain.tld.	1800	IN	TXT	( "v=DKIM1; k=rsa; " "p=MIIBIjANBg…" "Iv..AB" ) ; ----- DKIM key default for mymaindomain.tld
*._tcp.mymaindomain.tld.	3600	IN	 TLSA	3 1 1 ecd585ed2f2d2801da49…
imap.mymaindomain.tld.	86400	IN	 CNAME	mail.mymaindomain.tld.
mail.mymaindomain.tld.	86400	IN	 A	123.45.67.10
mail.mymaindomain.tld.	86400	IN	 CAA	0 issue "letsencrypt.org"
ns-srv01.mymaindomain.tld.	86400	IN	 A	123.45.67.10
pop.mymaindomain.tld.	86400	IN	 CNAME	mail.mymaindomain.tld.
smtp.mymaindomain.tld.	86400	IN	 CNAME	mail.mymaindomain.tld.

DNS myseconddomain.tld:

myseconddomain.tld.	86400	IN	 MX	10 mymaindomain.tld.
myseconddomain.tld.	86400	IN	 TXT v=spf1 a:srv01.mymaindomain.tld mx:mail.mymaindomain.tld ip4:123.456.789.10 ?all
myseconddomain.tld.	86400	IN	 A	123.45.67.10
myseconddomain.tld.	86400	IN 	CAA	0 issue "letsencrypt.org"
*.myseconddomain.tld. 86400	IN 	TXT	v=spf1 a mx mx:srv01.mymaindomain.tld ip4:123.456.789.10 ~all
_dmarc.myseconddomain.tld.	86400	IN	 TXT	v=DMARC1;p=reject;pct=100;ruf=mailto:marko.dargel@gmail.com;fo=0:d:s;aspf=r;adkim=r;
default._domainkey.myseconddomain.tld.	86400	IN	 TXT	( "v=DKIM1; k=rsa; " "p=MIIBIjANBg…" "Iv...AB" ) ; ----- DKIM key default for myseconddomain.tld
*._tcp.myseconddomain.tld.	3600	IN	TLSA	3 1 1 20d315859f86d83c8943…
imap.myseconddomain.tld.	86400	IN  CNAME	mail.myseconddomain.tld.
mail.myseconddomain.tld.	86400	IN  A	    123.45.67.10
pop.myseconddomain.tld.	    86400   IN  CNAME	mail.myseconddomain.tld.
smtp.myseconddomain.tld.	86400	IN	CNAME	mail.myseconddomain.tld.

best regards, Marko