[RCU] Misconfigured Mailing List DNS

roundcube at ptld.com roundcube at ptld.com
Sun Aug 15 18:48:00 CEST 2021


> On 08-15-2021 11:12 am, Reindl Harald wrote:

Just wow. Okay, i didn't want to over explain, because i assumed 
everyone here would know what FQND, FCrDNS, PTR's and MX records are. 
Sorry if my lack of over explanation was confusing to read. Let me over 
explain it now and what i meant. Im just surprised at how many people 
who's gig is email get so much of this wrong.


>> I got an email from this mailing list...
>> Client IP = 95.128.36.21 -> mx.kolabsys.com
> 
> this is a PTR

Yes, a PTR record is a mapping from an IP to a FQDN. So when you lookup 
host for 95.128.36.21 you get mx.kolabsys.com


>> Client PTR = mx.kolabsys.com -> 95.128.36.22
>>                               -> 95.128.36.21
>>                               -> 212.103.80.151
>>                               -> 95.128.36.23
>>                               -> 212.103.80.150
>>                               -> 212.103.80.152
> 
> this is not a PTR

This is where you got confused. I did not say those IP's where PTR's. I 
said the client PTR (mapping of 95.128.36.21) = (see the = above) 
mx.kolabsys.com which is a FQDN, and that FQDN maps back to -> those 
IP's. Now IMO you should not share multiple IP's for the same PTR 
record. Each IP should have its *OWN* PTR unique identifier AKA FQDN.


>> Kind of okay there, at least it maps back, however i have never seen 
>> PTR sharing the same domain like that. Not sure that won't have 
>> strange side effects. But then that client gave a HELO of...
> 
> you don't have the slightest idea what you are talking about when you
> even don't know what a PTR or a cloud is

What the heck does cloud have to do with DNS or PTR records. Don't throw 
around buzz words in an attempt to sound smart. Cloud isn't even a 
thing, its a loose concept which can mean different things, its just a 
marketing word to sell services. "Cloud servers" are just VPS servers. 
Email nor DNS cares or even knows the difference between a "cloud 
server" or a dedicated server. Its just a server reachable by an IP.


> [harry at srv-rhsoft:~]$ dig MX lists.roundcube.net

Now your last dig brings up something else wrong with the DNS. You can 
see they did their mx "round robin" kind of correctly for kolabsys.com, 
listing multiple mx records. But then they have two IP's listed for each 
mx record. Totally unnecessary as that is what the multiple mx records 
already covers. If they wanted 6 servers for receiving email they should 
just make 6 mx records, not some hybrid of three "round robin" mx 
records mixed with two "round robin" IP's. It serves no purpose. There 
is nothing gained by listing multiple IP's to a single mx record as 
clients are just going to pick one of those IP's at random to try same 
as they just picked one of those three evenly weighted mx records 
randomly.

Then for the lists.roundcube.net mx records they have just one record, 
and that one record then has six evenly weighted IP's which clients are 
just going to pick one at random. Again they should have just made six 
mx records so each server is uniquely identifiable. This was how mx 
record were designed to be used, this is why they have weighted numbers 
attached to them. They aren't even being consistent in their 
methodology. One mx system is a hybrid 3 times 2 "round robin" and the 
other mx system is a 1 times 6 "round robin". There is no limitation on 
giving every server its *OWN* FQDN and having uniquely valid FCrDNS for 
each server.


The way they set it up IMO is not good. Just for logging reasons alone 
you would want each server to have its own FQDN / FCrDNS so when you get 
a message that something happened on server mx.kolabsys.com you know 
which server it is. Not having to guess if it was 95.128.36.22, 
95.128.36.21, 212.103.80.151, 95.128.36.23, 212.103.80.150 or 
212.103.80.152. They are not saving anything by sharing the same PTR.

But none of that has anything to do with the problem that i wrote this 
email about in the first place. They are using a HELO FQDN that does NOT 
map back to the server using it. Maybe if the DNS followed a more clean 
methodology, every server having its own unique FCrDNS with the HELO 
matching PTR then maybe the confusion of allowing an invalid HELO FQDN 
wouldn't have happened. As it sits now they might as well have made the 
HELO be gmail-smtp-in.l.google.com as it would have the same result.


So before you come across all aggressive telling someone "you don't have 
the slightest idea what you are talking about when you even don't know 
what a PTR or a cloud is" make sure at the very least YOU know what the 
heck you are talking about.


More information about the users mailing list