##- Please type your reply above this line -## You are registered as a CC on this support request (15233). Reply to this email to add a comment to the request.
*Rachel* (NeverBounce) Mar 28, 3:39 PM EDT You are very welcome. And that is true. Please let us know if we can help with anything else, we certainly are most happy to do so. All the best, Rachel *Viktor Szépe* Mar 28, 3:38 PM EDT Than you Rachel. Sometimes standards and reality part ways. Idézem/Quoting "Rachel (NeverBounce)" <supp...@neverbounce.com>: *Rachel* (NeverBounce) Mar 28, 3:33 PM EDT Hi Viktor, Thank you for the patience as our team reviewed this for you. They have provided the following information which you will find helpful: In our experience working with email verification, we have found that the emails with no MX records are often spam traps. There is a bit of debate on how this should be handled best, but we opt to listen to the MX records. Please let us know if we can assist any further. We are happy to help! All the best, Rachel *Viktor Szépe* Mar 28, 10:58 AM EDT I do understand that a MX-less domain is declared a non-mailing domain in *modern age* but the mentioned standard still applies! Idézem/Quoting "Rachel (NeverBounce)" <supp...@neverbounce.com>: *Rachel* (NeverBounce) Mar 28, 10:54 AM EDT Hi Ralph, Thank you for the kind words! We are certainly always happy to help our customers and once we have a bit more information, I will quickly follow up. Have a wonderful day! All the best, Rachel *Ralph Corderoy* Mar 27, 6:32 PM EDT Hi Rachel, Thanks for your responses, and trying to keep the mailing list in the loop. I appreciate it takes time on your side and we're in no hurry. I'm more than happy to just be in contact with someone that knows how to have the issue examined, whatever the outcome. I've dealt with quite a few companies over the years in trying to report possible problems and NeverBounce is doing well in comparison with many of them! -- Cheers, Ralph. *Rachel* (NeverBounce) Mar 27, 5:05 PM EDT Hello, Thank you for your patience as our team has requested some additional time to review this matter. Once the team has followed up, I will be sure to send any and all information obtained your way. I do apologize if this ticketing system does not CC the appropriate team members (this has happened in the past). I have included them in this send. Thank you again and have a wonderful day! All the best, Rachel Attachment(s) Screen Shot 2019-03-27 at 2.05.09 PM.png <https://neverbounce.zendesk.com/attachments/token/PBgpCAFiLGFxU29YzoWTlqa76/?name=Screen+Shot+2019-03-27+at+2.05.09+PM.png> *Rachel* (NeverBounce) Mar 27, 9:26 AM EDT Request #15234 <https://neverbounce.zendesk.com/hc/requests/15234> "Fwd: [S-mailx] Fwd: false positive" was closed and merged into this request. Last comment in request #15234 <https://neverbounce.zendesk.com/hc/requests/15234>: Hello! Please forward it to your engineers. Maybe tell them to reread RFC 5321. Thank you. ----- Forwarded message from Ralph Corderoy ra...@inputplus.co.uk ----- Date: Wed, 27 Mar 2019 10:24:08 +0000 From: Ralph Corderoy ra...@inputplus.co.uk Subject: Re: [S-mailx] Fwd: false positive To: Rachel supp...@neverbounce.com Cc: SZÉPE Viktor vik...@szepe.net, s-mailx@lists.sdaoden.eu Hi Rachel, There's discussion on the s-mailx@lists.sdaoden.eu mailing list about a support reply from neverbounce.com. (Please keep s-mailx@lists.sdaoden.eu CC'd.) From: "Rachel (NeverBounce)" supp...@neverbounce.com To: Viktor Szépe vik...@szepe.net 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 s-mailx@lists.sdaoden.eu, 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. ----- End forwarded message ----- SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md ~~~ ügyelet/hotline: +36-20-4242498 s...@szepe.net skype: szepe.viktor Budapest, III. kerület *Ralph Corderoy* Mar 27, 6:26 AM EDT Hi Rachel, There's discussion on the s-mailx@lists.sdaoden.eu mailing list about a support reply from neverbounce.com. (Please keep s-mailx@lists.sdaoden.eu CC'd.) > > > From: "Rachel (NeverBounce)" <supp...@neverbounce.com> > > > To: Viktor Szépe <vik...@szepe.net> > > > 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 s-mailx@lists.sdaoden.eu, 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. This email is a service from NeverBounce. [WV6RY2-V9E8]