Let us remember that DKIM+Policy were separated into two protocols; a
DKIM-BASE layer and a secondary domain signing practice layer (SSP which
evolved to ADSP). Making an invalid signature equal to a missing signature
concept was a security logic which allowed for the exclusive or strict
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos hsan...@isdg.net wrote:
While DKIM-BASE tried to clean up this separation of the author domain
policy, it could not because of all the past existing ADSP or SSP
references in the many DKIM related RFCs, see RFC6376, section 1.1. But
On Jun 19, 2014, at 11:45 AM, Murray S. Kucherawy superu...@gmail.com wrote:
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos hsan...@isdg.net wrote:
While DKIM-BASE tried to clean up this separation of the author domain
policy, it could not because of all the past existing ADSP or SSP
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis doug.mtv...@gmail.com
wrote:
Our company has had extensive experience dealing with email spoofing.
While reputation is able to deal with bulk spamming, it is ineffective at
dealing with a phishing problem, the intent behind DMARC. It is a basic
Let me clarify it.
From a deterministic protocol standpoint, depending only on base signing
analysis has no payoff, i.e. no filtering is legitimately possible with high
confidence and zero/low false positive.
What is left is non-deterministic, heuristic, classification Bayesian scoring,
It would be nice to have some concrete examples in the draft, I find those
easier to follow than descriptions. So, maybe something like:
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s1024;
d=sender.example.com;
On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed ned.fr...@mrochek.com wrote:
I'm uneasy with an increase in version that isn't done in a complete
replacement for RFC6376. We're not just registering a couple of new
extension tags here. I would prefer that, if we do go decide to go down
this
On Mon, Jun 16, 2014 at 1:17 PM, John Levine jo...@taugh.com wrote:
Here's a draft that puts the forwarding thing into DKIM, with the
dread version bump. It defines a general syntax for conditional
signatures, with the forwarding signature the only condition defined
so far. (Since you
sigh, stupid editor. As I was saying:
I can think of a variety of ways to get this effect by hacks that stay
at v=1, all rather ugly. For example, we could invent
pseudo-canonicalizations like c=condrelaxed/condsimple which are the
same as relaxed and simple, but only are valid if the verifier
Here's an example. The top signature is from the list, the second and
third signatures were applied by the sender. The second is the normal
signature and the third a weak conditional signature. The third has
cs=fs which means it's only valid with an additional (forwarder)
signature, and fs=t
On Thu, Jun 19, 2014 at 4:20 PM, John R Levine jo...@taugh.com wrote:
I'm uneasy with an increase in version that isn't done in a complete
replacement for RFC6376.
The problem may be that we don't agree about what DKIM versions mean.
Here's what I would like them to mean:
[...]
Actually
11 matches
Mail list logo
