Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
On 26 May 2011, at 14:40, John R. Levine wrote: So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. My client found the signature, otherwise it would not have commented on its validity. It just wasn't able to verify it. Hmmn. How does it like the copy of this message sent to you directly? The signature was definitely good on the way out. That looks fine. I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). Actually, I think the long term solution is for people to stop pretending there is a problem. Can you describe the operational problems you're experiencing here? Broken signatures is a fact, not a problem. Mailing lists have worked quite well for 40 years with no signatures at all, making all sorts of random changes to the mail, so it has to be something more than that. I didn't posit this as a problem. Others did. I jumped in at the point that you said s/mime was already a solution, with a message that proved otherwise. I also said that - if there's a problem with packages arriving broken - then the solution lies in making the paths smoother rather than increasingly fancy suspension. Also, if you're suggesting changes to list software, please explain why they would have greater benefits than the obvious and simple one to have lists add their own signature on the way out. Well, I guess that there must be use cases where one would want to verify that the sender's message was unaltered. I accept that they're less common than with non-list mail, though. 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 -- 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] DKIM Scouts, was 8bit downgrades
On 26 May 2011, at 14:40, John R. Levine wrote: So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. My client found the signature, otherwise it would not have commented on its validity. It just wasn't able to verify it. Hmmn. How does it like the copy of this message sent to you directly? The signature was definitely good on the way out. I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). Actually, I think the long term solution is for people to stop pretending there is a problem. Can you describe the operational problems you're experiencing here? Broken signatures is a fact, not a problem. Mailing lists have worked quite well for 40 years with no signatures at all, making all sorts of random changes to the mail, so it has to be something more than that. Also, if you're suggesting changes to list software, please explain why they would have greater benefits than the obvious and simple one to have lists add their own signature on the way out. Oh, and actually, I'm not proposing changes to list software. The software that I use for lists is quite capable of passing unaltered bodies and subject lines. However, list operators don't like to do that because they have no other way of adding meta-data in a way that's visible to users. What I'm suggesting is that MUAs should be modified to expose List-* headers in a way that's useful to end users. At that point, most of the motivation for mucking around with messages would disappear. Also, done well, the utility of the meta-data could be improved. Increased safe passage of DKIM signatures might be regarded as a positive benefit with respect to motivating DKIM deployment. -- 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] DKIM Scouts, was 8bit downgrades
On 25 May 2011, at 21:06, 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. I went back and looked in more detail. The problem appears to be that this mailing list wraps the signed body in a MIME multipart/mixed section including both the signed message and the unsigned footer. Some MUAs look inside the mixed and see the signature, some don't. For the ones that do, I haven't checked to see how if at all they distinguish the signed part from the unsigned when they show you the message (shades of all the l= arguments.) So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. My client found the signature, otherwise it would not have commented on its validity. It just wasn't able to verify it. Why would anyone think that the situation with DKIM would be any different? I don't know. I had the impression that you were claiming that S/MIME would work better than DKIM here. Perhaps it does, but it still doesn't seem to be bullet proof. I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). My guess is that if the top five MUAs and the top ten webmail services were all to make good use of list-unsubscribe and list-id headers (and perhaps others), then many list operators would not feel the need to mess around with message bodies and subject lines. -- 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] DKIM Scouts, was 8bit downgrades
Ian Eiloart wrote: I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). This is the sort of improved Mail Integration information that should be in a MLM document. I increasingly believe we (the mail industry) needs a Mail Integration document similar to the RFC1123 document (I called the Bible) that help put it all together for online hosting systems with integrated Telnet, FTP and SMTP services. It was because of RFC1123 that helped RFC2822/RFC2821 get done. In fact RFC22821 updated RFC1123. We need a new document that deals all the new modern Mail Integration needs, and it can cover most and not exclusively: - Traditional Email - NNTP - POP3 - IMAP - Web Mail - Mobile Mail - List Servers, Mailing List - MUA (offline and online) - SUBMIT (PORT 587) - Legacy Mail Issues - The New Rules (i.e. PTR requirements, DISCARDING, etc) - DKIM - EAI, IDN etc. One of the things that I got out of RFC1123 was the Hosting Requirements under one bird eyes view. This new Mail Integration Hosting Requirements document would do a similar thing to get the consistent and persistent expected behavior in the new modern mail network. My guess is that if the top five MUAs and the top ten webmail services were all to make good use of list-unsubscribe and list-id headers (and perhaps others), then many list operators would not feel the need to mess around with message bodies and subject lines. In principle, passthru mail should not be tampered, but MLM list mail are the industry accepted exception to this non-tampering tradition and today (at least in the USA), it is CAN-SPAM legal requirement to have a viewable OPT-OUT text shown to the user to satisfy the CAN-SPAM capitalistic legal right provided to the VENDOR to due business with users. Nonetheless, today, the list operators already has the option to not change the body, but I can see if and when it was a BCP that end users will see unsubscribe information by their MUA based on the meta data, then list software developers may not make it a default to set text footers. From my (developer, vendor) point of view, we need to cater to all markets. So for example, these are our defaults when an list operator prepares a new list (showing ones that could alter the mail) [X] Add [List-Name] subject tag [X] Allow Attachments [_] Strip HMTL Content [X] Use List Address for Reply-To [X] Keep Original To: Addresses [_] Add Body Header [X] Add Body Footer [X] Add LIST-* headers I can see a change where we offer an option for a new mindset group of list operator thinking with Keep vs Change feature: (_) Keep Original Submission Integrity [X] Add LIST-* headers [_] Use List Address for Reply-To (o) Mail Submission Change Options [X] Add [List-Name] subject tag [X] Allow Attachments [_] Strip HMTL Content [X] Use List Address for Reply-To [X] Keep Original To: Addresses [_] Add Body Header [X] Add Body Footer [X] Add LIST-* headers But remember, when there is a need to change it also comes with the idea did we do it right, the need to justify the change, the whys and was all the key design issues taken into account. Just consider a change request where we will now need to double (Keep vs Change) the internal name space for options. In other words, from my point of view, if we are doing this for DKIM, then the DKIM spectrum of design requirements are considered as well. I think, in this case, that means honoring originating signed submissions and if thats the case, then in my engineering opinion, all top level DKIM Mail Integration design aspects are considered as well, including honoring ADSP: [X] DKIM options [X] Exclude ADSP restricted domains membership [X] Reject ADSP restricted domain submissions [X] Validate signatures [X] Add Authentication-Results [_] Sign Message [Click for Signer Options] [X] Strip Original Signatures In other words, when the DKIM (re)signing option is checked: [X] Sign Message [Click for Signer Options] then the exclusively mutual (radio) option is automatically unchecked.: (_) Keep Original Submission Integrity because it doesn't matter any more when the MLM is always (re)signing. Anyway, IMV, what people need is insights and let them make their own decisions based on their own needs, but overall, the same outcome in all cases should be the intended goal. -- 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 26 May 2011, at 12:46, Hector Santos wrote: In principle, passthru mail should not be tampered, but MLM list mail are the industry accepted exception to this non-tampering tradition and today (at least in the USA), it is CAN-SPAM legal requirement to have a viewable OPT-OUT text shown to the user to satisfy the CAN-SPAM capitalistic legal right provided to the VENDOR to due business with users. Yes, and are similar requirements across the European Union. In the UK, the phrase is easy to use. That's not the case if the user interface doesn't obviously expose it. Still, we're straying off topic here, I guess. -- 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] DKIM Scouts, was 8bit downgrades
So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. My client found the signature, otherwise it would not have commented on its validity. It just wasn't able to verify it. Hmmn. How does it like the copy of this message sent to you directly? The signature was definitely good on the way out. I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). Actually, I think the long term solution is for people to stop pretending there is a problem. Can you describe the operational problems you're experiencing here? Broken signatures is a fact, not a problem. Mailing lists have worked quite well for 40 years with no signatures at all, making all sorts of random changes to the mail, so it has to be something more than that. Also, if you're suggesting changes to list software, please explain why they would have greater benefits than the obvious and simple one to have lists add their own signature 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 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
Ian Eiloart wrote: On 26 May 2011, at 12:46, Hector Santos wrote: In principle, passthru mail should not be tampered, but MLM list mail are the industry accepted exception to this non-tampering tradition and today (at least in the USA), it is CAN-SPAM legal requirement to have a viewable OPT-OUT text shown to the user to satisfy the CAN-SPAM capitalistic legal right provided to the VENDOR to due business with users. Yes, and are similar requirements across the European Union. In the UK, the phrase is easy to use. That's not the case if the user interface doesn't obviously expose it. Still, we're straying off topic here, I guess. It was a background side point, but nevertheless an important point to keep in mind when a suggestion is made list operators is expected to move towards not changing list submissions during the distribution. Whether via a footer or via a meta-data header intelligent modern mail viewers make use of, it needs to be shown and this is what I have to consider. My take (as a list software developer) is that if these smart mail viewer are expected to exist, then we did our job by providing guidance to domain signers sending mail to a list: - use the l= tag - not hash RFC5322.Subject (not actually written in spec) That way the list server can continue two to three things: - Add the LIST-* headers - Add the text footer - Add the Subject tag [LIST-NAME] and the smart MUA now can: - Use the meta-data (List-Unsubscribe), and - not show the text beyond l= body length. So it appears we have all the ingredients in place actually. But for the legacy MUA, the visual footer would satisfy the business requirements. Note: I am just describing what I have to consider for our List Server product, I am not thinking as a List Operator only. -- 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
John R. Levine wrote: I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). Actually, I think the long term solution is for people to stop pretending there is a problem. Can you describe the operational problems you're experiencing here? eh, non-DKIM intermediaries? Broken signatures is a fact, not a problem. Sure it is. You are saying there is a SOLUTION - resign it. Mailing lists have worked quite well for 40 years with no signatures at all, making all sorts of random changes to the mail, so it has to be something more than that. But it doesn't have 40 years of dealing with DKIM or authentication issues. DKIM was around 40 years ago, Mailing List software would be a whole lot different today. Also, if you're suggesting changes to list software, please explain why they would have greater benefits than the obvious and simple one to have lists add their own signature on the way out. Not all list operators are agreeing with your general always resign Pottery Theorem model and/or take over the responsibility of the originating domain, copyright holder author mail. The Broken Signature Resign solution is only one solution. It doesn't cover all the problems for one reason only - you can't assume everyone is going to resign yet alone add DKIM to their software. -- 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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Thursday, May 26, 2011 3:08 AM To: John R. Levine Cc: DKIM List Subject: Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades I think the long term solution would be for mailing list software to stop mucking around with the message body, and for MUAs to work better at exposing meta data added by lists (like the list-unsubscribe header). The MLM document does say that such a thing is preferable, but not expected to become a reality any time soon. So really, we've already been down this road. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades
On 25 May 2011, at 02:13, John R. Levine wrote: Interestingly enough, outlook tells me this message has been tampered with, but not sure why... Probably doesn't have the Comodo validation certificate. Maybe, but my Mac does, and it complains. As does a Thunderbird client and an Outlook client. That's three different setups that are complaining about your signature now. Whether they're right or wrong is largely irrelevant. The fact is that S/MIME doesn't seem to be bullet proof. 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. ___ 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] 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. I went back and looked in more detail. The problem appears to be that this mailing list wraps the signed body in a MIME multipart/mixed section including both the signed message and the unsigned footer. Some MUAs look inside the mixed and see the signature, some don't. For the ones that do, I haven't checked to see how if at all they distinguish the signed part from the unsigned when they show you the message (shades of all the l= arguments.) So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. Why would anyone think that the situation with DKIM would be any different? 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] DKIM Scouts, was 8bit downgrades
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. I went back and looked in more detail. The problem appears to be that this mailing list wraps the signed body in a MIME multipart/mixed section including both the signed message and the unsigned footer. Some MUAs look inside the mixed and see the signature, some don't. For the ones that do, I haven't checked to see how if at all they distinguish the signed part from the unsigned when they show you the message (shades of all the l= arguments.) So this tells me that existing mail software doesn't try very hard to recover signatures from modified messages, even for simple changes that don't need any guessing or heuristics to undo. Why would anyone think that the situation with DKIM would be any different? I think you were telling people for a while now to use it for some reason. Anyway, I don't think the problem is as you state. From what I see, I think the issue here is no MIME Application Type association for the application and extension your message was made. Your email provides this MIME info: Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s Software that offer auto launching (generally with user permission necessary) using MIME Application association, can either have its own table or depends on the OS to provide it. For example, under Windows, you can use a console window using the ASSOC command to get the file type for the extension: ASSOC .p7s and it returns .p7s=P7SFile then you use the FTYPE command to see what application is responsible to handle this file type. FTYPE P7SFile and it returns: p7sfile=rundll32.exe cryptext.dll,CryptExtOpenPKCS7 %1 So if the email has an attachment file name/extension smime.p7s, then it should allow the user (with permission) to load it by running the above rundll32.exe process passing the rest of the line as parameters and substituting %1 with the local temp storage FQFN for smime.p7s Now, under TBIRD, it apparently is independent of the built-in Windows MIME association table in the registry. So one would think that Outlook would not have a problem and indeed it doesn't; it displays a seal icon save button for the SMIME.P7S attachment file when viewing the message under OE. Under TBIRD, you can click TOOLS | OPTIONS and under the Attachments properties tab, you will see the View Edit Associations button. For me, it is empty list - no MIME associations so shown as a file name PART 1.2 Now why didn't it atleast show SMIME.P7S as a file attachment? You did have: Content-Disposition: attachment; filename=smime.p7s You should check bugzilla or asks the TBIRD folks why it doesn't at least show the actual file name as the attachment because even if TBIRD doesn't have its own table, when the user tries to save it, Windows will most likely make the shell association. BTW, under OE, while it does show the SMIME.P7S icon attachment, the message display is blank. That may be related to what you are talking about. In any case, its all fubar. -- 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] 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] 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] 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
