Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
Alessandro Vesely wrote:
On 08/May/11 19:13, Dave CROCKER wrote:
In practical terms for the current world, what is the likelihood that
a signer has any information about the 'type' of an email address?
How can a signer possibly know that an addressee is a mailing list???
Currently, it has to query the /time-distributed database/ brought
about by the spotty subscription reminders that MLMs send on April
fools' day and similar occasions.
Seriously, since it is a civic and sometimes legal duty to confirm
subscriptions, one may wonder why that database is not maintained by
means of present-day technologies. Every MTA would then have a list
of mass mailers, cross-linked to its users, to be looked up when
whitelisting, signing, resolving complaints, and, occasionally,
attesting (un)subscriptions.
Forgive the OT.
Well, Dave's perspective is that of an independent (3rd party) free
wheeling signer. The issue at hand regarding the need to use the l=
is that of an author domain signing his own mail and thus has already
selected a s= value to use, its own or a provisioned independent
signer domain. But it the author domain doing all the picking, setup
and signing - not the signer domain. Even if its the 3rd party, the
author domain can still dictate what it wants (see the ending comment).
In our current rev1 DKIM implementation, the outbound edge MTA does
the signing and it reads a setup file keyed on the From.domain or
List-ID.domain.
That is how it knows what to sign and with what options per domain
stream and this was the quickest and no MLM software change. It was
to handle the MLM list setups on our system or a customer system with
the same software to handle its mailing list.
In Rev2 it will updated to handle external mailing list (inbound)
using a Mail Conference Type factor and this is where the l=
option MAY APPLY.
For example, for our API, the conference types are:
enum {
mtNormalPublicPrivate,
mtNormalPublic,
mtNormalPrivate,
mtFidoNetmail,
mtEmailOnly,
mtUsenetNewsgroup,
mtUsenetNewsgroupModerated,
mtInternetMailingList,
mtFidoEcho,
mtListServeForum,
mtUserEmail,
mtEND = 256
};
The operator can prepare Internet Mailing List conference where list
traffic can be stored. For this conference type, it also enabled a
Reply Network Address. For example:
Name : IETF-DKIM
Type : Internet Mailing List
Network Address: ietf-dkim@mipassoc.org
This conference can be accessible by online users, including by News
Readers MUAs if the conference option is checked:
[X] Publish as a Local Newsgroup
Any (access allowed) user reading the conference can create or reply
and the mail is exported with a forced direction to the network address.
Now when we add DKIM, new options could be for a internet mailing
list conference type:
[X] Sign Mail
[X] Use Body Length tag
With this option enabled, our edge MTA will now have the setup info
to use the L= tag when signing it only for this specific network address.
Finally, it is not unheard off in the outsource or ISP/ESP/Anti-Spam
mail service business to provide a list of user addresses for your
system. In fact, before we added better anti-spam stuff, we offered
an utility to specifically export a complete or DIFF file of
acceptable users for the hosting service to accept, do whatever to
the mail if anything, and forward to mail to their smart host/MDA
system. This is how many early operators began to add Anti-Spam
protection to their mail.
So for DKIM, a domain that wishes to outsource the signing operation
to a 3rd party, can easily possibly to start using a similar manual or
email automated method to send a full/change list of domains and
addresses it wishes to be sign under specific options like a l=. In
fact, the # of domains/addresses may even be part of the fee schedule
for the service. This will cater to domains with an fast DKIM entry
point who do not wish the deal with the internal overhead and cost to
setup/maintenance DKIM.
--
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: Consider deprecating l=
On May 9, 2011, at 5:14 PM, John Levine wrote: I think it was a mistake to include l= in the first place, but I find Murray's arguments against taking it out now persuasive. Agreed (which is a -1 to removal.) I would also really like to have a better idea of how people are using it, notably, for all those messages where l= doesn't cover the whole body, what's in the naked part. Agreed. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
On May 8, 2011, at 11:16 PM, Murray S. Kucherawy wrote:
-Original Message-
From: Franck Martin [mailto:fmar...@linkedin.com]
Sent: Sunday, May 08, 2011 9:12 PM
To: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
such as a signing and author subdomain {DKIM 12} - such as a signing
and author subdomain {DKIM 12} or a totally different domain
I'm on the fence on this one. Does anyone else have an opinion?
It is a best practice document so the full realm of possibilities should
be included.
It doesn't make general sense to list all possibilities in something that's
supposed to espouse a best practice. Although you're right that it could be
any domain, I think the best practice when it comes to creating mail streams
is the subdomain option.
Agreed, that seems to be the best currently-deployed practice.
Do you have some specific text you want to propose here? I couldn't
imagine any based on this comment.
Yes it is hard, because we don't want to endorse any product/service. Let
me try.
Some MTA senders and receivers can enter in bilateral agreements or via a
third party to receive out of band reports on failed signatures.
That's true, but is it advice specific to the MLM environment? And is 5.2
the right place to talk about this?
It'd fit nicely into a separate BCP on handling signature failures -- perhaps
after there's more widespread operational experience with
draft-ietf-dkim-reporting?
5.3 postmaster should inform their users that messages are likely to be
discarded if sent via a MLM.
Is this inbound or outbound? I assume inbound given the title of the
section. But again I couldn't concoct text in my head to match your
remark. Can you propose some?
I thinking outbound. As this document is to give postmasters a quick
start, then it is good to mention if you choose ADSP, there is no way
the message can go via a mailing list and survive. I thought it was
possible before reading this RFC that you could tweak a MLM in a manner
that ADSP would not break, but I realize while possible it is absolutely
impractical and as you say a cooperating MLM better drop the message out
front.
What I'm worried is that it does not set a mindset with other email
policies that can be created.
I think it's safer to let the MLM operator decide, since that person knows
whether or not the list software will tend to break signatures on messages it
re-sends.
Or if they don't know, this will encourage them to find out.
--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #24
On May 6, 2011, at 11:21 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Friday, May 06, 2011 11:15 AM To: ietf-dkim@mipassoc.org Cc: barryle...@computer.org Subject: Re: [ietf-dkim] Ticket #24 I appreciate the work that Doug and Charles put into their proposal, but for reasons already discussed, I think we should leave section 6.1 as is in -09. +1. Sections 3.8, 8.14 and 8.15 already say enough about this issue. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: Consider deprecating l=
On Tue, 10 May 2011 00:02:36 +0100, Barry Leiba barryle...@computer.org wrote: That was quick. I believe we already have enough objections to say that we do NOT have rough consensus for deprecating l= at this time. I'll close the issue in the tracker (issue #26), and we will leave it as it is. Of course, folks may, if it makes them feel good, continue to register objections here. Yes, leave it be. Point out some problems if you wish, but no more. People seem to be using it. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D Action: draft-ietf-dkim-mailinglists-10.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 : DKIM And Mailing Lists Author(s) : Murray S. Kucherawy Filename: draft-ietf-dkim-mailinglists-10.txt Pages : 32 Date: 2011-05-10 DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this Best Current Practices document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-10.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10
The DKIM Working Group requests the publication of draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document might be suitable for Pete's Applicability Statement experiment, at the Proposed Standard level. Please see the attached PROTO writeup. Barry, DKIM working group chair PROTO writeup for draft-ietf-dkim-mailinglists-10 The DKIM Working Group requests the publication of draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document might be suitable for Pete's Applicability Statement experiment, at the Proposed Standard level. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Barry Leiba is the document shepherd. I have reviewed this version, and am satisfied that it's ready. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has adequate review, and I have no concerns about the level of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no concerns. There is no IPR involved. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus of the working group, as a whole, behind it. A minority of participants feel that the advice given in the last paragraph of section 1 is all that makes sense, and that the rest of the document isn't needed (see Working Group Summary later in this writeup). Those participants are willing to accept this document, nonetheless, seeing no harm in it. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are no ID nits, apart from a reference issue (see 1.h). (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All references are properly separated and labelled. There is a normative reference to RFC 5598, an informational document. This document defines terms used in discussion of email architecture, and is widely referenced in this manner. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it
Re: [ietf-dkim] Ticket #24
To be concise, here are the proposed changes. The group's preferred change, #1, is this: 1. Add: --- 6.1.n. Validate Multiple Header Field Occurrences Through inadvertence or malice, a message may be received having multiple occurrences of single only header fields per [RFC5322]. To provide results upon which subsequent agents can rely, verifiers MUST detect an invalid number of single only header fields present within the Signature header field's h= list and return PERMFAIL (illegal multiple header fields). See Sections 8.14 and 8.15 for further discussion of such attacks. That asks for a lot, so the group has a second alternative, #2, which only asks for the from: 2, Add to 6.1: --- To provide results upon which subsequent agents can rely, verifiers MUST detect an invalid number of From header fields and return PERMFAIL (illegal multiple headers. [RFC5322] requires there be exactly one From header field. See Sections 8.14 and 8.15 for further discussion of header field considerations. While I address the other two open tickets, do the IESG writeup, and otherwise get ready to send 4871bis to the IESG, everyone please take the time to read Doug's note and weigh in on these two alternatives. Let us know, in this thread, whether you support one or the other of them, or whether you prefer the text as it currently is in the -09 version of 4871bis. If you have anything to say in argument for or against, please keep it VERY BRIEF. This is a call for new consensus, and the arguments have been made at length already. We need to see rough consensus *for* one of these changes in order to make them. I'll let this float for a few days -- I expect to be ready with the writeup by the middle of next week. I have the writeup almost ready for the IESG, and this issue has had enough responses for me to get a clear sense: The existing text had consensus before, and there is not consensus to change it now. The existing text will stay. I'm closing issue #24 as wontfix. My thanks to Doug, Charles, and Rolf for working out text to support their position, and thanks to the others for reviewing it and commenting. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep arguments to a minimum, so it's clearer to me what the consensus is -- we've had the arguments going for a while now. I have the writeup almost ready for the IESG, and this issue has had enough responses for me to get a clear sense: We do not have consensus to make this change. I'm closing issue #25 as wontfix. Thanks, Hector, for laying the issue out clearly, and to others for reviewing and commenting. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Final version of 4871bis
Murray, will you please finish folding in last-call comments, and submit the draft for 4871bis-10 ? I will do my final review on Wednesday, and send it to the ADs. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
