On 2021-04-28 Adam Thompson wrote:

99.9% likelihood they're trying to send to "technopolis.ca" or "tecnopolis.com", no matter what the agent on the phone is saying. Ask me how i know :-(. -Adam

Yes, that's usually the case... but the dude swore "no h" and not .com and read it char for char to us. But you never know!

I always thought about buying technopolis.ca just to never worry about this again... and... just checked and finally someone else registered it :-( Some French place. Oh well... guess they can receive all my Hilton emails :-)

Thanks Colin for that link. Quite useful.

On 2021-04-28 8:46 a.m., Colin Stanners wrote:

It's putting the horse before the cart to look into blocklists etc before the e-mail domain is correctly configured...

http://vger.kernel.org/cgi-bin/mxverify-cgi?DOMAIN=trevor%40tecnopolis.ca&am... http://vger.kernel.org/cgi-bin/mxverify-cgi?DOMAIN=trevor%40tecnopolis.ca&SUBMIT=Submit+to+VGER.KERNEL.ORG

Not sure who decided MX records were mandatory, and for what reason. There was a time that you supplied MX record(s) if...

1. You needed to specify a different host/domain name for the mail exchanger than the particular host/domain itself, or...

2. You had multiple mail exchangers that could handle mail for a particular host/domain (possibly with different priorities).

In the simple case of a single host handling its own mail, there was no need for an MX record to override the default (the A record was sufficient).

I guess in our increasingly aggressive attempts at fighting spam, we've come to treat all the simple, small domains as suspicious? Or have I missed something here?

(And don't get me started on some of the bogus errors that mxtoolbox.com reports on perfectly valid SOA serial numbers and TTL values!)

But, ranting aside, thanks to Colin for pointing out the two links, which can be quite useful if taken with a grain of salt.

Gilbert

On 2021-04-28 7:51 p.m., Hartmut W Sager wrote:

Yes, thank you Colin from me too for that link!  As for no MX record at all, really, Trevor??

Hartmut W Sager - Tel +1-204-339-8331

On Wed, 28 Apr 2021 at 10:51, Bill Reid <billreid@shaw.ca mailto:billreid@shaw.ca> wrote:

Thanks Colin for that link. Quite useful.

On 2021-04-28 8:46 a.m., Colin Stanners wrote:
 > It's putting the horse before the cart to look into blocklists
etc before the
 > e-mail domain is correctly configured...
 >
 >
 >
http://vger.kernel.org/cgi-bin/mxverify-cgi?DOMAIN=trevor%40tecnopolis.ca&SUBMIT=Submit+to+VGER.KERNEL.ORG

 >
<http://vger.kernel.org/cgi-bin/mxverify-cgi?DOMAIN=trevor%40tecnopolis.ca&SUBMIT=Submit+to+VGER.KERNEL.ORG>

On 2021-04-28 Colin Stanners wrote:

It's putting the horse before the cart to look into blocklists etc before the e-mail domain is correctly configured...

Thanks for the tool links! I had thought about DNS issues. But literally no other host that I know of is having problems with me.

Doing resolver lookup for T=MX domain=``tecnopolis.ca'' Questionable: NO MX DATA: domain=``tecnopolis.ca'' We SIMULATE! Do have at least one MX entry added!

Ya, this is a non-error.

https://serverfault.com/questions/947145/is-an-mx-record-required-on-a-domai...

My box is just my box, it's the only external-facing box, and as such does not require a MX. However, if some pathologically stupid MTA doesn't know the RFC then I guess I'll setup a MX.

https://mxtoolbox.com/emailhealth/tecnopolis.ca/ 7 Problems

Category Host Result

dmarc tecnopolis.ca No DMARC Record found spf tecnopolis.ca No SPF Record found

This tool also sort of aggressive with its warnings. Kind of like SSL-setup tools moan about using invalid hashes, though 1-3% of the hits out there are on old browsers that require them.

I don't have dmarc and spf on purpose. Surely no MTA would that braindead to refuse to *send* to such a server?

dns tecnopolis.ca SOA Serial Number Format is Invalid

Can a dns client even get the SOA serial? How does it do that? Mine is set to a normal int within the expected range. Weird... I'll need to verify my server is actually spitting an invalid value out, once I figure out how mxtoolbox is reading that info and what value it saw.

dns tecnopolis.ca SOA Expire Value out of recommended range

Another non-error. My TTL is 1 week and mxtoolbox thinks it should be min 2 weeks.

So useful tools taken with many grains of salt (as are most), at least it gives me some ideas and I'll implement one by one and then see if Hilton can reach me.

Thanks!

On 2021-04-29 Colin Stanners wrote:

I'm afraid that if I understand the situation correctly, the MXVerify result is not an non-error, it is a real problem, and the likely cause of your issue.

See the Gilbert reply. This doesn't jive with the understanding of these 2 old hands.

That serverfault link is unrelated, you are not sending emails only, this discussion is about your domain receiving email.

Ya, but its answer re: RFC5321 is correct:

2.3.5. Domain Names Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. ===

So per RFC is the receiving domain can either resolve to MX, *or* direct A RR (as my domain did).

Further:

5.1. Locating the Target Host If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. ===

As far as I can tell, 5321 is still in force and not superseded.

I had a valid, empty (non-existent) MX record set. That should be valid.

If you have a different understanding, feel free to RFC-enlighten us!