Re: Today is a good day to DANE!
On Thu, Aug 19, 2021 at 01:11:37AM -0400, Viktor Dukhovni wrote: > On Thu, Aug 19, 2021 at 02:44:44PM +1000, raf wrote: > > > I just saw Viktor's reply about mx[1-4].smtp.goog, > > and it looks like those domains are no longer signed: > > > > > host -t ds mx1.smtp.goog > > mx1.smtp.goog has no DS record > > > host -t ds mx2.smtp.goog > > mx2.smtp.goog has no DS record > > > host -t ds mx3.smtp.goog > > mx3.smtp.goog has no DS record > > > host -t ds mx4.smtp.goog > > mx4.smtp.goog has no DS record > > That's not correct, those are not zone cuts, the signed zone is > "smtp.goog". To see whether a name is signed you ask for a > DNSSEC validated response from a validating resolver: > > $ dig +dnssec +nosplit +nocl +nottl -t a mx1.smtp.goog. > > -- > Viktor. Thanks. What a silly mistake. I should have done: host -t ds smtp.goog cheers, raf
Re: Logging - Handling of Aliases
On Wed, Aug 18, 2021 at 12:07:07PM -0700, Ron Garret wrote: > On Aug 18, 2021, at 11:55 AM, Viktor Dukhovni > wrote: > > > If you want different processing for inbound and outbound mail, > > use separate Postfix instances configured appropriately to the > > task at hand. > > There is a useful distinction to be made between mail that is injected > into the system by an authorized user and mail that is not. I think > of the former as “outbound” even though that is not technically > correct. And it is possible to handle these two kinds of messages > differently by using a milter (there may be other ways as well, but I > know for sure that a milter can do it). This may not be a smart thing > to do, but it is possible. > > rg I think a common way to distinguish between authenticated "inside" senders and unauthenticated "outside" senders, just based on tutorials I've seen online, is with the use of values like these in the various smtpd_*_restrictions settings: permit_mynetworks permit_sasl_authenticated reject_unauth_destination permit_auth_destination They can be used to control which mails are subjected to policy checks like greylisting or SPF checking. And with all the actions available in access(5) databases that can also be included in the restrictions settings (e.g. check_recipient_access or check_sender_access), you can do (or avoid doing) all sorts of things (e.g. FILTER). And with multiple instances/services setup in master.cf, you can probably do anything you can imagine. I take it that milters must work too, but they sound like much more effort. You need to write a whole other program (securely). But I guess if you really like the milter API, then you like it. :-) I've only used other people's milters (OpenDKIM and OpenDMARC), and only to filter the mail content itself. cheers, raf
Re: Logging - Handling of Aliases
raf: > I take it that milters must work too, but they sound > like much more effort. You need to write a whole other > program (securely). No. You write little functions in a common language (python, perl, java, rust, haskell?, php, C) and leave the rest up to a code library. Wietse
why this DMARC pass by google?
Experts, I met a strange issue about DMARC validation at google groups. Since it requires some pics to make a more clear statement, I wrote the question on blog: https://blog.hoxblue.com/why-this-dmarc-pass-by-google/ Can you help to explain my question? Thank you very much. regards. Ken
Re: Logging - Handling of Aliases
On Thu, Aug 19, 2021 at 09:27:10AM -0400, Wietse Venema wrote: > raf: > > I take it that milters must work too, but they sound > > like much more effort. You need to write a whole other > > program (securely). > > No. You write little functions in a common language (python, perl, > java, rust, haskell?, php, C) and leave the rest up to a code > library. > > Wietse Thanks. cheers, raf
Re: why this DMARC pass by google?
On Thu, Aug 19, 2021 at 10:49:05PM +, k...@linuxdeveloper.xyz wrote: > Experts, > > I met a strange issue about DMARC validation at google groups. > Since it requires some pics to make a more clear statement, I wrote the > question on blog: > https://blog.hoxblue.com/why-this-dmarc-pass-by-google/ > > Can you help to explain my question? Thank you very much. > > regards. > Ken Hi Ken, Warning: This is just a theory, but it's the only reasonable one I could think of. Google is aware of the fragility of SPF/DKIM/DMARC when it comes to mailing lists, which is why they use ARC: Authenticated Received Chain (ARC) Protocol https://tools.ietf.org/html/rfc8617 (Experimental) ARC is a way for remailers to add an authenticated chain of custody to an email, where they check SPF/DKIM/DMARC when they receive the original email, and then attest that each check passed or failed at that time, and then they provide a DKIM-like signature to prove that it was really them that made the attestation. If you look in the headers of a googlemail email, you'll see these headers: ARC-Seal ARC-Message-Signature ARC-Authentication-Results There can be a set of these three headers for every ARC-enabled remailer along the path. The googlegroups email that I receive tends to have two sets, both added as the mail passes between various google servers. The ARC-Authentication-Results header contains the SPF/DKIM/DMARC check results for the original mail, and this gets copied up through the chain. The other two headers in each set enable the receiver to check the authenticity of its contents. Gmail is probably checking the ARC chain and seeing that DMARC was valid when googlegroups received the original email, and that's what gmail is reporting to you as a DMARC pass. I'm not sure how much ARC is used. From my tiny personal sample set, it's almost all Google and Microsoft. So maybe that's a lot. And who checks it? It's hard to tell. If gmail checks ARC but doesn't mention it by name, perhaps other mail providers are doing that too. There is a milter for it called OpenARC, written by the same group that wrote OpenDKIM and OpenDMARC, but it seems to have been abandoned two years ago when it was still in beta stage. And it doesn't get a mention in the postfix setup tutorials that I've come across. I can find people asking how to set it up, but not so much in the way of satisfactory answers. Without something like OpenARC, OpenDMARC is going to produce lots of false positives because it doesn't know to defer to ARC checking in the presence of ARC headers. cheers, raf
Re: why this DMARC pass by google?
Hi Raf, Thanks a lot for your explaining. That really help me understand the forwarding. I didn't hear ARC before, will check it later. Thank you. August 20, 2021 10:42 AM, "raf" wrote: > On Thu, Aug 19, 2021 at 10:49:05PM +, k...@linuxdeveloper.xyz wrote: > >> Experts, >> >> I met a strange issue about DMARC validation at google groups. >> Since it requires some pics to make a more clear statement, I wrote the >> question on blog: >> https://blog.hoxblue.com/why-this-dmarc-pass-by-google >> >> Can you help to explain my question? Thank you very much. >> >> regards. >> Ken > > Hi Ken, > > Warning: This is just a theory, but it's the only > reasonable one I could think of. > > Google is aware of the fragility of SPF/DKIM/DMARC when > it comes to mailing lists, which is why they use ARC: > > Authenticated Received Chain (ARC) Protocol > https://tools.ietf.org/html/rfc8617 (Experimental) > > ARC is a way for remailers to add an authenticated > chain of custody to an email, where they check > SPF/DKIM/DMARC when they receive the original email, > and then attest that each check passed or failed at > that time, and then they provide a DKIM-like signature > to prove that it was really them that made the > attestation. > > If you look in the headers of a googlemail email, > you'll see these headers: > > ARC-Seal > ARC-Message-Signature > ARC-Authentication-Results > > There can be a set of these three headers for every > ARC-enabled remailer along the path. The googlegroups > email that I receive tends to have two sets, both added > as the mail passes between various google servers. > > The ARC-Authentication-Results header contains the > SPF/DKIM/DMARC check results for the original mail, and > this gets copied up through the chain. The other two > headers in each set enable the receiver to check the > authenticity of its contents. > > Gmail is probably checking the ARC chain and seeing > that DMARC was valid when googlegroups received the > original email, and that's what gmail is reporting to > you as a DMARC pass. > > I'm not sure how much ARC is used. From my tiny > personal sample set, it's almost all Google and > Microsoft. So maybe that's a lot. And who checks it? > It's hard to tell. If gmail checks ARC but doesn't > mention it by name, perhaps other mail providers are > doing that too. > > There is a milter for it called OpenARC, written by the > same group that wrote OpenDKIM and OpenDMARC, but it > seems to have been abandoned two years ago when it was > still in beta stage. And it doesn't get a mention in > the postfix setup tutorials that I've come across. > I can find people asking how to set it up, but not > so much in the way of satisfactory answers. > > Without something like OpenARC, OpenDMARC is going to > produce lots of false positives because it doesn't know > to defer to ARC checking in the presence of ARC headers. > > cheers, > raf
