Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
Am 25.05.23 um 07:33 schrieb Slavko via mailop: I am confused now as in RFC 7505 sect. 4.2 one can read: Null MX is primarily intended for domains that do not send or receive any mail... And: ...mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. I understand that RFC as: nullMX's primary purpose is about not receiving, but as side effect it can result as not sending too. Is my understanding wrong? Technically, null MX and SPF "-all" are two different things, as has been pointed out. SPF "-all" is clear-cut, and you'd be absolutely correct in refusing to accept such mail. However, null MX is a different beast. Technically it only states that a domain does not receive mail. But when you look at common use cases and exception situations such as NDNs, domains with null MX can be regarded as being not fully functional when used in RFC5321.MailFrom, as they will not receive and process technical feedback about deliverability. In my experince, this is a significant factor in assessing whether you want to receive mails from such domains. RFC5322.From is a somewhat different matter, especially when null-MX domains are used in mails which are clearly not intended to be replied to. For bulk mail this is fairly common, although I would vastly prefer if such mails had a working RFC5322.From address for handling replies from confused recipients (a recipient who has not subscribed to some mailing list should be able to contact the sender and demand removal of his address without investing lots of sleuthing work to find out who was responsible for the e-mail). So this can be regarded as a sign that you would prefer to refuse such mail, but arguably a much weaker one, and one that more likely would cause false positives. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
Dňa 24. mája 2023 22:41:01 UTC používateľ Graeme Fowler via mailop napísal: >[moderator note] > >SPF asserts senders (by definition) >NullMX asserts receivers (also by definition) > >Interpretation aside, the fact they are (mis?)understood to be the same thing >is a clear conflation. It may be language based, it may not, but please stop >splitting this specific hair. I am confused now as in RFC 7505 sect. 4.2 one can read: Null MX is primarily intended for domains that do not send or receive any mail... And: ...mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. I understand that RFC as: nullMX's primary purpose is about not receiving, but as side effect it can result as not sending too. Is my understanding wrong? Of course, the sending is affected only if receiver checks return-path, but that is the same with SPF as it is usefull only if SPF is checked... regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
[moderator note] SPF asserts senders (by definition) NullMX asserts receivers (also by definition) Interpretation aside, the fact they are (mis?)understood to be the same thing is a clear conflation. It may be language based, it may not, but please stop splitting this specific hair. Thanks Graeme ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
It appears that Benny Pedersen via mailop said: >test it please, do you see spf rejects or nullmx rejects ? nullmx rejects >sendmail -f ab...@example.org -bv ab...@example.org Well, yeah, you're faking an example.org sending address. Don't Do That. As Laura pointed out, and you just agreed, it is quite normal to have mail domains that accept mail but don't send, so they have SPF -all and a normal MX. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] verifier.port25.com
Alessandro Vesely via mailop wrote on 2023-05-24 18:37: Considering just DKIM tests, this one is the only tester which explicitly and clearly recognizes ed25519 signatures. For the rest, EmailAudit reported a pass, but then said "DKIM key size is 0 bits. More senders are starting to use 2048 bits." The following test also supports ed25519: https://wander.science/projects/email/dkimtest/ It tests DKIM signatures and domain alignment, nothing else. Regards, Matt ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
John Levine via mailop skrev den 2023-05-24 19:50: same thing I checked with the guy who wrote the Null MX RFC and he is quite sure they're not the same thing. xpoint@tux ~ $ dig example.org txt ;; ANSWER SECTION: example.org.86400 IN TXT "6r4wtj10lt2hw0zhyhk7cgzzffhjp7fl" example.org.86400 IN TXT "v=spf1 -all" xpoint@tux ~ $ dig example.org mx ;; ANSWER SECTION: example.org.86400 IN MX 0 . test it please, do you see spf rejects or nullmx rejects ? sendmail -f ab...@example.org -bv ab...@example.org check your logs :) in my test example.org does not enforce spf rejects ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
It appears that Benny Pedersen via mailop said: >John Levine via mailop skrev den 2023-05-24 01:58: > >>> domains with this spf would possible know that spf is more weak then >>> then rfc 7505 (nullMX) ? >> >> No, not at all. >> >> SPF -all says a domain doesn't send mail. > >+1 > >if recipient check sender domain, its imho same thing > >if recipent do not check sender domain its a diffrent > >i just mention this since not all checks spf and enforce it, while if >nullmx is used its enforced > >> Null MX says a domain doesn't receive mail. > >same thing I checked with the guy who wrote the Null MX RFC and he is quite sure they're not the same thing. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] verifier.port25.com
On Tue 23/May/2023 22:27:22 +0200 Tobias Fiebig via mailop wrote: On Tue, 2023-05-23 at 13:31 -0500, Blake Hudson via mailop wrote: Anyone have [...] alternative tools for testing DKIM, SPF, and similar in one go? Lemme throw email-security-scans.org into the list of tools for this. ;-) Considering just DKIM tests, this one is the only tester which explicitly and clearly recognizes ed25519 signatures. For the rest, EmailAudit reported a pass, but then said "DKIM key size is 0 bits. More senders are starting to use 2048 bits." Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
Laura Atkins via mailop skrev den 2023-05-24 10:03: nullMX means the domain doesn’t receive mail. v=spf1 -all means the domain doesn’t send mail. When I’m working with clients who are setting up domains for not-email I recommend both as they address the issue from different directions. end results should be the same, i can argue that nullmx and SPF is doing different things, but end outcome would imho be same result, more or less It’s also perfectly legit for a domain to receive email while never sending email. correct I have domains set up to receive client mail, for instance. They never send mail, they’re collection addresses. +1 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] verifier.port25.com
As a postscript to this, I was formerly employed by SparkPost and so still have some contacts with people associated with Port25. When this thread kicked off yesterday, I noticed that the DNS for verifier.port25.com was a bit wonky; specifically, the MX record for that name resolved to "verifier." I reached out to my contacts, and they corrected the DNS. I don't know if that fixed the issue that led to the creation of this thread, but verifier.port25.com might not be down after all. On Tue, May 23, 2023 at 6:31 PM Andreas Schamanek via mailop < mailop@mailop.org> wrote: > > On Tue, 23 May 2023, at 16:10, Jim Popovitch via mailop wrote: > > > Lots of good responses for alternatives to verifier.port25.com, but > > do any of them support aliased feedback address whereby you could > > send an email to check-auth-lhs=domain@verifier.port25.com and > > the response would be returned to the aliased address not the sender? > > I feel like it took me much longer than it should to realize why I > would want such a feature. Now that I got it, thank you very much, > this is really helpful! > > -- > -- Andreas > > :-) > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Yahoo FBL down?
Marcel commented that they had an issue develop late last Friday (the 19th) and that they are working on it. Mike From: mailop On Behalf Of Alex Irimia via mailop Sent: Wednesday, May 24, 2023 7:38 AM To: mailop Subject: [mailop] Yahoo FBL down? We see a considerable drop in spam complaints at Yahoo since May 18-ish. Did anyone else notice this? -- Regards, Alex Irimia [cid:image001.png@01D79A9F.36D07E30] Postmastery Email Infrastructure, Analytics, DMARC and Deliverability Amsterdam, NL/Paris, FR ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Yahoo FBL down?
We see a considerable drop in spam complaints at Yahoo since May 18-ish. Did anyone else notice this? -- Regards, Alex Irimia Postmastery *Email Infrastructure, Analytics, DMARC and Deliverability* Amsterdam, NL/Paris, FR ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?
> On 23 May 2023, at 21:09, Benny Pedersen via mailop wrote: > > Todd Herr via mailop skrev den 2023-05-23 20:54: > >>> Indeed, an email will only be rejected if it has DMARC setup as >>> reject. >> There should be one exception to the rule of waiting till after DATA >> to check for a DMARC policy, and that's in the case of the following >> SPF record: >>> "v=spf1 -all" >> It seems wholly appropriate to reject at MAIL FROM if the RFC5321.From >> domain publishes an SPF policy that says "This domain is not used to >> send mail, ever." > > domains with this spf would possible know that spf is more weak then then rfc > 7505 (nullMX) ? nullMX means the domain doesn’t receive mail. v=spf1 -all means the domain doesn’t send mail. When I’m working with clients who are setting up domains for not-email I recommend both as they address the issue from different directions. It’s also perfectly legit for a domain to receive email while never sending email. I have domains set up to receive client mail, for instance. They never send mail, they’re collection addresses. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop