Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
> The law requires that there be an easy to use address for unsubscribing. > The List-unsubscribe header: would do the job nicely, if the majority of > people were using mail clients that expose it by default. I don't know of > any mail client which does that. pine/alpine does, but I agree, most MUAs don't show headers other than To, From, Cc, and Subject. This might be a good time to remind people that MLMs in their current form are not broken, and any proposal that requires them to stop doing something that they're currently doing, like rewriting messages or adding message tags, is a non-starter. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] broadcast lists
>> Even though ESPs are generally sending mail on behalf of customers, >> their relationship to the customers allows them to be the customer, as >> far as mail authentication is concerned. There are some issues about >> how a customer delegates part of its identity to its ESP, but they are >> completely, totally, unrelated to the MLM issues we've been arguing >> about. > > A document on those delegation issues might be helpful also. I'd be happy to work on one if anyone thinks that ESPs who don't already everything it says will read it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Authorizing List Domains
Stephen Farrell wrote: > > On 28/09/10 23:02, Douglas Otis wrote: >> On 9/27/10 9:47 PM, Murray S. Kucherawy wrote: On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote: >> TPA-Label involves ADSP being discussed on the dkim list. > > I've no idea precisely what Doug means here, but to avoid > doubt: the DKIM WG has a charter that does not currently > include work on TPA nor other possible alternatives, nor > any other tweak or alternative to ADSP. > > There does seem to be interest (though nothing like > consensus) in these however so we're not trying to stop > discussion for now, in the hope that one or other garners > sufficient consensus that we might re-charter. (And in > any case, its clear that asking people on this list to > stop typing is currently pointless;-) > > So these are all "unofficial" activities in the sense > that there is no plan for the WG to produce any RFCs. Early this year, the group "new goals" and correct me if I misunderstood, was to implement, experiment and collect data, especially for ADSP and Mailing List Software designs. If I recall, we gave ourselves at least 1 year to collect data. This is happening now. We implemented DKIM + POLICY, the R&D and statistics collection has commenced, and specifically with a focus towards policy and interaction/associations with Mailing List Software. The market research is very clear there is a strong interest for third party authorization protocols. ASDP as it stands now has limited value. But it offers an extensions feature and we are leveraging this to explore third party authorization solutions - the missing big piece in all this. While I clearly understand the charter does not include new I-D, I believe in the same way the "Out of Scope" Reputation modeling helped alter 4871 with 4871bis, we can also learn from the "out of scope" ADSP extensions R&D to help codify and fine tune RFC 5617 (ADSP) with a 5617bis. -- 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] Authorizing List Domains
On 9/28/10 3:27 PM, Murray S. Kucherawy wrote: > >> On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote: > > > > TPA-Label involves ADSP being discussed on the dkim list. > > Unless you're talking about revising ADSP (which it seems you are > specifically not doing since TPA is meant to cover other > technologies as well; plus, ADSP wasn't in your list), we're talking > about something new that is not in the current DKIM WG Charter. The TPA-Label draft offers additional ADSP assertions having semantics intended to support _existing_ mailing-list and third-party practices. The DKIM charter states the following: ,--- Consider issues related to mailing lists, beyond what is already documented. ... '--- > > Some have expressed strong desires to improve DKIM deliverability > > by allowing fallback to other adopted verification methods. > > TPA-Label permits such fallback without also requiring the same > > domain be used by alternative methods. > > The first sentence there seems contradictory to me; if you're > falling back to other methods, we're no longer talking about mere > DKIM deliverability. Sorry, should have said DKIM/ADSP deliverability, which is based upon DKIM Author Domain Signatures. The TPA-Label draft offers alternative ADSP assertions that indicate the possible availability of domain specific exceptions. When exceptions are not found, non-compliant messages are to be rejected, as opposed to being discarded or scored in some fashion. > > DKIM is unable to unilaterally authorize third-party services which > > impedes use of restrictive acceptance criteria. > > DKIM specifically allows a domain to give a third party signing > authority by putting into the DNS a public key matching a private > key that is in possession of that authorized third party. Unless > there's an assertion being made that this mechanism creates a > hardship, I'm still not clear why that's been dismissed as a > possibility. Utilizing a discussion list and mitigating domain spoofing is not possible with existing ADSP assertions. Nor is publishing public keys for all such discussion lists either a practical or a wise solution. Inclusion of List-ID or Sender header fields as an ADSP compliance requirement places less reliance upon only the From header fields in the recognition of message sources whenever authorizing third-party services. > >> Since any client can say anything it wants for an EHLO > >> parameter, why should it be considered a type of authentication? > > > > The SMTP client identified by the EHLO might resolve the IP address > > used in the exchange. While such resolution is not required by > > SMTP protocol, it might offer an opportunistic means to > > authenticate the administering domain as a fallback method. > > The DNSOP working group has repeatedly advised against use of > reverse DNS as a mechanism for client authentication. Do we claim to > have expertise they are lacking? See: http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4 The SMTP EHLO or HELO hostname must resolve the IP address of the SMTP client. Reverse DNS is not used. > For that matter, one could invent a scheme that mandates any piece > of data must match any other piece of data, both of which are > potentially (perhaps even often) under the control of a miscreant. > I'm not sure I see how this is useful. Requiring additional header field compliance better ensures different mail streams remain recognizable by recipients. Many MUAs already display Sender, and many who subscribe to mailing-lists already sort using List-IDs. Whether or not recipients see the required header field, their requirement helps isolate authorizations to specific mail streams, such as messages emitted by the authorized domain's mailing-list services. The TPA-Label response includes authentication requirements intended to exclude miscreants. The general premise is exceptional authorization is only given to trustworthy services. > Moreover, identification of a client as legitimate or otherwise > based on HELO/EHLO data has proven problematic if only because of > common configuration errors. Enforcing something along these lines > will likely create more operational problems than it solves. There is no assured authentication method specified by SMTP. This leaves a range of options that might be employed by third-party services, such as mailing-lists. However, ADSP's convention of only binding Author Domain DKIM signatures with the From header field disrupts these services whenever restrictive assertions are made. A goal of the TPA-Label draft is to leverage the strongest authorization method available. The strongest confirmed authentication method indicated within the TPA-Label for the domain in question reduces the receiver's discovery efforts. > > These header fields must match against TPA-Label specified > > domains. The contained domains ensure the effectiveness of
Re: [ietf-dkim] Authorizing List Domains
On 28/09/10 23:02, Douglas Otis wrote: > On 9/27/10 9:47 PM, Murray S. Kucherawy wrote: >>> On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote: > > TPA-Label involves ADSP being discussed on the dkim list. I've no idea precisely what Doug means here, but to avoid doubt: the DKIM WG has a charter that does not currently include work on TPA nor other possible alternatives, nor any other tweak or alternative to ADSP. There does seem to be interest (though nothing like consensus) in these however so we're not trying to stop discussion for now, in the hope that one or other garners sufficient consensus that we might re-charter. (And in any case, its clear that asking people on this list to stop typing is currently pointless;-) So these are all "unofficial" activities in the sense that there is no plan for the WG to produce any RFCs. S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Authorizing List Domains
On 9/27/10 9:47 PM, Murray S. Kucherawy wrote: > > On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote: TPA-Label involves ADSP being discussed on the dkim list. > > Agreed, but not having a defense against trivial exploitation of > > an authorization is not better. When a defensive requirement > > proves unused, it can be removed without impact. Since this > > information sets authorization requirements, adding the information > > at a later date would not be compatible with existing > > implementations. > > That seems antithetical to the idea that this is all experimental > work, explicitly not on the standards track. Some have expressed strong desires to improve DKIM deliverability by allowing fallback to other adopted verification methods. TPA-Label permits such fallback without also requiring the same domain be used by alternative methods. > > Perhaps we can work on the bare essentials independent of the > > notation used. > > > > Types of authentication that might be used for existing > > third-party services- > > > > 1) DKIM 2) TLS 3) SPF 4) EHLO/ADR > > I wasn't aware we were scoping something intended to be universally > used. My focus has been strictly on DKIM. Other than TLS, we're not > talking about particularly strong authentication systems here so I'm > not sure we should spend the cycles to be that accommodating. > However, as I said before, decoupling ATPS from ADSP is a trivial > matter if that turns out to be the right way to go. DKIM is unable to unilaterally authorize third-party services which impedes use of restrictive acceptance criteria. With few exceptions, DKIM/ADSP "discardable" disrupts normal email use, and ADSP/SPF "all" is ineffective at blocking spoofed domains. TPA-Label can remedy inappropriate message rejection or acceptance while also avoiding discarded messages. You seem to agree TLS could be included as a compliance option in conjunction with restrictive acceptance assertions. TPA-Label offers a fallback to other authentication/verification methods for graceful DKIM methodology transitions. While SPF does not authenticate a source domain, SPF "-all" currently represents the predominate restrictive acceptance assertion aimed at mitigating loss of email credibility caused by domain spoofing. The TPA-Label scheme offers fallback options that don't wait for universal DKIM adoption to improve legitimate domain acceptance and spoofed domain rejection rates. Perhaps TLS will be adopted as a means for IPv6 email acceptance based upon a domain, and might even become a governmental requirement. After all, restrictive assertions requiring Author Domain DKIM signatures accompany the From header field is disruptive for most third-party services, when compared with restrictive SPF assertions. In addition, DKIM signatures will not be as good at protecting domain reputations when compared with the use of TLS. > Since any client can say anything it wants for an EHLO parameter, why > should it be considered a type of authentication? The SMTP client identified by the EHLO might resolve the IP address used in the exchange. While such resolution is not required by SMTP protocol, it might offer an opportunistic means to authenticate the administering domain as a fallback method. > > Additional header field requirements ensure message sorting or > > presentation. The header field requirement is to offer simple > > tactics against most phishing exploits: > > > > a) Sender b) List-ID > > Why would one base any kind of security mechanism on a trivially > spoofed header field? These header fields must match against TPA-Label specified domains. The contained domains ensure the effectiveness of message sorting or header display in allowing recipients a means to differentiate email sources that might also contain the From header used by ADSP. The source of these header fields must also correspond with specified domain and authentication/verification methods. > > The most visible name to recipients is the domain found in the From > > header, whether used as a basis for sorting, or when displayed in > > addition to that of the friendly name. > > Then why create semantics around other fields? The From header field is not strictly bound to specific email sources, especially for third-party services. In reviewing the number of such sources involved, a dedicated effort at constructing comprehensive _tpa zones can fully encompass all legitimate sources and avoid most of the issues related with SPF and ADSP discardable/all. Ensuring inclusion of Sender or List-ID header fields helps isolate third-party service mail streams and provides recipients a means to differentiate direct and indirect messages. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Tue, Sep 28, 2010 at 3:29 PM, MH Michael Hammer (5304) wrote: > >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >> boun...@mipassoc.org] On Behalf Of Jeff Macdonald >> So the exchange is more likely to be: >> >> 1) message sent with restrictive policies >> 2) message bounces/is discarded >> 3) recipient feels unloved, asks Author why? >> 4) Author looks at logs and sees message was delivered, asks recipient >> to ask their ISP why >> 5) recipient asks ISP why >> 6) recipient gets an answer from ISP (really?) >> >> > > Jeff, > > Are you telling us that your clients are sending mail through your systems > using ADSP=discardable? If not, what are the restrictive policies indicated > in item "1)"? Sorry, that was a generalization. I don't see us promoting ADSP. We are not doing DKIM yet (about to pilot any week now). I just wrote some documentation for client services in which I left out ADSP on purpose. Although I do feel that ADSP is fine for marketing domains, I suspect that our clients want all their messages delivered. However, we do strict SPF/SenderID. Simply because of mandates by certain groups or ISPs. And we'll publish ADSP records for clients who ask for it. > For item "3)", can you indicate generally the nature of the mails involved? > Are these transactional? marketing? Where's the love? Both. Believe it or not, some people live for bargains and haven't discovered what a RSS reader can provide. > Just trying to understand. #1 could be shortened to "message sent" and the rest would still be true. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Jeff Macdonald > Sent: Tuesday, September 28, 2010 3:12 PM > To: DKIM > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > On Tue, Sep 28, 2010 at 1:18 PM, Dave CROCKER wrote: > > > > > > On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: > >> If a domain publishing ADSP discardable has not gotten control of their > >> mailstreams then all I can say is "Darwin was right". > > > > > > I agree with you completely. > > > > The problem is that customers of a receiving ISP often do /not/ agree > with you. > > > > When their ISP discards mail the customer wanted, the explanation "well, > it's > > what the author told me to do" typically does not work. And since the > > customer's contact is with the receiving ISP, it is the receiving ISP > that must > > alter their activity. > > I'm not convinced this is entirely true. We often get queries from our > clients who get queries from their subscribers asking what happened to > the email they were expecting. In other words, the questions are being > initially directed to the Author, not the recipient's ISP, about the > missing email. > > So the exchange is more likely to be: > > 1) message sent with restrictive policies > 2) message bounces/is discarded > 3) recipient feels unloved, asks Author why? > 4) Author looks at logs and sees message was delivered, asks recipient > to ask their ISP why > 5) recipient asks ISP why > 6) recipient gets an answer from ISP (really?) > > Jeff, Are you telling us that your clients are sending mail through your systems using ADSP=discardable? If not, what are the restrictive policies indicated in item "1)"? For item "3)", can you indicate generally the nature of the mails involved? Are these transactional? marketing? Where's the love? Just trying to understand. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing
On Sep 28, 2010, at 11:34 AM, J.D. Falk wrote: > On Sep 24, 2010, at 11:05 AM, John Levine wrote: > >>> Do concepts generalize enough to allow issuing >>> draft-ietf-dkim-mailinglists also for these "authoring" MLMs? >> >> No. All of the complications in mailing lists arise from the fact >> that the author of the message is not related to the operator of the >> list. >> >> Even though ESPs are generally sending mail on behalf of customers, >> their relationship to the customers allows them to be the customer, as >> far as mail authentication is concerned. There are some issues about >> how a customer delegates part of its identity to its ESP, but they are >> completely, totally, unrelated to the MLM issues we've been arguing >> about. > > A document on those delegation issues might be helpful also. I cover the main approaches I'm aware of, briefly, at http://dkimcore.org/deployment/esp.html I'm planning on fleshing that out a bit this weekend[1] to turn it into more of a design manual. If anyone has any docs or thoughts about ESP-style DKIM delegation I'd love to share. Cheers, Steve [1] Yay for long, boring plane flights! ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing
On Sep 24, 2010, at 11:05 AM, John Levine wrote: >> Do concepts generalize enough to allow issuing >> draft-ietf-dkim-mailinglists also for these "authoring" MLMs? > > No. All of the complications in mailing lists arise from the fact > that the author of the message is not related to the operator of the > list. > > Even though ESPs are generally sending mail on behalf of customers, > their relationship to the customers allows them to be the customer, as > far as mail authentication is concerned. There are some issues about > how a customer delegates part of its identity to its ESP, but they are > completely, totally, unrelated to the MLM issues we've been arguing > about. A document on those delegation issues might be helpful also. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On Tue, Sep 28, 2010 at 1:18 PM, Dave CROCKER wrote: > > > On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: >> If a domain publishing ADSP discardable has not gotten control of their >> mailstreams then all I can say is "Darwin was right". > > > I agree with you completely. > > The problem is that customers of a receiving ISP often do /not/ agree with > you. > > When their ISP discards mail the customer wanted, the explanation "well, it's > what the author told me to do" typically does not work. And since the > customer's contact is with the receiving ISP, it is the receiving ISP that > must > alter their activity. I'm not convinced this is entirely true. We often get queries from our clients who get queries from their subscribers asking what happened to the email they were expecting. In other words, the questions are being initially directed to the Author, not the recipient's ISP, about the missing email. So the exchange is more likely to be: 1) message sent with restrictive policies 2) message bounces/is discarded 3) recipient feels unloved, asks Author why? 4) Author looks at logs and sees message was delivered, asks recipient to ask their ISP why 5) recipient asks ISP why 6) recipient gets an answer from ISP (really?) -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
> -Original Message- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Tuesday, September 28, 2010 1:18 PM > To: MH Michael Hammer (5304) > Cc: DKIM > Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review > > > > On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: > > If a domain publishing ADSP discardable has not gotten control of their > > mailstreams then all I can say is "Darwin was right". > > > I agree with you completely. > > The problem is that customers of a receiving ISP often do /not/ agree with > you. > Where someone stands depends on where they sit. > When their ISP discards mail the customer wanted, the explanation "well, > it's > what the author told me to do" typically does not work. And since the > customer's contact is with the receiving ISP, it is the receiving ISP that > must > alter their activity. Since discarding got them in trouble, they will, at > best, > start discarding much more selectively. "Selectively" means using > information > beyond ADSP. > I've been saying for a while that ADSP is broken by design. When we (the group) reached the compromise that we did, I fully expected that data would become publicly available that would help generate a collective will to come up with a better/more robust implementation of ADSP. Put hope in one hand and never mind. > Given sufficient selectivity, the mechanism that defines "selective" will > contain enough information to make ADSP redundant. > Not intending to be tongue in cheek but I have to ask so what's your point? I think the activity in the "3rd party intermediary" space is indicative that there is a need to solve the issue of whether folks really mean the assertions they make and whether mailbox providers are willing to believe/act on those assertions. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 28/Sep/10 12:59, Ian Eiloart wrote: > --On 27 September 2010 19:26:37 +0200 Alessandro Vesely > wrote: > >> Now the MLM does its editing job. It knows the original message was >> signed, so it makes sense to verify if the signature is still good >> after any changes have been applied. In case verification fails, it >> shouldn't try to distribute an adsp-breaking message, so it can either >> send back a bounce or drop it. > > Oh, but I already know that my MLM is going to break any message with a > signed body. UK law practically mandates the addition of unsubscription > information in a message footer. We certainly require it locally. Signatures may still survive if they use l=. Probably, the best method for determining whether a signature has been broken is to simply verify it again. BTW, running OpenDKIM testsuite, it seems that verifying is an order of magnitude faster than signing. Thus, an extra verification shouldn't hurt. As a curiosity, I've noted that MLMs usually avoid duplicating the subject-tag (possibly even if it was present twice in the original.) However, they almost invariably duplicate the footer, if it's already present. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] envelope signatures, was Corner cases and loose ends
>> That no workable envelope-level DKIM equivalent has materialized to >> date is unfortunate. >> >> Not for lack of trying, but I just don't see how you could prevent bad >> guys from replaying good envelopes on bad mail. > >Yeah. Short-lived keys is the best thing I can come up with. > >Do you think it's worth a shot? Probably not. BATV is about 2/3 of what a scheme like that would be. It has a bounce address with a signature hash of the original bounce address and a timestamp, with its main limitation being that it uses a private key rather than public key signature, which would be straightforward to add. It works well for me, but people say it causes problems due to changing bounce addresses for the same correspondent (a surprising amount of software keys on bounce address) and local parts longer than 64 characters, a limit that some MTAs still enforce. To limit replays, it could include both the bounce and recipient addresses in the hash, but that would recreate much of what's wrong with SPF. So unless you have a truly brilliant way to solve all these problems (we can always hope), I don't see any point to going down this road again. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: > If a domain publishing ADSP discardable has not gotten control of their > mailstreams then all I can say is "Darwin was right". I agree with you completely. The problem is that customers of a receiving ISP often do /not/ agree with you. When their ISP discards mail the customer wanted, the explanation "well, it's what the author told me to do" typically does not work. And since the customer's contact is with the receiving ISP, it is the receiving ISP that must alter their activity. Since discarding got them in trouble, they will, at best, start discarding much more selectively. "Selectively" means using information beyond ADSP. Given sufficient selectivity, the mechanism that defines "selective" will contain enough information to make ADSP redundant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] end-of-data vs. connect-time
On 9/13/2010 11:58 AM, Murray S. Kucherawy wrote: > people believe the cost incurred by switching to end-of-DATA filtering vs. > connect-time filtering is a lot larger than I believe. And they [claim to] > have the data to support that position from large customers,... This issue keeps popping up. We need to find a way to get some solid data published about the costs and tradeoffs. I wonder whether this is a task best pursued in MAAWG? 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 28 September 2010 13:10:51 +0100 Graham Murray wrote: > Ian Eiloart writes: > >> Oh, but I already know that my MLM is going to break any message with a >> signed body. UK law practically mandates the addition of unsubscription >> information in a message footer. We certainly require it locally. > > Why does it have to be in the footer when (for many MLMs) it is also in > the List-Unsubscribe: header[1]? The 'excuse' that MUAs do not display > the header details does not hold water as the MLM footer would come > after the '-- ' author's signature separator and some MUAs will not > display the signature and if the original email was multipart/alternate > does the unsubscription information have to be included in all (normally > text/plain and text/html) alternatives? The law requires that there be an easy to use address for unsubscribing. The List-unsubscribe header: would do the job nicely, if the majority of people were using mail clients that expose it by default. I don't know of any mail client which does that. The footer, on the other hand, is displayed by most mail clients. The legislation doesn't require that absolutely every case is covered. It's not been tested in court, but I imagine that reasonable effort would be the test applied. Now, it may be that adding a footer isn't enough, but if that's the case, then relying on the header is even worse. > [1] Which does not break the author's DKIM signature. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On Sep 28, 2010, at 5:10 AM, Graham Murray wrote: > Ian Eiloart writes: > >> Oh, but I already know that my MLM is going to break any message with a >> signed body. UK law practically mandates the addition of unsubscription >> information in a message footer. We certainly require it locally. > > Why does it have to be in the footer when (for many MLMs) it is also in > the List-Unsubscribe: header[1]? The 'excuse' that MUAs do not display > the header details does not hold water Putting it in the List-Unsubscribe header that's not displayed to recipients is pretty much equivalent to putting it in the X-Bamboozle header that's not displayed to recipients when it comes to displaying legally required content to recipients. > as the MLM footer would come > after the '-- ' author's signature separator and some MUAs will not > display the signature I don't believe that's a behaviour you'd see in any commonly used MUA. > and if the original email was multipart/alternate > does the unsubscription information have to be included in all (normally > text/plain and text/html) alternatives? You'd need to consult a lawyer familiar with your local laws, and ideally also the local laws of every one of your recipients to answer those questions[1]. But, when talking about legally required elements of a message the sensible question to ask is often "Do you want to fund the lawsuit?". Much more to the point, many people sending email via mailing lists have a need to add information by modifying the body of the message, most easily by adding it in the footer of the mail. Arguing that they don't have that need, and hence that you don't need to support that behaviour, isn't going to fly. Cheers, Steve [1] In the US the answer is yes, the unsubscription information needs to be displayed to the recipient whether they're using a plain-text only MUA or not, if it's a situation where it needs to be displayed at all. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
Ian Eiloart writes: > Oh, but I already know that my MLM is going to break any message with a > signed body. UK law practically mandates the addition of unsubscription > information in a message footer. We certainly require it locally. Why does it have to be in the footer when (for many MLMs) it is also in the List-Unsubscribe: header[1]? The 'excuse' that MUAs do not display the header details does not hold water as the MLM footer would come after the '-- ' author's signature separator and some MUAs will not display the signature and if the original email was multipart/alternate does the unsubscription information have to be included in all (normally text/plain and text/html) alternatives? [1] Which does not break the author's DKIM signature. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 27 September 2010 19:26:37 +0200 Alessandro Vesely wrote: > > Now the MLM does its editing job. It knows the original message was > signed, so it makes sense to verify if the signature is still good > after any changes have been applied. In case verification fails, it > shouldn't try to distribute an adsp-breaking message, so it can either > send back a bounce or drop it. Oh, but I already know that my MLM is going to break any message with a signed body. UK law practically mandates the addition of unsubscription information in a message footer. We certainly require it locally. -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 28 September 2010 01:09:07 -0700 Michael Deutschmann wrote: > On 2010-09-27, John R. Levine wrote: >> And since this group seems to be obsessed with arcane corner cases, >> what do you do with a discardable message if it's sent to two addresses, >> one of which is a mailing list and one of which isn't? > > That's a trivial specific case, of a general problem important in > spamfighting. While a perfect solution would indeed require an extension > to SMTP, we have ways to approach it. LMTP would be a fine extension to SMTP, for these purposes. But why not accept, then later bounce, messages with good DKIM signatures? That should be acceptable where the signing domain and return-path domain match, should it not? Otherwise, send the notification to the author. -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 27 September 2010 11:39:43 -0700 Dave CROCKER wrote: > > > On 9/27/2010 11:04 AM, Murray S. Kucherawy wrote: >>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- >>> boun...@mipassoc.org] On Behalf Of John R. Levine > ... >>> It is not my impression that they all do the full DKIM validation while >>> the SMTP session is open. Mine doesn't. >> >> The milter-based ones like OpenDKIM and dkim-milter do. > > > It's been a significant revelation, for me, to realize how common it is > for DKIM processing to occur during the SMTP session. > > So SMTP issues reduce to finding ways of preventing the cross-net > transfer of data or even of preventing the SMTP session. Oddly, I think > the latter is more feasible than the former. Actually, it's not the traffic that I see as the problem. It's the amount of processing that is performed on the body of the message. We already use SpamAssassin and ClamAV on every message that we accept, and that's way more effort than a DKIM verification. However, with Spamhaus' new DKIM/domain and IP whitelists, I expect to be able to reduce the SpamAssassin scanning (we'd never fail to use ClamAV), once we have confidence in the whitelists. Therefore, I expect to be able to reduce the load on our hosts when good DKIM signatures are present. For domains like gmail.com, I'm considering working on rate-limiting by author address. Of course, the rate limit would be different for a message with a dkim pass. -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 27 September 2010 23:05:46 -0400 "John R. Levine" wrote: > > For Ian, I'm still wondering if he's yet implemented a setup which knows > at SMTP time what addresses deliver to mailing lists so it knows whether > to reject or discard on ADSP failures. Still seems like a lot of work > for a largely nonexistent problem. I know which addresses deliver to *my* mailing lists. They live on a different host, and I check the address so that I know the recipient is valid before accepting the message. The only difficulty arises when messages have multiple recipients. There are several options here, when one of the recipients turns out to be troublesome, but others don't: 1. Treat them all the same, and reject the entire message. 2. Treat them all the same, and deliver to all. 3. Use selective defers to split the stream into two (this is a fairly widely known technique in Exim circles, used to permit application of different SMTP time content based filtering rules) 4. Discard the troublesome recipients, notifying the sender (perhaps only when the sender mail domain matches the signing domain). If selective defers are regarded as difficult, then it's probably best to (A) reject troublesome messages when their is only one recipient, and (B) discard troublesome recipients when there are multiple recipients, and notify the sender. Since the message has a good DKIM signature, the signer may be held responsible for any collateral spam that's generated. -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
--On 27 September 2010 11:07:41 -0400 "John R. Levine" wrote: > > That seems an awful lot of work to do with the connection open to deal > with what is unlikely to be more than a rare misconfiguration. You recommend a particular course of action (discarding) for dealing with ADSP/MLM problems. I think you're almost exactly right except that the action should be to deny instead of discarding. The rarity of the misconfiguration would be an argument for ignoring the case entirely: it doesn't speak to whether one should discard rather than deny once you've gone to the trouble to detect the case. That's the only disagreement that I have with your message. > When you > made these changes to your MTA, how much work was it? How much effect > did it have on overall MTA performance? If you haven't implemented them, > why not? I already know when I have a good DKIM signature because SpamAssassin checks this at SMTP time. I already know when I'm delivering a message to a locally hosted list, because I couldn't route the message otherwise. I haven't implemented ADSP checks yet, because the community is still discussing the best way to do this. However, it's just another DNS lookup. We already do several of those for every message that we handle. Exim (our MTA) is designed to do *all* message checking at SMTP time. It uses ACLs that can run at any point in the SMTP session limited only by the availability of information. It's trivial to move an ACL from one part of the SMTP process to another. The alternative is to pipe the message to an external process which would then deliver it back. It's *much* easier to simply do this in an ACL, and there is no ACL that runs after the SMTP session is closed. Exim documentation gives instructions for running anti-spam software like SpamAssassin, and anti-malware software like ClamAV during the SMTP session. After the SMTP session, you'd have to route the messages through a secondary server to perform those functions. It would be arcane, and less flexible. We've been running SpamAssassin and ClamAV during the border SMTP session for many years now, and introduced DKIM checks about two years ago with zero impact on performance (because spamassassin and ClamAV already do a heck of a lot more DNS lookups and content processing). Here's the hardware that I'm running it on. We've got four of these machines for resilience (two each in two data centres). Any one of the machines can handle peak loads on its own: They're specced to handle our IMAP load, but don't perform that role any longer, because OSX has an artificial limit on simultaneous process numbers. XServe G5 (purchased in 2004) 2x Power PC G5 2.0GHz processors, with typical load averages of about 1.0 6GB RAM (that was for IMAP processes). Currently they use about 1GB, and I'd be happy with 2GB per machine. DNS servers are local to the machines, to reduce network accesses. Really, performance isn't a problem. > And since this group seems to be obsessed with arcane corner cases, what > do you do with a discardable message if it's sent to two addresses, one > of which is a mailing list and one of which isn't? It'll remain an arcane corner case only if you're successful in preventing uptake of ADSP. Either way, the correct solution is worth discovering. Our configurations deal with a lot of corner cases already. > R's, > John -- 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] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 27 Sep 2010, John R. Levine wrote: > I hadn't realized how many medium-sized MTAs do their DKIM during the > SMTP session. You learn something new every day. It still sounds like a > design that *requires* that an MTA do DKIM at SMTP time would present a > problem for some mail systems too large to ignore. If DKIM and ADSP had been invented ten years ago, perhaps post-transaction validation would have become the norm. But some time ago, spamfighters (who have been driving MTA software innovation) became deeply troubled by the fact that content-level spamfilters such as SpamAssassin could only be used in a way that either generates backscatter or causes false-positives to simply vanish. So, by lobbying and contribution of coding effort, they've pushed the dominant MTAs to structure themselves so as to be able to do significant analysis during the moment between CR LF '.' CR LF and its reply. It does break the intent of the RFCs, which expressly demand minimal delay at that juncture to avoid duplicate messages, but we don't care. Duplicate messages are far less horrible than backscatter. Anyhow, with that infrastructure in place, DKIM checking is trivial. At least message hashing can be streamed. We don't need to wait until CR LF '.' CR LF to *begin* analysing. Oh, and in any ADSPbis, I would like to see a flag that forbids silent discard but permits in-transaction rejection. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 2010-09-27, John R. Levine wrote: > And since this group seems to be obsessed with arcane corner cases, > what do you do with a discardable message if it's sent to two addresses, > one of which is a mailing list and one of which isn't? That's a trivial specific case, of a general problem important in spamfighting. While a perfect solution would indeed require an extension to SMTP, we have ways to approach it. (Basically, give 4xx's at RCPT TO: when about to accept mail to boxes with divergent filters. But since this delays mail, when possible just merge the competing filters into one common denominator, accepting possible "overblocking".) But it's not even a problem for modern mailing lists. They can afford to send a "bounce" message in this case, as they already have a confirmed opt-in communication channel to talk with their subscribers. It wouldn't work out if a non-subscriber posts to the list, but for other reasons, modern lists make it a requirement to opt-in subscribe and then suspend delivery, should one want to post without reading. Michael Deutschmann ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
