Hi List
Has anyone seen this error message and has a clue about the cause?
... while talking to mxbw.lb.bluewin.chhttp://mxbw.lb.bluewin.ch.:
****@bluewin.ch (reason: 550-5.1.0 MAIL FROM: *****@list.scout.ch Unable to verify MX-Record for domain list.scout.ch)
list.scout.ch. 3600 IN MX 50 list.scout.ch. list.scout.ch. 3600 IN A 157.161.57.26 list.scout.ch. 3600 IN AAAA 2001:4060:dead:beef:200:e2ff:fe70:3b2f list.scout.ch. 3600 IN TXT "v=spf1 a:list.scout.ch a:akela.scout.ch a:list.scoutnet.org -all"
Can't find anything wrong with the MX entry. Actually an MX is not even really necessary.
-Benoît-
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.
On 31 Mar 2020, at 10:05, Benoît Panizzon panizzon@woody.ch wrote:
Hi List
Has anyone seen this error message and has a clue about the cause?
... while talking to mxbw.lb.bluewin.chhttp://mxbw.lb.bluewin.ch.:
****@bluewin.ch (reason: 550-5.1.0 MAIL FROM: *****@list.scout.ch Unable to verify MX-Record for domain list.scout.ch)
list.scout.ch. 3600 IN MX 50 list.scout.ch. list.scout.ch. 3600 IN A 157.161.57.26 list.scout.ch. 3600 IN AAAA 2001:4060:dead:beef:200:e2ff:fe70:3b2f list.scout.ch. 3600 IN TXT "v=spf1 a:list.scout.ch a:akela.scout.ch a:list.scoutnet.org -all"
Can't find anything wrong with the MX entry. Actually an MX is not even really necessary.
-Benoît-
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Andreas
list.scout.ch. is not the same as aleka.scout.ch You could do instead
Yes, but this has been this way for months and has never caused an issue yet. Not even with @bluewin.ch recipients. So did bluewin change something?
Well I'll change the MX. Let's see if this solves this issue.
Strange that IMP has no such issue. We also have MX that point to IP's resolve to other names to do DNS based load balancing.
rrmx.imp.ch has address 157.161.12.5 rrmx.imp.ch has address 157.161.12.4 rrmx.imp.ch has address 157.161.12.6 rrmx.imp.ch has IPv6 address 2001:4060:1:1001::12:4 rrmx.imp.ch has IPv6 address 2001:4060:1:1001::12:5 rrmx.imp.ch has IPv6 address 2001:4060:1:1001::12:6
5.12.161.157.in-addr.arpa domain name pointer obelix.imp.ch.
and so on.
Re-Tested before changing MX.
Error is gone. So I suppose it was a temporary problem.
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: something@lists.scout.ch would be replaced by sendmail with something@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
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 jeroen@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: something@lists.scout.ch would be replaced by sendmail with something@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
-
Andreas Fink -
Benoît Panizzon -
Benoît Panizzon -
Jeroen Massar -
Ralph Krämer