Hi Rachel, There's discussion on the [email protected] mailing list about a support reply from neverbounce.com. (Please keep [email protected] CC'd.)
> > > From: "Rachel (NeverBounce)" <[email protected]> > > > To: Viktor Szépe <[email protected]> > > > Subject: Re: false positive > > > Date: Tue, 26 Mar 2019 19:40:15 +0100 ... > > > We did have the chance to review the email in question, and it > > > appears the domain is not configured properly, which is why the > > > email is being marked as invalid. For delivering [email protected], the DNS entries are $ dig +nocomment @8.8.8.8 lists.sdaoden.eu. ; <<>> DiG 9.13.7 <<>> +nocomment @8.8.8.8 lists.sdaoden.eu. ; (1 server found) ;; global options: +cmd ;lists.sdaoden.eu. IN A lists.sdaoden.eu. 14399 IN CNAME sdaoden.eu. sdaoden.eu. 14399 IN A 217.144.132.164 ;; Query time: 52 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Mar 27 10:12:48 GMT 2019 ;; MSG SIZE rcvd: 75 $ RFC 5321, Simple Mail Transfer Protocol, says https://tools.ietf.org/html/rfc5321#section-5 The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. lists.sdaoden.eu has no MX record, but does have a CNAME for sdaoden.eu and so that should be then treated as the initial name. sdaoden.eu has no MX record. This is also covered in that section of RFC 5321: 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. Thus sdaoden.eu is to be treated as an MX RR record. A lookup on that gives the A record for 217.144.132.164. That IP address is the one to connect to. Perhaps NeverBounce are getting confused with this part: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. So an MX RR's value can't resolve to a CNAME, but the implicit one above doesn't, it gives an A. It's perfectly valid, and explicitly covered above, for the lookup desiring an MX to find a CNAME. Please can you re-appraise NeverBounce's RFC compliance. Thanks. Steffen, don't change you DNS configuration. It's correct and helps flush out problems like this that may be affecting NeverBounce's treatment of other addresses. -- Cheers, Ralph.
