On Mon, 23 May 2011 03:50:06 +0100, Hector Santos hsan...@isdg.net wrote:
Case in point. Right now, I am looking at a gmail.com which I am
pretty sure was not in Base64 MIME. However, it was submitted to IETF
DISCUSS group and its showing up as base64 MIME. I don't know if the
list did it
On 19 May 2011, at 18:19, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Ian Eiloart
Sent: Thursday, May 19, 2011 3:21 AM
To: John Levine
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim]
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
Could you get the effect of this by including the
Content-Transfer-Encoding header in the 'h=' and doing some fancy checks
involving the 'bh=' (to detect whether it was the body or the headers or
both that were broken)?
No, of course not. The bh= and h= are just hashes, so all they can
Charles Lindsey wrote:
On Mon, 23 May 2011 03:50:06 +0100, Hector Santos hsan...@isdg.net wrote:
It would of been nice to have some DKIM-Signature flag that might
indicate the Content-Transfer-Encoding, i.e.:
et=base64 --- copy of the top level Content-Transfer-Encoding
Could you
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 wrote:
Sorry, Pareto Efficiency (an economics concept) isn't something that
I was familiar with. I was referring to an analysis Pareto charts
(a quality engineering tool). Same guy, different concept.
Actually, different guys (sciences, engineering disciplines), same
concept. :)
On 23 May 2011, at 16:00, Hector Santos wrote:
Ian Eiloart wrote:
Sorry, Pareto Efficiency (an economics concept) isn't something that I was
familiar with. I was referring to an analysis Pareto charts (a quality
engineering tool). Same guy, different concept.
Actually, different guys
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
If one were to encode somehow an extension indication that this content was
subjected to 8-to-7 downgrade as a hint that a verifier should do the
reverse before verifying, the verifier would have to manage to undo the
downgrade in precisely, i.e. byte-for-byte, the same manner that the
On 5/22/2011 10:43 AM, John R. Levine wrote:
VBR queries are about an actor, not a message.
Certs can be coupled to a particular message -- this was an interesting
semantic distinction about Goodmail's certification scheme -- although I
believe that typically they, too, are only scoped to
On 05/23/2011 11:17 AM, Dave CROCKER wrote:
As an impressive example of even deeper misunderstanding:
More of CROCKER's famed civility.
On 5/22/2011 10:49 AM, Michael Thomas wrote:
But this is exactly what DKIM is. You prove yourself fsvo prove
to the registrar who certifies you
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
On 23 May 2011, John R. Levine wrote:
Seems to me that if someone were that desperate to get a signed message
through a downgraded path, they should wrap the whole thing in a
base64 encoded message/rfc822 mime part and send it that way.
That's explicitly forbidden by RFC 2046. Some idiot lazy
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
At 11:03 23-05-2011, Dave CROCKER wrote:
Then you are using criteria that go beyond the requirements of a BCP.
From RFC 2026:
5. BEST CURRENT PRACTICE (BCP) RFCs
The BCP subseries of the RFC series is designed to be a way to
standardize practices and the results of
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
Dave CROCKER wrote:
? In Section 5.8:
DKIM-aware authoring MLMs MUST sign the mail they send according to
the regular signing guidelines given in [DKIM].
One concern is that having an MLM apply its signature to unsigned
mail might cause some verifiers or receivers to interpret
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
26 matches
Mail list logo
