Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
--On 9 August 2010 16:37:38 -0700 Dave CROCKER d...@dcrocker.net wrote: On 8/9/2010 3:57 PM, John Levine wrote: DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is delayed after the crlf.crlf, and that's not supposed to happen. Why not? My MTA usually does a whole spamassassin run between the end of data and the ack. It adds maybe five seconds, at a point where 5321 says the timeout should be ten minutes. It's considered bad form to hold up senders that way. For one thing, it adds non-determinacy at a point which can produce retransmissions. Yep. My experience is that MS Outlook MUA does this, but I think I've only ever seen one incident where an MTA did so. My belief is that best practice is to queue password authenticated email submissions, and bounce later if necessary (but not to bounce to a non-local domain). Unauthenticated mail should be scanned at SMTP time, and rejected at SMTP time if necessary. Mail that's authenticated by DKIM, could, perhaps, be treated as bounceable. However, I think one might only want to apply that rule when there's some clear relationship between the RETURN PATH address and the signing domain. For example, if the return path address matches the From header address, and the From header is DKIM signed. I'm sure you're not the only one doing it, but as I recall, the standards to no institutionalize anything that forces it. d/ -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
--On 10 August 2010 06:59:42 +0100 Graham Murray gra...@gmurray.org.uk wrote: Dave CROCKER d...@dcrocker.net writes: DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is delayed after the crlf.crlf, and that's not supposed to happen. Anyone using the opendkim sendmail/postfix milter will be doing this checking during the SMTP session. Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation during the SMTP session. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 08/17/2010 04:08 AM, Ian Eiloart wrote: --On 10 August 2010 06:59:42 +0100 Graham Murraygra...@gmurray.org.uk wrote: Dave CROCKERd...@dcrocker.net writes: DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is delayed after the crlf.crlf, and that's not supposed to happen. Anyone using the opendkim sendmail/postfix milter will be doing this checking during the SMTP session. Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation during the SMTP session. I'm not positive, but I believe that Ironport does it that way too. Is there anybody who *doesn't* do DNS lookups at SMTP time these days? That's all DKIM really amounts to, and the entire mail infrastructure would seize if we weren't (cf, blacklists). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : RFC4871 Implementation Report Author(s) : M. Kucherawy Filename: draft-ietf-dkim-implementation-report-00.txt Pages : 13 Date: 2010-08-17 This document contains an implementation report for the IESG covering DKIM in support of the advancement of that specification along the Standards Track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-00.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
On Monday 16 August 2010 20:25:16 Charles Lindsey wrote: On Sun, 15 Aug 2010 04:50:13 +0100, Daniel Black daniel.s...@internode.on.net wrote: If users are to place value in From headers as MUAs display and ADSP tries to enforce then manguling From headers is adds complexity to the interpretion of the header field by to the end user. If the original was From: Joe Doe j...@discardable.example and a recipient sees it as From: Joe Doe joe%discardable.exam...@mlm.example then he will still have a pretty clear idea that it originated from Joe Doe, and may even be able to correctly guess Joe's original email address even if he is unfamiliar with the percent-hack. I'm trying to get the same goal by recommending adding some non-artisicly specified form of a list: mlm.example display so its more evident to the user without percentage hacks. Current users are left out but a clearer interpration in the future is the tradeoff in values I'm making. ANNEX A - MUA Considerations A MUA could implement the following features to reduce the need for signature modifications: * Display of the List-ID header field is used to be displayed beside where a subject header field is displayed. * functionality to create a filter based on based on the List-ID header field. I agree it would be a Good Thing if MUAs routinely displayed some of the List-* headers as a default feature. But you seem to be suggesting that an MUA should be setup to accept mesages with a List-Id plus a valid signature from the MLM, even from a discardable origin. good point. Should verifiers and MUAs do this check? I was hoping MUAs would only need to parse Authenticated-Results rather than full DKIM/ADSP so a MUA doing ADSP lookups would enter into an offline/online MUA discussions as Hector mentioned and talks about the validity period of a DNS records. Ignoring the fact that such emails may be already discarded by some boundary agent, that is still an open invitation to every Phisher to add a List-ID from some bogus list to every message he sends, and to add a valid signature from that bogus list (and perhaps even a deliberately invalid signature from the phished domain). Somehow, MUAs need to be aware of which lists the user is subscribed to if they are going to do that sort of thing. Good idea. I'll try to word that in for the next rewrite. Alternately a MUA maintains good/bad/indifferent third party signature lists and varies the display for this. Thanks for the review Charles. Daniel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
I'm trying to get the same goal by recommending adding some non-artisicly specified form of a list: mlm.example display so its more evident to the user without percentage hacks. I must be missing something. What does this have to do with DKIM? If this were important, why don't MUAs look for the already standard List-ID header, regardless of whether it's signed? In my experience, nearly all of the mail that makes it through existing spam filters and has a List-ID header is really from a list. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Fwd: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC
FYI. d/ Original Message Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) From: IETF Secretariat ietf-secretar...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org CC: ondrej.s...@nic.cz, keyass...@ietf.org A new IETF non-working group email list has been created. List address: keyass...@ietf.org Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/keyassure Description: This list is for discussion relating to using DNSSEC-protected DNS queries to get greater assurance for keys and certificates that are passed in existing IETF protocols. The main idea is that a relying party can get additional information about a domain name to eliminate the need for using a certificate in a protocol, to eliminate the need for sending certificates in the protocol if they are optional, and/or to assure that the certificate given in a protocol is associated with the domain name used by the application. In all three cases, the application associates the key or key fingerprint securely retrieved from the DNS with the domain name that was used in the DNS query. For additional information, please contact the list administrators. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- 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 Usefulness
Patrick, I appreciate your input and advice here. I have not deviated from most, if not all, of your key notes. What I would trying to extract from this, is how can DKIM-CORE be coupled with some other, preferably standard or BCP to get some level of usefulness - something I can use to explain to customer how it can serve them. IOW, the implication is such that pure unrestricted DKIM-BASE signing (by any MTA) has (or can provide) a useful (and non-damaging) purpose and I wanted to know how that is accomplished without any other integrated or interfacing design considerations, including MUA and MLM, both of which we have expert level skillset. Anyway, you convinced me that we need to finally get DKIM implemented abeit as you noted for associated risk reasons, very carefully and conservatively. Murray's work to consolidate and address the long time MLM concerns is a major help in my renewed DKIM interest. He is probably sore for an additional pat on his back. :) -- 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] Issue 4871bis - DKIM Definition Separation of domains conflict
Douglas Otis wrote: I don't think a reference to POLICY needs to be made, but only focus on the idea that the LAST SIGNER is the responsible party. What conclusions would you draw from the last signer, when there is also a valid Author Domain authorized third-party signature? It seems wrong to suggest there would be great significance in the last signature added. The last DKIM (re)signer message handler is the final arbiter of the next handler DKIM message verification result. With 4871bis, it (last handler) has complete and as the 3rd sentence implies, unrestricted, control over the absolution of any previous single or collective domains responsibility. Lets restate the 3rd sentence: DKIM separates the question of the identity of the signer of the message from the purported author of the message. First of it, it DOES NOT separate any question because the 5322.From header is a required DKIM hash binding and hence it is always bound to any and all signatures. As long as the 5322.From binding is a requirement, there is always an association with the signer and the original AUTHOR. Second, I think we can all understand the historical perspective why the 3rd sentence exist, to break away from POLICY driven resigning restrictions. This is an inherent subjective POLICY and I believe it needs to be noted the long required multi-protocol synergism necessary to engineer DKIM properly, not only for POLICY for Reputation based models, needs to be considered in 4871bis. So if we don't want 4871bis to be specific, it needs to at least remove any semantics that suggest 4871bis has no signing restrictions. The only way to truly separate the question of the signer and author domain, is to remove the DKIM requirement to include the 5322.From header in the bind. -- 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] draft-ietf-dkim-mailinglists annex MUA considerations
Daniel Black wrote: On Tuesday 17 August 2010 01:18:52 Hector Santos wrote: I think which keeps getting in the way here in molding ideas is that much of it is based on online MUA access which does not always match Offline MUA access, I was going on a desireable assumption that a verifier would add a Authenticated-Results header field and online/offline MUAs could depend on this if it falls within the right domain or its domain is accepted by a user. Right. it would be for offline devices. Online rendering can handle this. I can see one offline MUA feature that could be part of the mail account settings: [_] Trust the A-R header for mail picked up from this domain. Or it do it as a domain while list file listing managing by the user. It would be the opposite of the Fire Icon Thunderbird has to mark message as JUNK.This A-R button would add the validated domain to the whitelist. The main point Dave and Levin were making is that it wouldn't be possible to equally apply to all offline MUA, unless using the method I suggested of writing this trust information in the top of the body. The 2nd main point is that the trust conclusion should not be automated without some form of user action, like with the per mail account checkbox setting to trust the A-R header for this mail pickup site. -- 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] draft-ietf-dkim-mailinglists-01 review request
Michael Thomas wrote: On 08/17/2010 04:08 AM, Ian Eiloart wrote: Yes, out Exim/Spamassassin installation does DKIM (but not ADSP) evaluation during the SMTP session. I'm not positive, but I believe that Ironport does it that way too. Is there anybody who *doesn't* do DNS lookups at SMTP time these days? That's all DKIM really amounts to, and the entire mail infrastructure would seize if we weren't (cf, blacklists). In the past, I followed how implementations of SPF was being done - at SMTP or post acceptance. I recall it was interestingly spread out depending on the software being used. Most of the MTAs that allowed embedded hooking with programming scripts had scripts available and others used general 2822 text file mail bot SPF scripts. But I've also followed other MTAs such as YAHOO, AOL, MSN.COM, gmail.com and so on, where you definitely saw a shift towards DATA level rejections than in the past. The only issue overall between the two was how the ENVELOPE information was read or written into the 2822 file for post smtp to read. In general, you could get this from the top Received: line stamped by the MTA (a requirement), but other MTA add specific syntax envelope info at the top before the 2822 blocks. At the SMTP level, you don't need to work about that but generally, the scripting language is proprietary to the MTA engine in use. So POST SMTP scripts tend to be more general and made to work with for most MTAs, with no or little change. -- 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
