e.g. I do not accept delivery attempts where IP's in-addr.arpa record does not match the forward lookup of the returned hostname's for this IP AND does not match what the delivering MX claims to be regarding the helo info AND if SPF and/or DKIM matches.
and ... yes, I still have mails successfully delivered ;-) I don't see why the receiver (with a compliant configuration) should weaken the proper configuration because senders do 'weird' things. Always fix at the root cause, don't go for workarounds :-) Ralph ----- Am 31. Mrz 2020 um 11:36 schrieb Jeroen Massar jer...@massar.ch: > On 2020-03-31 10:13, Andreas Fink wrote: >> your reverse DNS is not matching for 157.161.57.26 as it returns >> aleka.scout.ch. >> >> list.scout.ch. is not the same as aleka.scout.ch >> You could do instead >> >> >> list.scout.ch MX 50 aleka.scout.ch >> >> or >> >> list.scout.ch CNAME aleka.scout.ch. > > Please, please, please, for your own sanity: NEVER EVER point an MX to a > CNAME. > > > Sendmail, which some people still use (oh heck my inbound MX's are sendmail), > will mess up the domain that way and nicely replace it. > > Thus a mail to: someth...@lists.scout.ch would be replaced by sendmail with > someth...@aleka.scout.ch, which likely will not end up in the same place, and > will cause other expected. > > > > Also RFC refs why not to do it: > > https://tools.ietf.org/html/rfc1912#section-2.4 > 8<---- > Don't use CNAMEs in combination with RRs which point to other names like MX, > CNAME, PTR and NS. > ... > ----->8 > > > http://tools.ietf.org/html/rfc2181#section-10.3 > > 8<---- > 10.3. MX and NS records > > The domain name used as the value of a NS resource record, or part of the > value > of a MX resource record must not be an alias. Not only is the specification > clear on this point, but using an alias in either of these positions neither > works as well as might be hoped, nor well fulfills the ambition that may have > led to this approach. This domain name must have as its value one or more > address records. Currently those will be A records, however in the future > other > record types giving addressing information may be acceptable. It can also have > other RRs, but never a CNAME RR. > ----->8 > > and there are others that detail this problematic setup. > > > > In general actually: avoid CNAMEs where possible; just pre-process your > records. > > Greets, > Jeroen > > > > _______________________________________________ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
