Re: [dmarc-discuss] Email encryption services and DMARC
On Wed, 11 Jul 2018, John R Levine wrote: If you're going to have a third party send mail for you, why can't you just list the third party IP address in your SPF record? Oh, wait, I got it backward. On the outbound mail, you're right, it's the customer's domain so they can add the IP to the SPF. On the inbound mail, the customer sees all the mail coming from the third party. In that case either the third party needs to do some filtering, or the customer needs to peek at the received headers to do some retroactive SPF checking. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Email encryption services and DMARC
It sounds to me like the bounce address is the third-party provider and there's no DKIM signature, so there's nothing for DMARC to align with. Sounds to me like the answer is that if you're going to let a third party send mail for you, it'd be a good idea to enable the third party to put on some DKIM signatures, too. If you're going to have a third party send mail for you, why can't you just list the third party IP address in your SPF record? ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Email encryption services and DMARC
In article <3fe159fb-7de2-b823-2665-bcf985b6c...@rolandturner.com> you write: >Can you show sample/likely envelopes/headers that would cause the >problem? It's not clear from your description why there's a problem. Are >you saying that Cisco is running a service that impersonates author >(5322.From) domains of *_non_*-customers? It sounds to me like the bounce address is the third-party provider and there's no DKIM signature, so there's nothing for DMARC to align with. Sounds to me like the answer is that if you're going to let a third party send mail for you, it'd be a good idea to enable the third party to put on some DKIM signatures, too. R's, John ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
Re: [dmarc-discuss] Email encryption services and DMARC
Ivan, Can you show sample/likely envelopes/headers that would cause the problem? It's not clear from your description why there's a problem. Are you saying that Cisco is running a service that impersonates author (5322.From) domains of *_non_*-customers? - Roland On 11/07/18 19:22, Ivan Kovachev via dmarc-discuss wrote: Hello all, I have a question regarding third-party email encryption services and DMARC. For example, when using Cisco CRES the emails contain the From domain of the sender and the Return-Path is that of the sender so if they authorize Cisco CRES then emails will pass SPF and align with regards to DMARC. Emails contain no DKIM signature. The recipient then replies and again emails go through the CRES servers, the From domain is that of the company that replies, the Return-Path is also that of the company that replies, however, they will also have to authorize Cisco CRES in their SPF in order for DMARC to pass. Again no DKIM. The problem is that there are many other email encryption services out there and if the sender is using any of them then their recipients must also authorize them in their SPF records. This means that if any the sender or recipient is in DMARC reject when replying to such emails their emails will be rejected. Has anyone come across this problem before and what have you done to solved it? Is using subdomains (in DMARC none policy) for this email communication the only way to go for now? ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) -- I felt a great disturbance in the Internet, as if millions of marketers suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened. -- Obi-Spam Kenobi, May 26, 2018 ___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
[dmarc-discuss] Email encryption services and DMARC
Hello all, I have a question regarding third-party email encryption services and DMARC. For example, when using Cisco CRES the emails contain the From domain of the sender and the Return-Path is that of the sender so if they authorize Cisco CRES then emails will pass SPF and align with regards to DMARC. Emails contain no DKIM signature. The recipient then replies and again emails go through the CRES servers, the From domain is that of the company that replies, the Return-Path is also that of the company that replies, however, they will also have to authorize Cisco CRES in their SPF in order for DMARC to pass. Again no DKIM. The problem is that there are many other email encryption services out there and if the sender is using any of them then their recipients must also authorize them in their SPF records. This means that if any the sender or recipient is in DMARC reject when replying to such emails their emails will be rejected. Has anyone come across this problem before and what have you done to solved it? Is using subdomains (in DMARC none policy) for this email communication the only way to go for now?___ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
