On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
if DMARC is really the succes that dmarc.org claims it is [1] and with so
many of the big ESPs around here [2] I fail to see why it would be so
difficult to involve the MUA developers of these same ESPs?
On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy superu...@gmail.com
wrote:
If the input is the message and the output is a set of zero or more
SDIDs representing domains whose signatures validated, then I don't think
it matters if we go the v=2 route or the new header field name route,
On Apr 2, 2015, at 11:08 AM, John Levine jo...@taugh.com wrote:
Handled by whom? If we're talking about telling MUAs Don't render the
unsigned part of the content the same way as the signed content, then a
bunch of additional complexities begin to appear:
We went over all of this ages
So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...
I wondered about that, too, so before I proposed a version bump, I took a
look at the code that people use:
* Murray's opendkim C library: checks that the version is 0.5 or 1,
fails
On 4/1/2015 8:22 PM, John Levine wrote:
DKIM-Signature: v=2; d=example.com; ...
DaveKIM-Signature: v=1; d=example.com; ...
In this particular case, the incompatibility is a new kind of must
handle tag suggested by Ned Freed with the new rule that if a
verifier doesn't understand it, the
In the latter case, it's really an entirely new protocol, which should
be identified by the next-lower protocol, rather than by using the
version field as an in-bred demultiplexing field.
I suppose, but if the two procols are 99% the same, and the new one is
upward compatible with the old
On Thu, Apr 2, 2015 at 6:25 PM, John R Levine jo...@taugh.com wrote:
So receipt of a message signed in the new form will likely produce an
incorrect signature validation, ...
I wondered about that, too, so before I proposed a version bump, I took a
look at the code that people use:
*
On the signing side, the signer has the new option of adding a conditional
signature, but all of the old options still work.
Protocols are defined by bits over the wire, not APIs.
They're defined by both. The main reason we published RFC 5672 was to
clarify that the API returns the value of
That is, the 'payload' of DKIM is the delivery of a validated domain
name. In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.
These hairs are split too finely for me to understand. The DKIM validator
In article 551cc3fe.10...@dcrocker.net you write:
On 4/1/2015 8:22 PM, John Levine wrote:
In the latter case, it's really an entirely new protocol, which should
be identified by the next-lower protocol, rather than by using the
version field as an in-bred demultiplexing field.
I suppose, but
On 4/2/2015 8:14 AM, John R Levine wrote:
On the signing side, the signer has the new option of adding a
conditional
signature, but all of the old options still work.
Protocols are defined by bits over the wire, not APIs.
They're defined by both.
Sorry, no.
Or rather, while it is common
Murray S. Kucherawy responds to my (not-so-new) suggestion:
Some days ago I tentatively suggested signing only part of
some message parts, in particular part of the Subject header
(excluding any future additions of [list-identification]),
As I recall this was considered during the
On 4/2/2015 9:02 AM, John R Levine wrote:
That is, the 'payload' of DKIM is the delivery of a validated domain
name. In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.
These hairs are split too finely
On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker d...@dcrocker.net wrote:
The main difference I see is that if we call v2 something else, we now
have a tedious administrative exercise of finding every place something
refers to DKIM and change it to DKIM or DKIM-plus. This does not
strike me
Handled by whom? If we're talking about telling MUAs Don't render the
unsigned part of the content the same way as the signed content, then a
bunch of additional complexities begin to appear:
We went over all of this ages ago when DKIM was young. It should all be
in the DKIM WG archives.
-
What sorts of things do you want to see in an MUA?
- Gmail says, of messages in the spam folder, “This message is here because
others marked it as spam.”
- If you enable it in Gmail, they also put a key beside authenticated messages
- Outlook.com/Hotmail has a Green Shield in the List view next
16 matches
Mail list logo
