On 02/11/2018 06:20 PM, Dave Crocker wrote:
On 2/11/2018 5:54 PM, Michael Thomas wrote:
You clearly have no idea what you are talking about.
Mike
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Mike,
On 2/11/2018 5:54 PM, Michael Thomas wrote:
You clearly have no idea what you are talking about.
Mike
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Mike,
Please review the participation rules
On 02/11/2018 05:46 PM, Dave Crocker wrote:
On 2/10/2018 10:47 AM, Michael Thomas wrote:
But I still think this entire conversation is silly in its
theoreticality.
Extra design complexity and consuming development resources --
programming, bench testing, interoperability testing -- for
On 2/10/2018 10:47 AM, Michael Thomas wrote:
But I still think this entire conversation is silly in its theoreticality.
Extra design complexity and consuming development resources --
programming, bench testing, interoperability testing -- for something
that is not essential, nevermind
On 2/10/2018 9:59 AM, John R. Levine wrote:
MIME was in significant use quite a bit before ESMTP was operational.
In fact it's a non-trivial feature that MIME only requires adoption by
author and recipient and not by /any/ of the infrastructure. IE, not
by SMTP.
Yes, I know, but I wish
On 02/10/2018 10:22 AM, Dave Crocker wrote:
On 2/10/2018 10:12 AM, Michael Thomas wrote:
DKIM-Signature-v2: vs DKIM-Signature: v=2;
Angels, meet the pinhead.
equal semantics does not mean equal implementation. the processing
for each of these takes place in very different parts of the
On 2/10/2018 10:12 AM, Michael Thomas wrote:
DKIM-Signature-v2: vs DKIM-Signature: v=2;
Angels, meet the pinhead.
equal semantics does not mean equal implementation. the processing for
each of these takes place in very different parts of the system. the
latter requires new code, albeit
On 02/10/2018 10:04 AM, Dave Crocker wrote:
On 2/10/2018 9:47 AM, John R Levine wrote:
Well, OK, other than DKIM-Improved-Signature how would you do
conditional signatures, where the signature has to fail if the
semantics of the re-sign tag aren't satisified? Remember that the
current rule
On 2/10/2018 9:47 AM, John R Levine wrote:
v= word (, word)*
where each word describes a semantic feature. Feature tag "1" is all
the stuff in RFC6376. My feature is mandatory to understand tags,
feature name "mandatory", so the signatures start
The listing of 'authorized' features
MIME was in significant use quite a bit before ESMTP was operational. In fact
it's a non-trivial feature that MIME only requires adoption by author and
recipient and not by /any/ of the infrastructure. IE, not by SMTP.
Yes, I know, but I wish you'd read what I've said about 8BITMIME. It's
Well, that's simply and completely false.
The message format specification(s) have no dependency on the email transport
mechanism.
Huh. When I look at RFC 822, section 3.1 says:
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the
On 2/10/2018 7:50 AM, John Levine wrote:
The idea with DKIM v=2 is that there are things that you cannot say in
a v=1 signature, no matter how many new tags you add, so you need some
way to tell verifiers what they need to understand. How about this?
We rebrand the v= tag to be a feature list
On 2/10/2018 7:50 AM, John Levine wrote:
PS: The reason you haven't noticed the versions in RFC822 is that we
put the version flags into SMTP. An 8BITMIME or EAI mail message is
not backward compatible with RFC822.
Well, that's simply and completely false.
The message format
In article <20180210092127.33398.qm...@f3-external.bushwire.net> you write:
>In any event, 822 is an existence-proof that decades-long upgrades are entirely
>possible without the scorched-earth approach of versioning. ...
Nope, see the PS. But anyway.
I don't understand this scorched earth
14 matches
Mail list logo
