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
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
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
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
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
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
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
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
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)
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
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
%) | 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
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
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
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
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
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)
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,
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
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
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:
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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.
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
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
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
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
i just like to know
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
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
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
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
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
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
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
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
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
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
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
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
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
61 matches
Mail list logo
