[mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
Hi, we are an ESP (a very small italian alternative to Mailchimp). Today an italian mailvox provider started refusing our emails with this message > 550 5.1.0 sender rejected: domain does not have neither a valid MX or A record The "e.#customerdomain" is a CNAME record that points to app.mailvox.it and app.mailvox.it has both A and MX records. I guess Tiscali is checking only the A and MX records for the sending domain without following the CNAMEs: in many years this is the first time I see something similar and I thought that many services sending email use a CNAME like us as the alternative (zone delegation) is a lot more complex to be setup. I just wrote email to Tiscali postmaster to understand if they will consider this "a bug in the new feature" or a "feature of the new feature", but in the mean time I wanted to share the issue as I think other senders use the same CNAME solution. We use that CNAME host in order to align the SPF authentication of emails sent by our customers but our email are also DKIM aligned, so I could simply use @app.mailvox.it instead of the customer CNAME in the return-path and emails would still pass DMARC via DKIM. Do you know other receivers refusing emails because the sender (smtp mail from) domain is a CNAME? -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
Well, I think I wrote here too early: from further investigation seems like the issue has gone and now those emails are not refused anymore. According to the logs the issue lasted around 5 hours from 28/02/2024 07:00 CET to 28/02/2024 11:40 CET. I had no answer from their postmaster, so I don't know if they simply found the new rule was too aggressive or if it was a test and they will enable the rule in future. Stefano On Thu, 29 Feb 2024 at 10:00, Stefano Bagnara wrote: > Hi, > > we are an ESP (a very small italian alternative to Mailchimp). > > Today an italian mailvox provider started refusing our emails with this > message > > 550 5.1.0 sender rejected: > domain does not have neither a valid MX or A record > > The "e.#customerdomain" is a CNAME record that points to app.mailvox.it > and app.mailvox.it has both A and MX records. > > I guess Tiscali is checking only the A and MX records for the sending > domain without following the CNAMEs: in many years this is the first time I > see something similar and I thought that many services sending email use a > CNAME like us as the alternative (zone delegation) is a lot more complex to > be setup. > > I just wrote email to Tiscali postmaster to understand if they will > consider this "a bug in the new feature" or a "feature of the new feature", > but in the mean time I wanted to share the issue as I think other senders > use the same CNAME solution. > > We use that CNAME host in order to align the SPF authentication of emails > sent by our customers but our email are also DKIM aligned, so I could > simply use @app.mailvox.it instead of the customer CNAME in the > return-path and emails would still pass DMARC via DKIM. > > Do you know other receivers refusing emails because the sender (smtp mail > from) domain is a CNAME? > > -- > Stefano Bagnara > Apache James/jDKIM/jSPF > VOXmail/Mosaico.io/VoidLabs > -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
Stefano Bagnara via mailop skrev den 2024-02-29 11:09: I think I wrote here too early: from further investigation seems like the issue has gone and now those emails are not refused anymore. https://totaluptime.com/kb/cname-and-mx-for-the-same-host-name/ dont use cname for email or even mx and lastly cname breaks dnssec, dont do this, is tlsa not something you care about ? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
On Thu, 29 Feb 2024 at 12:09, Benny Pedersen via mailop wrote: > > I think I wrote here too early: from further investigation seems like > > the issue has gone and now those emails are not refused anymore. > > https://totaluptime.com/kb/cname-and-mx-for-the-same-host-name/ > > dont use cname for email or even mx Why? The page you reported is correct as you cannot have CNAME and MX for the same host, but I don't need CNAME and MX on the same host because the spec cleary say that the domain can be a CNAME and in that case you have to follow the CNAME before looking for the MX records. This is the main reason CNAMEs exists: isn't it? The opposite way, an MX pointing to a CNAME, is invalid according to the SPEC, but that's another thing. If you have RFC pointers about this "dont use cname for email or even mx" I'd be happy to double check this and be corrected. From https://datatracker.ietf.org/doc/html/rfc5321 2.3.5. Domain Names > For example, a domain may refer to an alias (label of a > CNAME RR) or the label of Mail eXchanger records to be used to > deliver mail instead of representing a host name. > [...] > In other words, names that can > be resolved to MX RRs or address (i.e., A or ) RRs (as discussed > in Section 5) are permitted, as are CNAME RRs whose targets can be > resolved, in turn, to MX or address RRs. So, not only they are not prohibited by the spec, but they are explicitly permitted. Do you understand something different from RFC5321? (I'm not a native english speaker, but "as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs" seems pretty straightforward). Of course I could stop using the CNAMEd domain and use my shared domain for all of my customers but this way I'd loose SPF alignment so I refrain from doing that because of some uncompliant receivers and subdomain delegation is not something 99% of my users/customers would be able to do. > and lastly cname breaks dnssec, dont do this, is tlsa not something you > care about ? I only receive bounces to those addresses, TLS is good enough. The real replies are sent to domains not using CNAMEs. Stefano -- Stefano Bagnara Apache James/jDKIM/jSPF VOXmail/Mosaico.io/VoidLabs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
On 2024-02-29, Stefano Bagnara via mailop wrote: > Today an italian mailvox provider started refusing our emails with this > message >> 550 5.1.0 sender rejected: > domain does not have neither a valid MX or A record > > The "e.#customerdomain" is a CNAME record that points to app.mailvox.it and > app.mailvox.it has both A and MX records. This situation is specifically permitted and covered in the DNS and Mail Routing RFCs, but may be less known than other configurations. As the problem went away, perhaps they introduced a bug when doing something else. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"
> and lastly cname breaks dnssec, Err, what? CNAME works fine with DNSSEC. CNAME at zone apex with other RR types can break DNSSEC since CNAME with other RRs at the same label (anywhere) isn’t supposed to work. However, since people want to do it, some folks have come up with solutions that may or may not work with DNSSEC. Regards, -drc signature.asc Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Bounces at cox.net (AUP#CXSNDR)
Many thanks to Cox for a quick and effective response. This issue has now been resolved. Andy On 28/02/2024 14:04, Simplelists - Andy Beverley via mailop wrote: Hi all, Has anyone seen an uptick in bounces in the last day or so to cox.net? We're seeing many (but not all) emails bounce, showing what are described as SPF/DKIM failures (AUP#CXSNDR), but as far as we can tell the emails should authenticate correctly. IP range is 78.143.254.0/24. Is there anyone at Cox that can help? Thanks, Andy ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Support contact for Shaw.ca
From: Hugh E Cruickshank via mailop Sent: February 5, 2024 16:52 > From: Scott Undercofler via mailop Sent: February 1, 2024 17:04 > > > > The servers at shaw are configured to reject non-RFC bare linefeeds. > > Silly me I was looking for bare CRs as the error message advised. I > will now go back and review the code for bare LFs. I am also having > the code reviewed by someone else. > > > Can you elaborate on why you’re sending them as they are not > > allowed. > > If we are sending them we are not doing so intentionally. The code in > question was reviewed and updated for CR/LF pairing many years ago and > has been running fine until now. Hi All: Just a quick post to confirm that we have resolved our issue... The problem was indeed a "bare CR". The code in question had been updated many years ago to ensure the all LFs were replaced by a CR/LF however there was one line of code that applied this same replacement to the body of a message without first checking to see if already contained a CR/LF. If this occurred then we would end up with CR/CR/LF hence the "bare CR" error message. Cleaning up this code has resolved the problem. If there is anyone out there working with OpenEdge and the FreeFrameWork smtpmail.p library just drop me a line and I will pass on my code. I would like to express my great appreciation to all who contributed. Regards, Hugh -- Hugh E Cruickshank, Payroll Guardian, www.PayrollGuardian.com ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
