Re: [ietf-dkim] 8bit downgrades
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: Failure rates for message top level encoding type ++ | enctype total bodyfail pct | || | 8bit 31 25 80.6| It is not clear what part of these 8bit failures is due to messages that had been downgraded before signing, and then upgraded before verifying. None. Sorry, by upgraded I mean the same as X-MIME-Autoconverted: from /any encoding/ to 8bit. Thus I take your answer as 20/31. 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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p4BLC7Hl032165 Thanks! It was recently mentioned that Hoffman's MLM inserts a white line on top of the body. Unfortunately, relaxed body canonicalization regards this line as significant. This autoconversion is another, unrelated change that breaks signatures. Now, let me say that my MTA contravenes the SHOULD downgrade precept. I hypothesize that if it wasn't for the extra white line, that is, taking into account only normalization issues, then my signatures would survive while Keith's would not. IOW: the 1st paragraph of Section 5.3 can be *misleading*, as in some cases a signature's survivability gets worsened. What encoding minimizes the chances of conversion is a moving target whose current state we should not purport to know. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 8bitmime advertising, it still doesn't downgrade. I think it just tries to deliver the mail as 8bit, regardless of what the receiving MTA does. I think postfix and sendmail do the same, but I'm not sure. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 no harm. Well, harm will only be done when someone incorrectly punishes a broken signature. They should not do that, 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 shoulder and angel on the other. Because there are known to be paths that break DKIM signatures. And because of this: http://www.apps.ietf.org/rfc/rfc4871.html#sec-6.3 so the damage is actually done by the recipient, not by the downgrading. Well, thats a difference in two reasonable mindsets - a receiver who views faults as part of the strength of securing a technology and a receiver who tolerates faults - accepts everything including one that are direct and indirectly created and passes the buck to end-users. I like to believe there exist a commonality where false positive deterministic methods can be use to detect violations of an authentication and integrity technology. Rhetorically, its all for nothing, why bother looking at how to fix C14H hashing, talk about content formatting downgrades when failure is tolerated and per specification, deliberately ignored? Because success has value, if you have a good reputation as a signer. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent modification in transit, not malice. Do you have numbers to show that broken signatures indicate that messages are malicious, or spam, or otherwise worse than otherwise? 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... Barely. That's 0.1 on a default threshold of 5.0, I think. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 signatures, which is why they should sign on the way out. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] dot-forward, was 8bit downgrades
On 24/May/11 15:22, John Levine wrote: 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 signatures, which is why they should sign on the way out. IMHO, that MLM is only responsible for the inserted whiteline; MIME rewriting is done by MTA/MDA. This rewriting is typical of a class of messages that arrive at an MTA and then undergo a dot-forward or similar mechanism. Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] dot-forward, was 8bit downgrades
Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. If the EAI work is any guide, in the long run everything will be 8 bit, and downgrades will eventually go away. In the shorter term, if the forwarding MTA is inclined to be helpful, it can re-sign on the way out. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] dot-forward, was 8bit downgrades
On 24/May/11 16:14, John R. Levine wrote: Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. If the EAI work is any guide, in the long run everything will be 8 bit, and downgrades will eventually go away. Well, this consideration suggests it would be smoother to remove the recommendation to use transfer encoding now, rather than suddenly turn it into the opposite recommendation in a post-EAI DKIM spec. Anyway, if that is going to take decades, a more robust canonicalization could be worth its while. In the shorter term, if the forwarding MTA is inclined to be helpful, it can re-sign on the way out. SPF experience says MTAs often don't help. Even if they did, the resulting SDID would be neither the author's domain nor the MLM. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 you're wrong, since that violates an explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent modification in transit, not malice. Do you have numbers to show that broken signatures indicate that messages are malicious, or spam, or otherwise worse than otherwise? 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... 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. And also (to get back to John's question) it doesn't mean that [...] a broken signature indicate that messages are malicious, or spam [...]. It just means that in the real world there are systems, even widely used systems, which does by default treat messages with a broken signature not equal as if the message had no signature at all. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Perfect Solution (FDS), was dot-forward, was 8bit downgrades
FDS - Final Delivery Signer The perfect solution is the Mail Delivery Agent (MDA) signing all Incoming Mail for the User!! With a Final Delivery Signer or FDS, it doesn't matter who signed it, can't blame it on the mail man, this truck, or for delivering a torn up letter. John R. Levine wrote: Although it is a minor number of messages, I don't think that ignore-by-design could play a winning role here, because --unlike mailing lists-- there is no way to eventually fix this at the forwarding MTA. If the EAI work is any guide, in the long run everything will be 8 bit, and downgrades will eventually go away. In the shorter term, if the forwarding MTA is inclined to be helpful, it can re-sign on the way out. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 shoulder and angel on the other. Because there are known to be paths that break DKIM signatures. And because of this: http://www.apps.ietf.org/rfc/rfc4871.html#sec-6.3 That doesn't answer the question of why should it be tolerated. Why is the sender who's intention is to get the receiver to trust him tolerate the sender's ignorance of taking the wrong path is not helping him? This is what promotes a very serious problem of relaxation neglect or the Crying Wolf Syndrome. In other words, at what point is your signature ok? and ifs that acceptable why isn't the case 100% of the time? If thats not possible, when whats the difference? Rhetorically, its all for nothing, why bother looking at how to fix C14H hashing, talk about content formatting downgrades when failure is tolerated and per specification, deliberately ignored? Because success has value, if you have a good reputation as a signer. And more usually than not, success can only be determine after you remove all the dirt from it. Can't talk about Pareto without having this being a very fundamental part of the thinking process. The fact is everyone does it - filters information before squeeze out the good. We are trying to ignore that fundamental concept for DKIM - doesn't work very well when its plagued with all sorts of error conditions. We are assuming that receivers will endure high volume abuse and overhead just to look for that limited golden needle in the hay stack of failure. Sorry, its an incorrect mentality that is often exhibited by mail blasters believing that every receiver/MDA will accept all mail with no questions asked. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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. If you switch on 8bitmime advertising, it still doesn't downgrade. I think it just tries to deliver the mail as 8bit, regardless of what the receiving MTA does. I think postfix and sendmail do the same, but I'm not sure. Look, the general rule of thumb is PASSTHRU mail is untouched (except for adding network control/trace header lines). Only upon final delivery begins the idea of any transformations and gateways so you expect under normal circumstances, the payload will be delivered as it was created. That is why, overall, the system has worked over the last two scores of years and allowed us to get to this point. Honestly, if the Internet mail network was that chaotic, I highly doubt I will be doing this work since 1982, nor do I think RFC822/RFC821 would of taking over the existing mail networks at the time, commercial or otherwise. There were at least 4-6 competing mail frameworks existing and in development in the 80s and RFC822/RFC821 won out for many obvious reasons - its flexibility was one key reason, and mainly, it (predecessor, X.400) was government funded and already used in government and academia. This is no different than the early telecommunications days when dealing with half/full duplex issues, client/host LF/CR translations issues or 7bit vs 8 bits file transfer protocols and which worked better over the different available wires, including X.25 networks (i.e. PAD configurations, etc). How do you think ZMODEM got invented? As well as KERMIT? Before then, you has ASCII (7bit), then XMODEM, YMODEM, then ZMODEM and KERMIT, and it *not* ironic, the Postel principle: Be conservative in what you send; be liberal in what you accept. always applied in data communications: Receive HIGH (buffers), Send Low (Buffers) I always used the Bucket Brigade idea to illustrate this; A fireman is passing water in a bigger bucket than the next fireman in the brigade has - you will have flow control issues or spillage. Someone has to slow down. The system works because we have an expectation for an optimal behavior across the board. When one or more node begins to do things differently with an unrealistic unknown expectation for downlinks, its no surprise problems develop for some or many. The only reason we are seeing it now, its because of this DKIM integrity invention highlight the issues. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 advertise 8bitmime either, by default. If you switch on 8bitmime advertising, it still doesn't downgrade. I think it just tries to deliver the mail as 8bit, regardless of what the receiving MTA does. I think postfix and sendmail do the same, but I'm not sure. 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. I'm not sure any of this affects DKIM much, other than Hey, look! Yet another way DKIM signatures might get removed in transit!. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM Scouts, was 8bit downgrades
Steve Atkins wrote: Exim doesn't downgrade. It doesn't advertise 8bitmime either, by default. If you switch on 8bitmime advertising, it still doesn't downgrade. I think it just tries to deliver the mail as 8bit, regardless of what the receiving MTA does. I think postfix and sendmail do the same, but I'm not sure. 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. +1 If everyone (mail transport/mail handlers) just followed the basic mail networking principle of: Thou should not touch passthru mail (except for network traces) We would not be having these side issues today. There are legit reasons for transformations but mainly at the final destination (local routing). The 8BITMIME thing is ideal to tell MUA/MTA (at the Interactive Level) what is not acceptable at the MSA. So if the USER has 8bit enable in his UI, then he can switch it to 7bit compatible format. But its create problems when there is a Mind Guessing game between intermediaries. I'm not sure any of this affects DKIM much, other than Hey, look! Yet another way DKIM signatures might get removed in transit!. The only solution I see for DKIM is to use Target/Path dependency methods, but in principle, intermediaries need to refrain from thinking they know better for downlinks. hmmm, perhaps DKIM Scouts :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
On 5/24/11 12:47 , Hector Santos hsan...@isdg.net wrote: Steve Atkins wrote: Exim doesn't downgrade. It doesn't advertise 8bitmime either, by default. If you switch on 8bitmime advertising, it still doesn't downgrade. I think it just tries to deliver the mail as 8bit, regardless of what the receiving MTA does. I think postfix and sendmail do the same, but I'm not sure. 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. +1 If everyone (mail transport/mail handlers) just followed the basic mail networking principle of: Thou should not touch passthru mail (except for network traces) Are there the same issues with PGP or S/Mime email? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same value. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
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 that's what EAI is going to do, too. Maybe yes, maybe no. That actally means definitely yes, for some scenarios. The maybe no means that it might not occur for some others. One possibility is that the two paths are distinguished by near-term vs. long-term, assuming one believes that 'near-term' is a useful construct when projecting Internet-scale transitions of infrastructure service... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Franck Martin wrote: Steve Atkins mentioned: This (entirely RFC valid yet completely broken) behaviour has bitten me a couple of times. Hector followed up: +1 If everyone (mail transport/mail handlers) just followed the basic mail networking principle of: Thou should not touch passthru mail (except for network traces) Are there the same issues with PGP or S/Mime email? RFC3851 (S/MIME) states this under the security section: Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it. IMO, with the known issues in the wild related to using MIME parts, I would say yes. Since our MSA/MDA/MTA does not tamper with passthru mail and since we never heard of a complaint, it will suggest it didn't cause problems for any customer either. My general point is based on painful experiences learned with multiple different mail networking software (old and new) and the common and basic long traditional rule of thumb was to refrain from screwing around with passthru mail and when followed, things generally worked better, there were less issues, less surprises and future things would basically fit right in. With new needs such as EAI (internalization) and DKIM (authentication), it is highlighting the cases where certain methods in the network were not ideal. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Interestingly enough, outlook tells me this message has been tampered with, but not sure why... On 5/24/11 15:35 , John R. Levine jo...@iecc.com wrote: Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same value. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
On 5/23/2011 10:26 AM, Murray S. Kucherawy wrote: 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 downgrade was done for it to work. That's a pretty high requirement for interoperability (i.e., it's pretty error-prone), so it requires a specification and it would need to be consistent with the MIME RFCs. So assuming it's a useful endeavour, it seems to me there's a lot of work to be done here. Let's make it be the right work. To make a canonicalization algorithm that is more robust -- such as having it based on canonical forms of data, independent of encoding -- makes some sense. Trying to create the ability to reverse changes strikes me as far to complex and fragile to be reasonable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Cry Wolf! Thunderbird says Not Digitally signed :) Franck Martin wrote: Interestingly enough, outlook tells me this message has been tampered with, but not sure why... On 5/24/11 15:35 , John R. Levine jo...@iecc.com wrote: Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same value. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
Interestingly enough, outlook tells me this message has been tampered with, but not sure why... Probably doesn't have the Comodo validation certificate. I took the copy of my message that came back from the mailing list, ran it through some rather violent transformations (mail to usenet and back) and the S/MIME signature still is OK. R's, John On 5/24/11 15:35 , John R. Levine jo...@iecc.com wrote: Are there the same issues with PGP or S/Mime email? Generally no. They're a group of MIME parts that shouldn't need to be recoded, or even if they are, will decode to the same value. smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
It tells me signing and encryption certificates are valid and even their root certificates are valid... On 5/24/11 18:13 , John R. Levine jo...@iecc.com wrote: Interestingly enough, outlook tells me this message has been tampered with, but not sure why... Probably doesn't have the Comodo validation certificate. I took the copy of my message that came back from the mailing list, ran it through some rather violent transformations (mail to usenet and back) and the S/MIME signature still is OK. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
It tells me signing and encryption certificates are valid and even their root certificates are valid... Well, something's wrong with it. I checked the signature in Alpine, Thunderbird, and Evolution, and they all agree it's fine. On 5/24/11 18:13 , John R. Levine jo...@iecc.com wrote: Interestingly enough, outlook tells me this message has been tampered with, but not sure why... Probably doesn't have the Comodo validation certificate. I took the copy of my message that came back from the mailing list, ran it through some rather violent transformations (mail to usenet and back) and the S/MIME signature still is OK. R's, John Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
On 2011-05-24 11:44 PM, John R. Levine wrote: It tells me signing and encryption certificates are valid and even their root certificates are valid... Well, something's wrong with it. I checked the signature in Alpine, Thunderbird, and Evolution, and they all agree it's fine. Not in Thunderbird V2.0, V3.1. It knows nothings about your signature - Click View | Message Security Info and it says: Message Has No Digital Signature Message Not Encrypted What version of TBird did you use? -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
