[dmarc-discuss] De-munging From:, would this list participate?

Hi all, I rewrote this I-D to add a simple method to de-munge From: header fields upon receiving list messages at subscribers mailboxes: https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ The changes required to the mailing list settings should be easy. Copying the pristine

[dmarc-discuss] Some DMARC adoption data

Hi all, The European Commission has published a comprehensive study on DNS abuse: Study on Domain Name System (DNS) abuse, 2022 https://data.europa.eu/doi/10.2759/616244 Study on Domain Name System (DNS) abuse : technical report. Appendix 1, 2022 https://data.europa.eu/doi/10.2759/473317

Re: [dmarc-discuss] Heterogeneity in handling non-OD inputs among web-based DMARC checking tools

On Wed 29/Dec/2021 18:54:08 +0100 suman wrote: Here is a screenshot of an informal survey I ran today: gov.in isn't listed in http://psddmarc.org/registry.html Thanks Ale --

Re: [dmarc-discuss] opendmarc and response from Mailer Daemon

On Mon 06/Sep/2021 08:14:18 +0200 Kazik K. via dmarc-discuss wrote: I have noticed behavior such as the following: when the message is from Mailer Daemon - when 'MAIL From: <>' is used during the SMTP dialog, and the From: header line is a valid sender's domain, opendmarc marks such messages as

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

On Wed 07/Jul/2021 15:19:35 +0200 Roland Turner via dmarc-discuss wrote: On 7/7/21 4:03 pm, Alessandro Vesely via dmarc-discuss wrote: If I outsourced my mail to google (to stick to the example) what other providers' SPF record do I have to include? Oh yes, John said "to several prov

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

On Wed 07/Jul/2021 07:33:57 +0200 Roland Turner via dmarc-discuss wrote: On 7/7/21 2:57 am, John Levine via dmarc-discuss wrote: It appears that Alessandro Vesely via dmarc-discuss said: I'd suggest that a resolution to this might be to expand the finite limit (I've also had trouble

Re: [dmarc-discuss] Correct counting of DNS lookups for SPF record containing MX mechanism

On Tue 06/Jul/2021 02:55:23 +0200 Roland Turner via dmarc-discuss wrote: On 22/5/21 7:41 am, Brandon Long via dmarc-discuss wrote: At least at one point we definitely saw enough senders requiring too many lookups that we cared more about trying to find a positive evaluation than downside from

Re: [dmarc-discuss] If my understanding is correct?

On Sun 27/Sep/2020 09:14:46 +0200 Blason R via dmarc-discuss wrote: Hi Folks, I am starting with DMARC implementation and analysing the XML report without any GUI tool just to clear my understanding. Can someone please confirm if below marked in *bold* is correct? Yup, it sounds correct.

Re: [dmarc-discuss] SPF and DKIM

Hi, On Wed 20/May/2020 07:31:35 +0200 Roshan Hiripitiyage via dmarc-discuss wrote: > Can we enable DMARC just by enabling only SPF?, without DKIM? If it's possible > what are the issues we will come across without DKIM? While it is possible, SPF only won't cover forwarding. Mail that you send

Re: [dmarc-discuss] DMARC and SPF Failures

Hi, On Fri 21/Feb/2020 17:46:32 +0100 Marisa Clardy via dmarc-discuss wrote: > > In our organization, we provide mail filtering for customers. We had SPF > failures being rejected for a long time, however recently, we implemented > DMARC, and set it so that if a domain has a DMARC policy, it

[dmarc-discuss] PolicyPublished, was PolicyOverride in Reporting

Hi, I'm not clear on what Brandon actually said. I agree that the schema doesn't make that clear: policy_published, like report_metadata, occurs once in a report. I don't think one should send multiple reports in the face of policy changes. It would complicate report sending quite.

Re: [dmarc-discuss] Testing DMARC

Hi, On Wed 08/Jan/2020 01:29:35 +0100 Al Iverson via dmarc-discuss wrote: > In fact, I've gone and whipped something up: > > https://xnnd.com/dmarcbounce.cgi > > Please don't use it for evil. I may yank it or rate limit it later. > > Suggestion of a domain to try to get a positive result:

Re: [dmarc-discuss] Re-verifying external report destinations

On Fri 08/Nov/2019 18:03:00 +0100 Ken O'Driscoll via dmarc-discuss wrote: > Quick question: > > Is is common for providers to re-verify external report email addresses > from time to time? It should be verified every time, since one can also override the destination address. > I ask because a

Re: [dmarc-discuss] DMARC fails for "on behalf of" messages

> you have to try to find out users who are sending emails in a way you > described, and ask them to change FROM address to the one matching > sender domain (senderdomain.aaa) Or change the bounce address while signing. Having an SPF pass helps in case of DKIM hiccups. > or you can move to

Re: [dmarc-discuss] What is the end goal of DMARC?

On Wed 17/Oct/2018 18:41:09 +0200 John R Levine wrote: >>> wildcard *.dmarc.fail addresses and they work fine.  My mail server >>> knows what's been rewritten recently and rejects everything else. >> >> Wildcard *.trailing.parts doesn't work, but is existent. > > I have a wildcard MX for

Re: [dmarc-discuss] What is the end goal of DMARC?

On Mon 15/Oct/2018 20:56:44 +0200 John Levine wrote: >> I'd favor domain.INVALID. Its only defect originates from a dubious >> reject-on-nxdomain advocacy, which would require to use domains with >> wildcard records (e.g. domain.REMOVE.DMARC.TRAILING.PARTS).> > I did INVALID for a while and it

Re: [dmarc-discuss] What is the end goal of DMARC?

On Sun 14/Oct/2018 16:29:15 +0200 Al Iverson via dmarc-discuss wrote: >> >>> Rewriting the from address to something that fails -- and thus is >>> potentially going to fail delivery at any ISP that checks to see if >>> the from address is valid -- seems crappy to me. >> >> Sorry, I don't

Re: [dmarc-discuss] What is the end goal of DMARC?

On Thu 11/Oct/2018 21:17:44 +0200 John Levine via dmarc-discuss wrote: > In article <5bbf9b2b.6010...@signal100.com> you write: >> Other than rewriting headers (which of course can be done in a number of >> ways), what would you suggest? >> >> Perhaps a new RFC defining new headers which MLs can

Re: [dmarc-discuss] What is the end goal of DMARC?

On Thu 11/Oct/2018 01:39:55 +0200 Shal F via dmarc-discuss wrote: > >> However, if the eventual goal is for everyone to be using DMARC and >> generating emails that pass DMARC, then either rewriting headers or >> resigning messages with ARC is eventually going to be required for >> every email

Re: [dmarc-discuss] Is it already possible to distinguish all four of these cases in DMARC reports?

Hi Pete, On Tue 11/Sep/2018 20:37:45 +0200 Pete Holzmann via dmarc-discuss wrote: > [...] > > 1) Fully compliant. We (or authorized agent) sent it, and all is well > > 2) We sent it but there are one or more compliance issues which may result in > blocking at the recipient end (if we are using

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Fri 01/Jun/2018 07:40:07 +0200 Roland Turner via dmarc-discuss wrote: > On 31/05/18 23:13, Alessandro Vesely via dmarc-discuss wrote: > >> My filtering ability is visible to the people I forward to. Although targets >> don't see what I spare them, they can imagine. If you

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Thu 31/May/2018 02:27:35 +0200 Roland Turner via dmarc-discuss wrote: > On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote: > > I took it as self-evident that I was describing a transition from an > embedded list to a reputation data feed. Got it :-) >>>&g

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote: > On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote: >> [...] which includes pretty much all mail sites. The latter is *not* a >> slow-moving data set. It grows steadily. > > Steady grow

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Tue 29/May/2018 01:27:33 +0200 Roland Turner via dmarc-discuss wrote: > On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote: > > For the implied question ("Why would small guys be interested?"): > >  * ARC headers simply provide a view as to what happene

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Sat 26/May/2018 06:55:55 +0200 Roland Turner via dmarc-discuss wrote: > On 25/05/18 19:00, Alessandro Vesely via dmarc-discuss wrote: > >> Wasn't this tried for SPF already? > > A whitelist of "I trust these guys to make exactly the same abuse-filtering &g

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Thu 24/May/2018 20:58:30 +0200 John Levine via dmarc-discuss wrote: > In article <445884976.7940.1527153118...@appsuite.open-xchange.com> you write: >>This is actually an area of concern to us: how will small scale operations, >>like a server that only hosts a handful >>of mailing lists for

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On Mon 21/May/2018 18:24:13 +0200 Ken O'Driscoll via dmarc-discuss wrote: > On Mon, 2018-05-21 at 09:29 -0600, Pete Holzmann via dmarc-discuss wrote: >> QUESTIONS: >> 1) Is anyone working to solve these issues? >> 2) Has there been consideration of a forwarding token that could validate >> all

Re: [dmarc-discuss] DMARC Reporting De-duplication

On Fri 04/May/2018 21:37:35 +0200 Scott Kitterman via dmarc-discuss wrote:  > > Shouldn't it be possible to de-duplicate these based on message ID *before* > sending aggregate reports back? Can/should this be added to DMARC the next > time the specification is updated? [my emphasis] The

Re: [dmarc-discuss] Incorporation of dmarc in our email system

Hi Carl, On Thu 26/Apr/2018 16:03:03 +0200 Bongaerts Contract via dmarc-discuss wrote:  > > We're using Thunderbird and have been suggested by LinkedIn to set up DMARC to > control and/or recognize Fraudulent emails that come into our "In Box". For TB, I'd recommend you install DKIM Verifier:

Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

On Fri 14/Oct/2016 08:37:08 +0200 Juri Haberland via dmarc-discuss wrote: On 2016-10-13 20:06, Matt Simerson via dmarc-discuss wrote: The problem in this thread is an issue with some DMARC report senders failing to parse the DMARC URIs properly, if that DMARC URI includes size limits. Right

Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

On Wed 12/Oct/2016 21:38:45 +0200 Juri Haberland via dmarc-discuss wrote: On 12.10.2016 12:17, Steven M Jones via dmarc-discuss wrote: On 10/12/16 01:32, Juri Haberland via dmarc-discuss wrote: Btw: Did anyone notice that AOL sends DMARC reports with two To: headers? Looking at the last

Re: [dmarc-discuss] A bit quiet?

On Tue 20/Sep/2016 08:44:00 +0200 Povl Hessellund Pedersen wrote: Authentication-Results: spf=pass (sender IP is 209.85.214.50) smtp.mailfrom=my.test.dk; dsg.dk; dkim=pass (signature was verified) header.d=my.test.dk;dsg.dk; dmarc=pass action=none header.from=my.test.dk;dsg.dk; dkim=pass

[dmarc-discuss] Deliverability of DMARC reports

Hi, what is the best practice when DMARC reports bounce? I'm currently following the lazy approach, do nothing until recipients fix it. Next option would be to skip long time bouncers, but how long is "long", months, years, ...? Some bounces have complicated issues, like Google's bulk

Re: [dmarc-discuss] exegesis: pass and fail together

On Tue 05/Jul/2016 09:41:07 +0200 Thomas Krichel via dmarc-discuss wrote: I am new to DMARC. Google have sent me a report that I attach. 2a01:4f8:190:62e8::68 7 none pass fail openlib.org ... lists.openlib.org pass How can