Alessandro, with the undotting leading dot fix, I went back and adding
code to adjust for this by undotting it in the C14N code and what a
major difference compared to the failed rate listed before:
Failure rates for level encoding type (OLD)
On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
...
When I remove the domains I know, the rest is pretty much spam.
...
Isn't that pretty generally true, DKIM or no DKIM.
Scott K
___
NOTE WELL: This list operates according to
Scott Kitterman wrote:
On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
...
When I remove the domains I know, the rest is pretty much spam.
...
Isn't that pretty generally true, DKIM or no DKIM.
Sure, in general I would agree with that and most of it are single
shot deals.
On 23/May/11 22:04, Hector Santos wrote:
Alessandro Vesely wrote:
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
On 23 May 2011, at 23:10, Franck Martin wrote:
There is an interesting post today on
http://chilli.nosignal.org/mailman/listinfo/mailop about exim and 8bit
It seems they will stop to downgrade.
Exim doesn't downgrade. It doesn't advertise 8bitmime either, by default. If
you switch on
On 23 May 2011, at 17:10, Hector Santos wrote:
Ian Eiloart wrote:
On 23 May 2011, at 15:19, Hector Santos wrote:
But why skip? Usually the message won't be downgraded. And even if they
are, usually a broken signature will cause no harm.
Thats the problem - define usually and also define
On 23 May 2011, at 23:09, Rolf E. Sonneveld wrote:
On 5/23/11 6:35 PM, John R. Levine wrote:
In the real world signature reliability matters. If a domain signs mail
as a rule then an absent or broken signature will be treated as
suspicious.
I hope you're wrong, since that violates an
Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP
list with a 3rd party signature and Hoffman's list server (non-dkim
aware) doing this:
Oh, it's a mailing list. Why are we even having this discussion? We all
know there's a million ways that lists break incoming
On 5/24/11 1:30 PM, Ian Eiloart wrote:
On 23 May 2011, at 23:09, Rolf E. Sonneveld wrote:
On 5/23/11 6:35 PM, John R. Levine wrote:
In the real world signature reliability matters. If a domain signs mail
as a rule then an absent or broken signature will be treated as
suspicious.
I hope
Barely. That's 0.1 on a default threshold of 5.0, I think.
Granted, it's a small penalty, yet it's a penalty.
I'll ask the spamassassin developers where the number came from. SM's
suggestion that it has to be non-zero to exercise the code may be it.
Regards,
John Levine, jo...@iecc.com,
Ian Eiloart wrote:
On 23 May 2011, at 17:10, Hector Santos wrote:
Rhetorically, why not? Put another way, why should a receiver
tolerate failure, or better, why should DKIM itself - the technology
- tolerate failure? Sounds like DKIM has some inner soul turmoils - a
devil on one
Ian Eiloart wrote:
On 23 May 2011, at 23:10, Franck Martin wrote:
There is an interesting post today on
http://chilli.nosignal.org/mailman/listinfo/mailop about exim and 8bit
It seems they will stop to downgrade.
Exim doesn't downgrade. It doesn't advertise 8bitmime either, by default.
On May 24, 2011, at 3:55 AM, Ian Eiloart wrote:
On 23 May 2011, at 23:10, Franck Martin wrote:
There is an interesting post today on
http://chilli.nosignal.org/mailman/listinfo/mailop about exim and 8bit
It seems they will stop to downgrade.
Exim doesn't downgrade. It doesn't
Exchange advertises 8bit and then bounces the mail if it tries to forward it
to a server that doesn't advertise 8bit.
This (entirely RFC valid yet completely broken) behaviour has bitten me a
couple of times.
Better get used to it, since that's what EAI is going to do, too.
Regards,
John
On 5/24/2011 3:34 PM, John R. Levine wrote:
Exchange advertises 8bit and then bounces the mail if it tries to forward it
to a server that doesn't advertise 8bit.
This (entirely RFC valid yet completely broken) behaviour has bitten me a
couple of times.
Better get used to it, since
On 19 May 2011, at 22:53, Pete Resnick wrote:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not
mean vitally important and SHOULD does not mean really really important,
but less important than MUST. MUST means you have to do this or you're
not going to
On 20 May 2011, at 05:24, Hector Santos wrote:
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add a rule to a DKIM signing
component:
If mail is 8bit then
Ian Eiloart wrote:
On 20 May 2011, at 05:24, Hector Santos wrote:
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add a rule to a DKIM signing
component:
If mail
On 23 May 2011, at 15:19, Hector Santos wrote:
Ian Eiloart wrote:
On 20 May 2011, at 05:24, Hector Santos wrote:
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top level encoding type
Ian Eiloart i...@sussex.ac.uk wrote:
On 23 May 2011, at 15:19, Hector Santos wrote: Ian Eiloart wrote:
On 20 May 2011, at 05:24, Hector Santos wrote: In this case, if
this is enforced with a MUST, for a system that is not 8BITMIME
ready but is adding DKIM signing support, to remain
Ian Eiloart wrote:
On 23 May 2011, at 15:19, Hector Santos wrote:
But why skip? Usually the message won't be downgraded. And even if they
are, usually a broken signature will cause no harm.
Thats the problem - define usually and also define no harm.
Well, harm will only be done when
In the real world signature reliability matters. If a domain signs mail
as a rule then an absent or broken signature will be treated as
suspicious.
I hope you're wrong, since that violates an explicit SHOULD in RFC 4871,
and in my experience, most broken signatures are due to innocent
On Monday, May 23, 2011 12:35:02 PM John R. Levine wrote:
In the real world signature reliability matters. If a domain signs mail
as a rule then an absent or broken signature will be treated as
suspicious.
I hope you're wrong, since that violates an explicit SHOULD in RFC 4871,
and in my
Alessandro Vesely wrote:
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top
There is an interesting post today on
http://chilli.nosignal.org/mailman/listinfo/mailop about exim and 8bit
It seems they will stop to downgrade.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 5/23/11 6:35 PM, John R. Levine wrote:
In the real world signature reliability matters. If a domain signs mail
as a rule then an absent or broken signature will be treated as
suspicious.
I hope you're wrong, since that violates an explicit SHOULD in RFC 4871,
and in my experience, most
Hi Rolf,
At 15:09 23-05-2011, Rolf E. Sonneveld wrote:
SpamAssassin assigns a score of something like 0.1 for a message
carrying a DKIM signature and compensates that with -0.1 if the
signature can be verified to be correct. Effectively, this means SA is
penalizing broken signatures...
Not
Murray S. Kucherawy wrote:
-Original Message-
What this tells me is: Ignoring ADSP, if a domain sometimes signs its
mail, then mail from it (signed or not) is usually not spam. From this I
suspect we could conclude that a missing signature doesn't tell us much
of anything.
And
On Thu, 19 May 2011, Murray S. Kucherawy wrote:
The presented argument, which comes from an IETF outsider involved with
MTA development, is whether or not that SHOULD is worthy of a MUST because
failing to do it in the vast majority of cases will result in a downgrade
somewhere on the path
On 5/19/2011 10:50 AM, Murray S. Kucherawy wrote:
Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in RFC4871
Section 5.3, rather than a MUST?
To concur with one of the lines of explanation that has been offered:
It is generally a good idea to refrain from mandating
Dave CROCKER wrote:
On 5/19/2011 2:53 PM, Pete Resnick wrote:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not
mean
vitally important and SHOULD does not mean really really important, but
less important than MUST. MUST means you have to do this or you're not
going
Michael Deutschmann wrote:
On Thu, 19 May 2011, Murray S. Kucherawy wrote:
The presented argument, which comes from an IETF outsider involved with
MTA development, is whether or not that SHOULD is worthy of a MUST because
failing to do it in the vast majority of cases will result in a
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Sunday, May 22, 2011 10:43 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 8bit downgrades
Please refrain from passing the buck to the WG
Murray S. Kucherawy wrote:
Hector Santos followed up Crocker'ss passing of the buck:
Please refrain from passing the buck to the WG. The document editors
are:
D. Crocker (editor)
Tony Hansen (editor)
M. Kucherawy (editor)
If the WG was technically incapable as you are
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top level encoding type
On 20/May/11 15:33, John Levine wrote:
of what paths are likely to downcode a message and what paths aren't,
so I would prefer not to purport to offer advice about it.
Actually, I kinda prefer to leave it in. It seems to me assume a
downgrade will happen unless you're certain it won't, and
On Friday, May 20, 2011 01:18:39 AM Murray S. Kucherawy wrote:
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Thursday, May 19, 2011 7:20 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] 8bit downgrades
I think Pete's
On May 19, 2011, at 4:53 PM, Pete Resnick wrote:
In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not
mean vitally important and SHOULD does not mean really really important,
but less important than MUST. MUST means you have to do this or you're
not going to
On 5/19/2011 7:34 PM, Michael Thomas wrote:
Since dev
managers literally looks at MUST's and SHOULD and ignore
MAY's to determine what gets implemented, this is not
quite as academic.
That's a rather significant assessment. It means that all of the Internet
specifications done for the
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871
Section 5.3, rather than a MUST? The likelihood of breakage is so high when
sending 8-bit data that DKIM almost becomes pointless without the upgrade.
Not advocating for this to be changed in -bis (yet), but
On 05/19/2011 10:50 AM, Murray S. Kucherawy wrote:
Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is
so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
Not
On Thursday, May 19, 2011 02:16:47 PM Wietse Venema wrote:
We could pretend that the future is 8-bit clean, and hope the
problem will go away eventually.
I have a vague recollection that this is the reason it's SHOULD vice MUST.
Scott K
___
NOTE
On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage
is so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
Not
On 05/19/2011 02:53 PM, Pete Resnick wrote:
In this case, the spec says that you MUST downgrade prior to signing
*unless you know that the end-to-end path is 8-bit clean and will not
downgrade later*. That's what SHOULD downgrade means. If there is an
implementation that doesn't downgrade
Pete Resnick wrote:
On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage
is so high when sending 8-bit data that DKIM almost becomes pointless
without the
On 5/19/11 6:09 PM, Michael Thomas wrote:
We send things that get forwarded through all kinds of manglers,
8bit manglers just being one variety. In the abstract, you can never know
as a signer that a path is clean... it can always be forwarded. So by your
argument it should be a MUST since you
On 05/19/2011 07:11 PM, Pete Resnick wrote:
On 5/19/11 6:09 PM, Michael Thomas wrote:
We send things that get forwarded through all kinds of manglers,
8bit manglers just being one variety. In the abstract, you can never
know
as a signer that a path is clean... it can always be forwarded. So
On 05/19/2011 07:20 PM, John Levine wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is
so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
I think
On 5/19/11 6:52 PM, Hector Santos wrote:
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended on a SHOULD operation as a
100%? That is extreme.
I hope you are not stating giving two interfacing points, one end will
read a SHOULD as a MUST? I hope not. One end point expecting a MUST
behavior from a SHOULD recommendation is seriously broken especially
if it doesn't get what it expects. That is not a matter of
Pete Resnick wrote:
On 5/19/11 6:52 PM, Hector Santos wrote:
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended on a
On 5/20/11 11:09 , Michael Thomas m...@mtcc.com wrote:
On 05/19/2011 02:53 PM, Pete Resnick wrote:
In this case, the spec says that you MUST downgrade prior to signing
In reality, I haven't ever seen a failure that was attributable to 8bit
mangling, and I've probably seen sample sizes as big
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Thursday, May 19, 2011 7:20 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] 8bit downgrades
I think Pete's analysis is correct, but my advice would be to take
it out altogether. We
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Thursday, May 19, 2011 8:38 PM
To: Pete Resnick
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] 8bit downgrades
100%? That is extreme
55 matches
Mail list logo
