roblem doesn't seem right to me. There'd be an awful lot of
existing, current usage to unwind there to get back to your desired
square one, and I'd argue that there's value and utility to lose by
doing so.
Cheers,
Al Iverson
--
Al Iverson / Deliverability blogging at www.spam
email authentication goes.
You're more likely a sender, not a forwarder.
Cheers,
Al Iverson
--
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
__
ind-carbon-copy.
>
> Blind-carbon-copy is already a sign of spam.
Except when it's not, like this very mailing list.
Cheers,
Al Iverson
--
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools
+1 on adoption of Wei's latest draft.
--
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
Ietf-dkim ma
o be specific enough to exclude any of this from the
definition of DKIM replay; it says nothing yay or nay about the
potential for additional headers. And I think that's fine, as exploits
evolve and it would be limiting to have done otherwise.
Cheers,
Al Iverson
--
Al Iv
ional reality that large/savvy MBPs will
already be invalidating signatures containing l=, while driving the
point home for smaller providers or those who may be more of a
stickler about RFCs.
Cheers,
Al Iverson
--
Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.com // Deliverability
ht
as well. I lean toward thinking it should be called DKIM2
but your changes here don't necessarily prohibit that (or prohibit
future discussion on it).
Cheers,
Al Iverson
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
> In message il.com>, Murray S. Kucherawy writes
>
> >I've uploaded the charter,
>
> which I found at
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/
>
> for the record, I think this is suitable for moving forward
+1,
modifying content beyond byte X
with no corresponding failure in the DKIM signature checks.
In my opinion, Wei is correct here.
Cheers,
Al Iverson
--
Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.com // Deliverability
http://www.aliverson.com // All about me
https://xnnd.com/ca
lown imo) about l= go back 20 years.
> It's hardly a new argument, and anything the supersedes it will have the
> same considerations.
"Hardly new" doesn't seem to be a suitable reason to leave it be.
"Anything new will have the same problem" is a heck of an
this is great.
And this time around I'm going to try not to fall into the trap of
debating bits about DKIM shortcomings or potential fixes today --
seems like that's best saved for discussion within the charter-defined
working group, not in the meta-discussion around defining th
don't /only/ show failed-but-accepted messages. If
this use case is invalidated (is it? I don't quite understand why it
would be invalidated), others still exist.
TL;DR, DKIM2 w/o DMARC leaves what I think would be reporting gaps
that I think IT/security people might not want to lose insig
I
agree.
I honestly do want "no auth, no entry" but I approach it through
deliverability eyes of "my server, my rules" for inbound mail processing. I
want to enable choice, not demand the only path.
Cheers,
Al
--
Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.c
Thanks for taking the time to reply and explain, Todd! I appreciate it.
>> > Moreover it removes the need for any kind of reporting, as a Domain Owner
>> > will know from the rejections which messages that it authorized failed to
>> > authenticate and presumably why, and the Domain Owner will ne
ome back post send nowadays.
Even for those platforms, they effectively still utilize "one message
per rcpt to" as they use salted links and image paths to track clicks
and opens, respectively.
So if the question is, is this how it primarily is today, the answer
is that there's lots of
signature, accidentally or otherwise.
I think I don't want an existing DKIM verifier to be able to provide
some sort of result for a DKIM2 signature. I foresee much confusion
resulting from that.
I think there would be lots of downside from that confus
16 matches
Mail list logo
