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@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.
_______________________________________________
Roundcube Users mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/users

Reply via email to