>Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM
>failure is frequently not a
>sufficient basis for rejection.
I should hope not. The DKIM spec is crystal clear that an invalid
signature is equivalent to no signature.
R's,
John
_
John Levine writes:
> >Spamassassin does not pretend to be a DKIM (or DMARC) policy engine,
> >so of course it "accepts" weak signatures. It accepts invalid and
> >nonexistent signatures, too.
>
> No, it doesn't. It calls Mail::DKIM to validate the signatures.
Indeed, it validates the sig
On Jun 15, 2014, at 6:02 PM, John Levine wrote:
>>> Your plan, as I understand it, was that verifiers will ignore a
>>> signature that is too weak. One might argue clients that accept weak
>>> signatures are already broken, but in that case there are an awful lot
>>> of broken clients, starting
> > Your plan, as I understand it, was that verifiers will ignore a
> > signature that is too weak. One might argue clients that accept weak
> > signatures are already broken, but in that case there are an awful lot
> > of broken clients, starting with spamassassin. (I just checked.)
>
>Spamassas
Murray S. Kucherawy writes:
> On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull
> wrote:
>
> > > How about a new tag, "shf=" (special header fields). Ignored
> > > by legacy verifiers, as required; otherwise, contains a
> > > colon-separated list of fields that get special handling
John Levine writes:
> >I do not understand this predilection for trying to change the DKIM base
> >engine. It doesn't need it.
>
> Actually, I claim that a version bump is the approach least likely to
> break existing clients.
The point is to avoid breaking the anti-spam *system*. If the
signatures are already broken, but in that case there are an awful lot
of broken clients, starting with spamassassin. (I just checked.)
Out of curiousity, did you try having two signatures in various different
orders and combinations of validity?
No, but from looking at the code, I don't thin
> >I do not understand this predilection for trying to change the DKIM base
> >engine. It doesn't need it.
> Actually, I claim that a version bump is the approach least likely to
> break existing clients.
> >I also don't understand the construct of 'special handling', never mind
> >not liking th
>I do not understand this predilection for trying to change the DKIM base
>engine. It doesn't need it.
Actually, I claim that a version bump is the approach least likely to
break existing clients.
>I also don't understand the construct of 'special handling', never mind
>not liking the idea of it
On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull
wrote:
> > How about a new tag, "shf=" (special header fields). Ignored by legacy
> > verifiers, as required; otherwise, contains a colon-separated list of
> > fields that get special handling by verifiers. "Special handling"
> depends
>
On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker wrote:
>
> What I was suggesting was merely registering a new canonicalization
> algorithm. Legacy DKIM implementations won't understand it. New ones
> (presumably also modified to know about DMARC) will.
>
> The new canonicalization should have ac
On Sun 15/Jun/2014 08:15:18 +0200 Dave Crocker wrote:
> On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote:
>>
>> Somewhat less bogus than a new canonicalization that imparts new
>> semantics; a new tag would, one would think, always impart new semantics
>> in the first place.
>
> I do not understan
12 matches
Mail list logo
