Re: [dmarc-ietf] no DMARC result for DKIM testing and policy
John R. Levine skrev den 2024-03-22 19:22: On Fri, 22 Mar 2024, Benny Pedersen wrote: to confusion about DMARC and DKIM test flags. This document is already too long and too late. Unless there is an actual problem to solve here, let's close the issue and finish up. why is dkim fail here Because the mailing list modified the message before that header was applied. The IETF's mail server is a mess, and will be completely replaced over the next month. X-Spam-Status No, score=0.679 tagged_above=-999 required=5 tests=[AUTHRES_DKIM_PASS=-0.5, DKIMWL_WL_HIGH=-0.372, DKIM_ADSP_DISCARD=1.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, KAM_MXURI=1.2, MAILING_LIST_MULTI=-2, RCVD_IN_ANONMAILS=1.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=1.3, SPF_PASS=-0.1] autolearn=no autolearn_force=no Authentication-Results mx.junc.eu (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b="LudFgiUU"; dkim=pass (1024-bit key) header.d=ietf.org header.b="Adq3Jxj4"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=junc.eu header.b="e0KF8MmP" Authentication-Results ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=junc.eu what i get back on faulty maillist, note no problem will the faulty server add openARC or dito in rspamd ?, it must be done before maillist manager see the mail, not after ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] no DMARC result for DKIM testing and policy
John Levine skrev den 2024-03-22 03:52: According to Mark Alley : I don't feel particularly strongly about this, but I can see people thinking there's some correlation between DKIM testing and DMARC testing. It's not completely illogical, so it might be better to be explicit. Scott K Agreed as well. It's worth calling out, IMO. I disagree. DMARC is a decade old and I am not aware that anyone, ever, has had problems due to confusion about DMARC and DKIM test flags. This document is already too long and too late. Unless there is an actual problem to solve here, let's close the issue and finish up. why is dkim fail here X-Spam-Status No, score=-1.321 tagged_above=-999 required=5 tests=[AUTHRES_DKIM_FAIL=0.5, DKIMWL_WL_HIGH=-0.372, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-2, RCVD_IN_ANONMAILS=1.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=1.3, SPF_PASS=-0.1] autolearn=unavailable autolearn_force=no Authentication-Results mx.junc.eu (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b="Xr+FwPZI"; dkim=pass (1024-bit key) header.d=ietf.org header.b="Xr+FwPZI"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b="qTXLFk6y"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b="IB1/7fRP" Authentication-Results ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b="qTXLFk6y"; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b="IB1/7fRP" its already dkim fail at delivery to amsl ? let me see if eitf still breaks my dkim :=) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?
Murray S. Kucherawy skrev den 2024-03-18 04:15: It is not a false positive in that the technology did exactly what it was supposed to do; i.e., this is not a bug. We should just be clear about this. how to make dmarc fully aligned when spf +all is allowed :( it renders no go rfc is already solved ? please turn of html posting ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A.5 Issues with ADSP in Operation
Tim Wicinski skrev den 2024-03-10 00:48: I agree with Ale here - ADSP was moved to Historic in 2013. Appendix A.5 should be dropped, and some text in the document should mention ADSP is historic bla bla, ADSP is historic as working in spamassassin, see no reason to remove it, senders can still opt out if it does undesired things it was planned to be added to dmarc so the test could still be tested, but so far only hope for std without any code changes anywhere to support it, opendmarc does not yet do anyhing with above wished, hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Break SPF response: DKIM Only
Douglas Foster skrev den 2024-02-29 18:48: I am surprised at the lack of feedback about Barry's research link. It is a devastating attack on our ability to trust SPF when shared infrastructure is involved. As a result of that document, I have switched camps and believe that we MUST provide a DKIM-only option for DMARC. The proposed workaround, of using a "?" modifier to force SPF Neutral instead of Pass, seems to lack both awareness and implementation, since it was not even mentioned in the research document as a mitigation. spf specs have desided to allow +all and unlimited numbers of ips, there is no way to stop it unless rfc changes it even "v=spf1 ip4:0.0.0.0/0 -all" is fully valid for maillist is never being dmarc aligned anyway, but direct could be aligned, if not a forwarding host does something, with or without srs maybe rfc wise it could help to have a max ips to get spf pass ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From
Murray S. Kucherawy skrev den 2024-02-11 01:39: -MSK, participating Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable avoid this on maillists please why is stupid mua using quoted-printable while its html ?, i dont blame anyone from make silly msg standards for webpages ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-29.txt
Alessandro Vesely skrev den 2024-01-09 12:35: On 02/01/2024 21:47, Mark Alley wrote: Actually, thinking about it some more, simply inserting the word "aligned" between "valid" and "DKIM" would address it. "/It is therefore critical that domains that publish p=reject *MUST NOT* rely solely on SPF to secure a DMARC pass, and *MUST *apply valid *aligned *DKIM signatures to their messages./" +1, non-aligned signatures don't help DMARC. question to you is, why should maillists be aligned ? fix is NOT srs ! dkim spec should not allow reject of failed dkim, this is a job for dmarc, but this have to be solved first all else live in good intention :) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
Dave Crocker skrev den 2023-08-05 18:49: Governance seems like the best word to me, since Governance is what Reporting has provided to ADs in Monitoring Mode, but I do not want to say DMARG out loud either :-) Here, too, the domain owner does not govern the platform receiver. good news for paypal phishers, sadly the recipient should newer recieve mail that is with credit card info by dmarc is unaligned to the dmarc policy, when policy is basicly ignored we have the underlaying problem dmarc should solve, but as is does not ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Alessandro Vesely skrev den 2023-07-19 19:38: Let me reword the question: Are there lists that modify messages and don't munge From:? Authentication-Results: mx.junc.eu (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b="M78Nxm+h"; dkim=pass (1024-bit key) header.d=ietf.org header.b="KUhOcaZu"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="sAKZ9jA7"; dkim=fail (1152-bit key) reason="fail (body has been altered)" header.d=tana.it header.b="Axzjfts6" i really don't know :) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
John R Levine skrev den 2023-06-20 02:25: On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: I suggest that we do not only drop SPF, but also come up with better ways (simplification, tools, exchange formats) to implement DKIM in order to allow for a smooth transition. I'm scratching my head here. On my system I publish and rotate DKIM keys completely automatically. The only manual config is to edit the list of domains when I add or remove one from my mail server. It's not totally trivial but it's not that hard. I suppose we could encourage people to implement ed25519 signatures since the keys are small and more likely to fit in a single TXT record string for provisioning crudware that doesn't handle multiple strings, but beyond that, what do you have in mind? i see it as a problem, not as a solution, would we want all to be forced to accept new algo ?, will old be depricated ?, yes retorisk question i know, but be carefull, metacpan Mail::DKIM does not yet have it, but there is patches waiting so maybe it comes ? imho there would be more forward to see amavisd-new do ARC-Seal/ARC-Sign then to see it support one more algo in dkim, i know this is maybe just me ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
Scott Kitterman skrev den 2023-06-08 17:50: Isn't the way to say I don't use SPF for DMARC to not publish an SPF record? maybe "v=spf1 +all" or just something like over x numbers of ips, will trigger in dmarc not using spf ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 30 06:00:04 2023
Hector Santos skrev den 2023-04-30 13:49: and i top posted once with one msg ? :=) can it be with extended info like DMARC,DKIM,ARC,SPF,ADSP you name it ? What is the count based on? Is the count the amount of mail created since the last date of this report which was 1 week ago? Did Scott create 25 messages and myself 14 messages in one week? I don't think so. On 4/30/2023 5:59 AM, John Levine wrote: Count| Bytes | Who ++--- 94 ( 100%) | 946980 ( 100%) | Total 25 (26.6%) | 200417 (21.2%) | Scott Kitterman 14 (14.9%) | 190300 (20.1%) | Hector Santos 12 (12.8%) | 81505 ( 8.6%) | Alessandro Vesely 9 ( 9.6%) | 102937 (10.9%) | Jesse Thompson 7 ( 7.4%) | 123062 (13.0%) | Brotman, Alex 6 ( 6.4%) | 95933 (10.1%) | Douglas Foster 6 ( 6.4%) | 31018 ( 3.3%) | John Levine 3 ( 3.2%) | 30536 ( 3.2%) | Dotzero 3 ( 3.2%) | 17389 ( 1.8%) | Matthäus Wander 2 ( 2.1%) | 25665 ( 2.7%) | Barry Leiba 2 ( 2.1%) | 12106 ( 1.3%) | John R. Levine 2 ( 2.1%) | 5589 ( 0.6%) | 1 ( 1.1%) | 20637 ( 2.2%) | Seth Blank 1 ( 1.1%) | 5569 ( 0.6%) | Benny Pedersen 1 ( 1.1%) | 4317 ( 0.5%) | Jim Fenton ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc * ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
John R. Levine skrev den 2023-04-25 18:28: Since the only mechanism is mail and nobody's going to S/MIME encrypt their reports, I suggest just deleting it. TLS vs not TLS. I suppose, but that's not up to the report sender. If I say "rua=mailto:rep...@cruddy.org;, and the MX for cruddy.org doesn't do STARTTLS, what are you going to do? STARTTLS is optional, not required, hopefully you did know that is like some anti spam sites says you must have a MX to send mail or even recieve mail, A/ does not work at all, hmm :) dmarc should not enforce STARTTLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Alessandro Vesely skrev den 2023-04-19 11:09: Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS. No headers required. No delayed learning necessary. How would I get a clue of that? reading books ? if all maillist did arc on incomming mails before mailman scrapled dkim then all will be good, only left is dmarc is not in all places tests arc results It is all too easy to spoof an ARC chain offering false authentication results. ARC chains is untrusted by defaullt, where is the problem ? Allowing ARC to override DMARC result requires the ARC signer to be whitelisted. whitelisted is not right word for it, its either trusted or untrusted Now, one can object that whitelisting could be done by DKIM, by SPF, by DNSWL, without the need to introduce a new, long-winded protocol. However, ARC brings a couple of advantages: 1) In case of multiple forwarding steps, ARC delivers an ordered and cohesive chain which is easier to verify than a messy mass of DKIM signatures. recipients should only care of dmarc, not dkim/arc/spf fails to make this work dmarc must trust arc 2) Authentication results, which normally are deleted or renamed on crossing ADMD barriers, can be exported. well it scramples dkim, no go As they can sometimes be checked against message transformation, fraudsters can in the long run be debunked. if we keep the problem on maillist we lost all the goods dkim protect, i dont want this i still wonder what errors done in rspamd now :/ my dmarc policy is none, but rspamd says its reject, hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Hector Santos skrev den 2023-04-18 20:47: So your verifier see Benny’s as suspicious because of arc=fail? it does imho not fail on my own arc ? Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS. No headers required. No delayed learning necessary. if all maillist did arc on incomming mails before mailman scrapled dkim then all will be good, only left is dmarc is not in all places tests arc results its more waste that ietf add one more dkim signed keys, its not used at all in spamassassin unless one do welcomelist_from_dkim *@* ietf.org What more is needed? more dokument on dkim fails, basicly dkim should not defined any reject reasons, eg it should not be possible to reject in opendkim at all, this should be in opendmarc policy, not just random chain rejects ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Hector Santos skrev den 2023-04-17 20:55:
One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;")
retest
[3] https://winserver.com/public/wcDmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Hector Santos skrev den 2023-04-17 20:55:
Just consider your message source. The header overhead is massively
complex to read. It is really a waste on receivers.
Apr 17 22:53:28.015 [22350] dbg: authres: parsing
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass
(1024-bit key) header.d=isdg.net header.b="LJSFN/J6"; dkim=pass
(1024-bit key) header.d=beta.winserver.com header.b="x/bRVx9h"
Apr 17 22:53:28.015 [22350] dbg: authres: parsing
Authentication-Results: dkim.winserver.com; dkim=pass
header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;
dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com
(atps signer);
Apr 17 22:53:28.016 [22350] dbg: authres: skipping header, missing
property: =reject author.d=isdg.net signer.d=beta.winserver.com (atps
signer);
Apr 17 22:53:28.016 [22350] dbg: authres: results: dkim=pass
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;")
added and thanks if succces :)
[3] https://winserver.com/public/wcDmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Signaling MLMs
Hector Santos skrev den 2023-04-17 05:06: Anyway, there are far too much waste in electronic mail, ADSP/DMARC and this quest to resolve its issues, creating more junk, ARC, is not getting anywhere. ?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, works for me atleast, it sometimes helps to be a gentoo ebuild maintainer, i still like to find proxy maintainers helping me with arc its sadly appled AFTER mailman have scrampled dkim :/ arc sign/seal should be done on incomming mails, not on outgoing ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
Dotzero skrev den 2023-04-01 17:25: Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver to validate DMARC. Nobody forces mailing lists to accept mail from domains which publish a DMARC record let alone one which publishes p=reject policy. But it interoperates just fine once you make the effort. turn client domains into diggest mode on maillist if dmarc policy from sender is reject, this will not break anything in dmarc, or even dkim ps i sav ietf had removed dkim selector in dmarc reporting, on consistens or just error ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
Hector Santos skrev den 2023-03-31 16:30: - SPF make this a milter, its sadly missing, is possible to test in spamassassin 4 with authres - DKIM remove reject code in dkim, so it cant reject any mails, is possible to test in spamassassin 4 with authres - DMARC this still miss to use ARC results, is possible to test in spamassassin 4 with authres - ATPS is to hard to deploy, is possible to test in spamassassin 4 with authres - VBR is nice, but to much centralismen, is possible to test in spamassassin 4 with authres you only miss ARC and BIMI But we continue to have the reputation model being pushed over policy and we continue to have this problems. its 20 years to late, codebase is maked now with metacpan Mail::DMARC ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC Dependency?
Seth Blank skrev den 2023-03-25 00:17: Microsoft is using ARC quite heavily, and has reported on this list and at M3AAWG of the impact it makes Microsoft even has on their public roadmap that tools are being built for their customers to enable per-customer sealers that they choose to trust: https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc i dont like there model of make pr custommer trusted by arc, it should imho be trusted on forwarder only, not on random custommer but ok if it can be made complicated lets do-it, like microsoft-edge on linux, where firefox say web.skype.com works better with edge, hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 7.1 SPF -ALL
On 2022-02-11 17:25, John Levine wrote: A bare -all is clearly a special case, the converse of null MX, that means no mail at all. I agree the current wording is fine. nullMX is supported from all mta, but spf is lotto ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 7.1 SPF -ALL
On 2022-02-11 08:57, Douglas Foster wrote: This section implies that publishing SPF -ALL is a risky move, which is made worse by DMARC. SPF -ALL is a only risk when (a) the message is forwarded without MAILFROM rewrite and (b) the evaluator does not implement DMARC. +1 Rather than telling senders to weaken their SPF policies, we need to make it clear to evaluators that they should implement DMARC correctly. Proposed language for the second paragraph: why spf -all when there exists nullMX ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 20:40, John Levine wrote: It appears that Scott Kitterman said: How about if it has a null MX and a DMARC record or DKIM keys? Remember that those records are at different names than the MX. ... There's two ways we could go at this question: 1. A domain that, except for the null mx, would fit the criteria for non- existent. This would be kind of weird, since mull mx only makes sense if you have an A/, but I wouldn't think existence of a null mx alone would be enough to make the domain 'exist'. 2. A domain which has an A/ and null mx. Since it claims to be a no mail domain, we could treat it as not existing for DMARC purposes. Since RFC 7505 specifies null mx is for domains that don't accept mail, but is silent on sending mail, these should probably exist for DMARC purposes. I think that your point is about #2 and I agree. #1 is definitely a corner case, but if the only thing there is a null mx, I'd be quite comfortable saying it doesn't exist. It's about both. What if a domain has a null MX and a DMARC record? Maybe it has an SPF record, too. For your #2 you seem to be saying that if I send no-reply transactional mail, my DNS would look like this: notifiy.bigcorp.com. IN MX 0 . /* we don't receive replies /* IN A 0.0.0.0 /* make the domain exist */ _dmarc.notify.bigcorp.com. IN TXT "v=DMARC1; p=reject; ..." /* it's all aligned */ s._domainkey.notify.bigcorp.com. IN TXT "v=DKIM1; h=sha256; p=MIIBIjANB..." /* it's signed */ thanks for another rule to mx check in mta stage hopefully any-ip is just an example, not a real world test should spf allow 0.0.0.0/0 ?, sadly it does ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 20:04, John Levine wrote: This sounds like local policy again. Personally, I am not crazy about getting mail that I can't reply to, but my mailbox is full of mail from my bank and stores from which I have ordered telling me that I can't reply to their messages. banks or stores do not know anything about null mx :=) null mx is not that known on many dns hosters :/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6. Non-existent Domains
On 2021-12-05 05:13, Scott Kitterman wrote: Should we modify the definition of non-existent domains so that a domain that only has an RFC 7505 null mx record is still considered non-existent? hope you will not change rules to ignore null MX ? why is it even a question ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reversing modifications from mailing lists
On 2021-12-05 21:24, John R Levine wrote: Agreed there's risk in HTML hiding content and showing malicious things but that risk has existed before. An updated DKIM authenticator could help us understand who did those malicious updates along some forwarding path. I'm pretty sure that changing DKIM is very out of scope for this working group. +1 We have a decade of experience with DKIM. If l= were useful, someone would have figured it out by now. is there any talks about dkim l= tag anywhere ?, can dkim verify l= number of lines is not changed ?, will it gives special results if its changed or not changed, does dmarc understand this tests in dkim ? if dkim cant do this its not usefull dkim specs says it exists imho ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-18 14:56, Baptiste Carvello wrote: There is no abuse. MLMs act as submitters. Setting From: should be a must. This all habit of telling other actors what they should or must do has to stop. This hubris is the original sin of Yahoo, which started all the trouble. yahoo follow same error as this maillist here ?, why is ietf add dkim signing to my mlm message at all ?, amazonaws does the same error, sendgrid does the same error, all foolsly forwarding service dkim sign mails that is not originating from them, if thay stop this and did a openARC seal/sign we would all be happy, but that process of openARC must be done BEFORE dkim is breaked, period :) lets talk about dmarc when this is solved or even is rfc stable note its fairly simple to add Mail::DKIM::ARC::Signer and Mail::DKIM::ARC::Seal instaed of using dkim signer for non origination mails in amavisd, who will make that path ? if done problem solved remember mails that is in amavisd origination must not be ARC signed or Sealed but it must be dkim signed rest is handled downstrem on breaking dkim forward hosts ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-18 14:11, Alessandro Vesely wrote: Perhaps an RFC could improve the way average MLMs rewrite From:? what is the point of dkim then ? note i did not write dmarc here ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-17 19:43, Alessandro Vesely wrote: On Sun 17/Oct/2021 03:10:21 +0200 Joseph Brennan wrote: Telling mailing list owners and mailing list software designers to violate RFC 5322 Internet message format's description of the From header line to make you happy is abusive. There is no abuse. MLMs act as submitters. Setting From: should be a must. mlm is never origating, so dkim sign mlm fails all it needs is that mlm start doing ARC-Seal, ARC-Sign, and both of them must be done BEFORE dkim is breaked we all loose if order of things is inccorect hope spamassassin 4.x.x will finaly help people understand the main problems of breaking dkim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-08 02:47, Douglas Foster wrote: Assume the following: List "L" has implemented ARC and has subscribers from 10 domains, Domain through DomainJ. A user from DomainA, which publishes p=reject, submits a post to the list. What information does List "L" use to decide whether to rewrite "From", for each of the 10 domains? How is that information obtained? what info ? are you asking how to break dkim ? dkim have still adsp, and atleast this still stands in spamassassin, since it uses metacpan Mail::DKIM perl module simple do not break dkim i think its endless debate on we want to fix it, but no one can see the light in the jungle of solutions on problems never existed on servial maillists that does not break dkim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-07 15:38, Scott Kitterman wrote: I'm out of time, but something like that which defines the solution space rather then trying to specify THE solution is probably the only path forward. maillists can dmarc reject posters that use dmarc reject policy or quarantine, problem solved downstream for postfix there is a nice smtpd_milter_maps so maillists ips is not dkim/arc/dmarc rejected at all i pick my games, but if maillists stops dkim sign non orginating mails 50% of the main problem is solve there maillist should only ARC seal / and ARC sign, nothing more, if that is done BEFORE dkim is breaked, then it wont break dmarc from github trunk of opendmarc, time to stablelize ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] From: munging, was Ratchets - Disallow PCT 1-99
On 2021-07-23 12:08, Alessandro Vesely wrote: https://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio/ all this is solved if maillists stop dkim signing of non origination postings and only do the arc sealing so all dmarc testers can see originating spf, dkim pass take sendgrid, thay forwarded netflix phishing emails, and thay belived dmarc protected there ignorance to some kind out off there services never trust a forwarding server that does there own dkim signing, period dmarc needs openARC testing to all above to work, then maillist can break maillists to there own stupid needs without breaking dkim cant be verified on dmarc recipient servers hope the best for the future ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
On 2021-07-20 19:16, Dotzero wrote: On Tue, Jul 20, 2021 at 12:39 PM Dave Crocker wrote: On 7/20/2021 7:54 AM, Barry Leiba wrote: I would like to see us deprecate PCT entirely, +1 +1 if this was postfix it would not be accepted, old habist must stay to be backward compatible, sadly not all understand why with all that changes it could end with no one uses this good software writed after c code i provided :( hope for there LTS of it all ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On 2020-12-21 18:27, Alessandro Vesely wrote: On Mon 21/Dec/2020 01:52:11 +0100 Benny Pedersen wrote: On 2020-12-20 23:07, Michael Thomas wrote: On 12/20/20 2:01 PM, Benny Pedersen wrote: For the message I'm replying to, I got: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass reason="Original-From: transformed" (whitelisted) header.d=junc.eu; dkim=pass (whitelisted) header.d=ietf.org header.b=GUNfiCpP; dkim=fail (signature verification failed, whitelisted) header.d=ietf.org header.b=IIMQxhd+ Two out of three is not bad, is it? If IETF only did ARC seals, I'd probably verified no signature at all —since I don't run ARC checks. metacpan Mail::DKIM gives dkim invalid if just one dkim is invalid, so spamassassin says aswell dkim invalid what software used above to show this results ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On 2020-12-20 23:07, Michael Thomas wrote: On 12/20/20 2:01 PM, Benny Pedersen wrote: hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full internet standard and expressly intended for lists, etc to resign if they broke the original DKIM signature. We have always had the ability to do reputation checks regardless of ARC. I'm not sure when this wg lost sight of that. only original senders should dkim sign, rest should only arc sign, i dont have to agre on anyhing other then that, if maillists dkim sign thay try to steel the original dkim private key without succes, and there is possible a solotion to dmarc adsp handling this break seeing eitf do 3 dkim sign just to be sure it does not work ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On 2020-12-20 19:13, John R Levine wrote: On Sun, 20 Dec 2020, Alessandro Vesely wrote: question is who steps up to provide such shared lists. Dnswl.org counts about 25K domains. I suppose one might try them but I expect most of them are not sending forwarded mail. only sending to maillists here that breaks dkim and do not add arc before breaking dkim, world of 2020 cant be better :=) I've finally gotten around to doing ARC checks in my SMTP daemon so I can see who's adding ARC seals. hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim now that nearly all maillists i am on have showed what not to do, its hopefully solved soon ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
Dotzero skrev den 2020-12-08 19:50: And here we get to some of the crucial unresolved questions involving email: "Does the wishes of a user of an account at a domain supercede the policies of the domain owner/administrator of a domain?" "Does a domain owner/administrator have the right to externalize enforcement of their internal usage policies?" These questions and associated answers go far beyond DMARC but certainly impact how one views policy statements made by DMARC. i have solved it by using fuglu :=) when i used milters in postfix i just did that in postfix to tell dont use milters on maillists ips, pretty simple but there might be more options, eq dont break dkim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
Michael Thomas skrev den 2020-12-03 03:58: if you're trying to make a point about the bloat, you might actually get your facts straight. ARC adds an additional DKIM signature and a Seal. i have no idea what a X-Google-DKIM-Signature is and is not relevant. would you show an example on that openARC adds openDKIM signature ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 20 06:00:05 2020
John Levine skrev den 2020-09-20 11:59: Count| Bytes | Who next weeks lotto ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
John R Levine skrev den 2020-08-02 23:24: If large mail providers were willing to whitelist known mailing lists we wouldn't need ARC. if no one breaked dkim then we did not need arc See previous messages for why that isn't sufficient. missing arc will not break spf dkim, but it preserves state of pass TO the maillists, but only if maillists run arc at the first stage of breaking dkim, i only know dovecot maillist that have solved it as it should be, i think others could do the same of not breaking dkim, or if need to, do a fully arc sealing ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
Joseph Brennan skrev den 2020-07-23 17:05:
Since it is off topic, I will give a short answer. If the Header From
matches /From: anything , check whether domain is one
that needs the rewrite, gmail.com for example, and change the field to
be simply /From: string@domain/.
ok
In Mimedefang, we created a per-message global hash %Header, and
parsed each field (split on :). So for example $Header{from} was the
value of the From header field. The hash was used in various rules. MD
has a built-in function to replace the content of header fields, which
I think is a milter function.
but it fails to not break dkim then
ietf.org have more ips to spare to make not breaking dkim, sadly so many
experts doing the wrong things :(
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
Joseph Brennan skrev den 2020-07-23 15:15: Briliant! I wish we were still using Mimedefang. This wouldn't be hard to code, and the results would be effective. show the source on how to make this work in mimedefang, or will it completely fail with spampd ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mailing List Digest Considerations
Hector Santos skrev den 2020-07-07 15:00: Not sure, Benny. I still haven't gotten the "Ah Ha" with ARC. when i post to dovecot maillist i get DMARC PASS on my own domain, and dovecot maillist do only ARC sealing Another thing that just came to mind is the number of messages in a digest. does not matter What if its set to 1? see above if possible. In our MLM, the admin sets this amount, not the subscriber. so if users do it it will break dkim mlm digest signing ? :=) But I have seen another MLM, forget which one, mlmmj ?, mailman can behave nicely aswell, more or less just unwilling admins that turns it into break dkim allowing the user to set the digest amount. How would a digest of 1, are digest not sent daily or weekly ?, it have never being on more then 1 msg if allowed, be different from a normal non-digest submission distribution. are how digest is done imho I see it as the only form of a MLM output that would have not any "argument" or "conflict" with DKIM/DMARC/ARC concerns. digest is dkim signed from mlm, thats not the same as mlm forward and break dkim original senders dkim signing, thats why its diffrents problem to solve The list digest agent can do what it wants without any debate. so can ietf of breaking dkim, but not provide a dkim pass on there own problem ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mailing List Digest Considerations
Hector Santos skrev den 2020-07-07 13:52: What would be, if any, DKIM, DMARC and ARC consideration when digests are created? user posts to maillist should only be ARC sealed digist post could be dkim signed aswell, since content is dkim breaked anyway but both should still be ARC sealed then DMARC can test if it passes from original senders have i missed anything ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
Doug Foster skrev den 2020-07-06 14:48: I like the idea of making signatures recoverable wherever possible. For mailing lists, I wonder if this approach is sufficient to solve the whole problem. If the MLM transformation is for security rather than informational purposes, I expect that the transformations will be (even should be) non-reversible. For some spam filters, it might be important. Lots of spam filters add DKIM-invalidating content upon entry to the protected domain. Many of those changes should be reversible. URL rewrite is the most difficult to reverse using this approach. However, when the incoming and outgoing email gateways are from the same vendor, as I suspect is often the case, the reversal should already be feasible using proprietary methods. Is any known spam filter vendor doing this type of reversal? i know mailman can do the right things, ARC sealing, and then nothing more, then its op to DMARC to test results from ARC, job done but this does not work if DKIM is breaked before ARC sealing is done, and DMARC testing is not yet maked into stable releases yet, and in gentoo none of it exists i have dropped OpenDKIM, OpenARC, OpenDMARC, and now just live with fuglu modification and thereby confirm that the original signature still verifies against the original content. in the end it might work better if maillists in generic does not try to fix anything thay self creates as a problem to solve, dovecot and postfix maillists is known to not break DKIM, and currrently only dovecot is doing ARC sealing, not the worst case, but nice to know that maillist can stop breaking DKIM hope it will be standard in 2021 finaly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 2020-06-13 22:13, John Levine wrote: In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write: The "mailing list problem" was introduced into this discussion as an objection to DMARCs progress, by implication suggesting that DMARC must be delayed until a solution is found which creates no inconvenience to mailing list operators. At this point I truly have no idea what your point is. The fact that DMARC screws up mailing lists is enough of a problem that a lot of people have put considerable time and money into inventing and implementing ARC. even if ietf tribble dkim sign mails it still gives X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on localhost.junc.eu X-Spam-Status: No, score=-9.3, required=5.0, Autolearn=unavailable autolearn_force=no, LastExt=4.31.198.44 X-Spam-Rules_score: DKIM_INVALID=0.1,DKIM_SIGNED=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25,LOCAL_WHITELIST_URI=-0.5, MAILING_LIST_MULTI=-10.1,SPF_HELO_NONE=1.1,SPF_PASS=-0.1 hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 2020-06-13 18:42, John Levine wrote: In article you write: I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.) I can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user login. ... That's OK, the rest of us can. if no one breaked dkim then arc would not even be needed IMHO ietf is gone to far of fixing problems ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] spf helo considered in arc ?
i just like to know ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 2020-05-20 17:49, Dave Crocker wrote: This looks like it has a strong constituency against the proposal, a much smaller constituency in favor of it, and little or no offered benefit. Yes? if the mouse have 2 holes to select from, it will be 50% fails in 50% reports, this is why postfix keep old dokumented bugs :) bla i am just funny here, it can be solved, but main part is that software need to be updated then, and not all precompiled problems do this same reason i dropped sid-milter, opendkim, openarc, opendmarc, to unmatined and still have unclear bugs not solved, no thanks to it ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc.ietf.org does not fail dmarc
On 2020-05-16 19:24, John Levine wrote: In article you write: https://dmarcian.com/domain-checker/ test it there You're misreading what it says. The DMARC setup is fine. page does not test arc results :) if its complete impossible to not break dkim i will leave this maillist After you leave, you might want to review the ARC work we've been doing over the past year. it does not matter if opendmarc does not use openarc yet opendmarc from trunk does, but none of it is stable on gentoo, even opendkim is not stable, since gentoo devs insists on backports with delays to not happend soon thats why i leaved from opendkim, openarc, opendmarc, its simple to unstable for real life ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc.ietf.org failed dmarc
On 2020-05-19 00:09, Douglas E. Foster wrote: I understand your question to be "Why do I see invalid DKIM signatures on messages from the IETF mailing list?" yes this is my consern, it should not be breaked on take ownerships, if maillist can break dkim and take ownerships and still not make it dmarc pass then its incompetent maillist admins its just sadly not the only maillist its daily problem on I can provide your answer The typical message on this mailing list has three signatures: Signature Analysis: * The first signature is from the submitter's organization. In your message, it was from junc.eu. yes * The second signature is applied by IETF shortly after receipt of the message. opendkim resign ? * IETF adds an Athentication-Results header which indicates that the junc.eu signature was valid when they checked it yes i did my homework then . * Then, IETF changes the FROM address to be @dmarc.ietf.org and tags the Subject with [dmarc-ietf]. This breaks both of the first two signatures. why is it done ?, to fix there own problem of breaking dkim ? * Then, IETF applies a second signature which is verifiable. it just not giving dmarc pass, why ? Integrity Analysis: * The IETF rule is "an unverified signature is the same as no signature." Therefore, the invalid signatures can and should be ignored. It appears that your tool is getting confused by the invalid IETF signature and ignoring the valid one. i think that on the safe side to not make dkim pass with signatures not from original outhor domain, if that ships sail it would make it hard to verify without openarc sealing * The message passes SPF because the Sender Address has been changed to dmarc-boun...@ietf.org. thats the standard aling changes, all well there * The second passes DKIM because the second IETF signature verifies. but why is it not dmarc pass * No official assertion is been made about the sender's domain, so there is no need to verify against that domain. But if you want to do so, you can evaluate whether to place trust in the Authentication-Results header applied by IETF. waiting for AuthRes plugin in spamassassin then all problems will be bigger if results is evaluated outside of spamassassin from AR headers hope developpers wake up on the risk of breaking more then just dkim * IETF converts all messages to plain text, and strips or blocks attachments, so they have minimized the opportunity for malicious submission. i remember with amavisd-new it was good to disable 8bitmime before letting amavisd-new do its dkim sign, that helps make dkim signed signature not break on mime converters Implications for Email Defenses: This example is a reminder that every message is a take-it-or-leave-it proposition. You can accept the message or reject it, based on the message characteristics, but you will probably be unable to cannot change the sender's behavior. In this situation, you may not like having two signatures from IETF, but you cannot change IETF.As a result, any spam filter needs to be very flexible about exceptions. Too many spam filters do not have adequate exception mechanisms. i will let spamassassin do its work on dkim breakage on maillists, but that is same reason i do not use sid-milter, opendkim, openarc, opendmarc, its designed badly to maillists that claim its impossible to not break dkim Hope this helps, it does hopefully :=) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc.ietf.org failed dmarc
On 2020-05-18 22:32, John Levine wrote: spamassassin still says dkim invalid here Yes, that is correct. I would suggest learning more about DMARC and why that is not a problem. i will when spamassassin supports dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc.ietf.org failed dmarc
On 2020-05-18 22:02, Tim Wicinski wrote: +1 John and thanks. this mail is dkim valid au here, hope to see posts from John that is pass aswell ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc.ietf.org failed dmarc
On 2020-05-18 21:51, John R. Levine wrote: While the setup for dmarc.ietf.org was correct before, it was pretty funky. +1 I suggested they make a few changes which they have now done: there is now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX record pointing at the mail server rather than A/ records. spamassassin still says dkim invalid here not using sid-milter, opendkim, openarc, opendmarc or even python based dkim validators, pure perl Mail::DKIM 0.440 in gentoo sorry if its my own fault i self use fuglu 0.10.6 to dkim sign ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 2020-05-18 10:27, Alessandro Vesely wrote: Best Ale -- could you remove empty lines in your signature ? lets see dmarc fail, dkim invalid test in spamassassin ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] dmarc.ietf.org failed dmarc
https://dmarcian.com/domain-checker/ test it there if not taking ownerships it will get dmarc pass oh well software testers needs cases to test on its one here then if its complete impossible to not break dkim i will leave this maillist ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC bis: ticket 69: add JSON reporting format?
On 2020-05-16 11:38, Alessandro Vesely wrote: Please let's not even air such hypothesies. There is still people who send zip rather than gzip... and still people that does not use sid-milter, opendkim, openarc, opendmarc, all of them wait for software updates or precompiled problems to be solved ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
John Levine skrev den 2016-11-03 04:12: Indeed. We look forward to hotmail/outlook implementing ARC so your users can resume using mailing lists the way they have for 30 years or more. waiting for ARC to solve something that is only a problem on maillists that break DKIM, whats next ? i see no problem on postfix maillist with dmarc pass, so why have others choiced a route of fails ? limit opendkim to only verify last signer could be a option, if last signer signs all mails, atleast dkim pass fron every mail here, but i dont like that route ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
Hector Santos skrev den 2016-11-02 21:05: ADSP/ATPS actually works very well. Its been in production for a number of years. I have "ietf.org" as a 3rd party signer assigned to my ATPS records in DNS. Supportive receivers can then see that I authorize ietf.org to sign my IETF submissions as my receivers do when I get a copy. My ADSP record for isdg.net is: dkim=all; atps=y; asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" Authentication-Results: linode.junc.eu; dmarc=none header.from=isdg.net Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b=vqpaROA9; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isdg.net header.i=@isdg.net header.b=twhXt8L/; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com header.b=ubq9bnhD; dkim-atps=neutral so it works ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
Benny Pedersen skrev den 2016-11-03 10:21: Cullen Jennings skrev den 2016-11-02 23:00: there is no problem as long no one breaks dkim Authentication-Results: linode.junc.eu; dmarc=none header.from=junc.eu Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b=bXpPFfNS; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=junc.eu header.i=@junc.eu header.b=J+BeXpkF; dkim-atps=neutral sure breaks dkim signed mails :( ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
