[Mailman-Developers] mailman and DKIM

2011-02-24 Thread Murray S. Kucherawy 
Hi,

I'm authoring a document within the DKIM working group at the IETF to talk 
about the use of DKIM in the context of mailing lists.  I believe one or more 
of you is already at least monitoring the working group traffic on that topic, 
and thanks for that.

Mailing Lists Managers legitimately modify messages sent through them.  (After 
all, lists are, essentially, re-posting a new message and they can do what they 
want.) DKIM has a minimal feature that attempts to allow a signature to survive 
transiting mailing lists, by ignoring text added to the end.

A suggestion has come up that I'd like to bounce off of you. We're interested 
in doing a better job of surviving the transit.  That means that DKIM would 
have to adjust to other modifications made by MLMs, such as altering Subject: 
field contents.

What a few of us would like to explore is the idea of collaborating with the 
MLM community to develop a profile for MLM message modifications that DKIM can 
be enhanced to survive.  For example, a new canonicalization algorithm might 
tolerate the addition of a "[...]" string at the beginning of a Subject line.  
We would document this profile and MLM implementers can choose to support it.

This would be a voluntary and cooperative effort.  DKIM signers would have one 
more configuration choice.  MLM operators would have a special kind of profile 
that could apply to a list.  Or not.

Our initial discussions have come up with a few idea.  No doubt some are 
unworkable, but they should at least serve to get further discussion going:

1) add a way to DKIM to have small Subject: modifications be tolerated; 
something like "exclude from the signed portion any leading text in the 
Subject: field that is contained within square brackets and includes only 
letters, numbers, hyphens and underscores, to a maximum of 32 characters", 
which would allow MLMs to add a short token such as the list name for use by 
receivers in mailbox sorting but would make it tough for abusers to put a URI 
there;

2) encourage people to sign with "l=" tags, but recommend that receivers 
enforce a policy that says any appended text must be no more than a couple of 
lines long and contain no URLs, or some other similar restriction;

3) explore ways to increase use and utility of the List-* header fields.

I'd like to hear your views on such an approach and any other suggestions you 
may have.  As a representative of The OpenDKIM Project, which is used by AOL 
and Yahoo to perform DKIM verifications, I can say we're in a position to 
conduct some real experiments and get the code out to a wide distribution if we 
come up with something that has the potential to be successful.

Let me know what you think.

Cheers,
-MSK


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] mailman and DKIM

2011-02-28 Thread Murray S. Kucherawy 
> -Original Message-
> From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk]
> Sent: Friday, February 25, 2011 6:09 AM
> To: Murray S. Kucherawy; mailman-developers@python.org
> Subject: Re: [Mailman-Developers] mailman and DKIM
> 
> I think this is only valuable for users of ADSP. Other people would expect
> their signatures to break, and be supplemented with a good signature
> generated by the list server.

I don't think that's the only class of users that would be interested in this 
problem.

> Perhaps you could modify the syntax of the h= tag, to allow, say
> [12]+subject+[5] to mean that 12 unknown characters may prefix the signed
> header, and 5 may follow, provided they are bracketed. I'd suggest only
> permitting bracketed additions, so perhaps this could be expressed as
> 12+subject+5 instead. I suppose all of this might break existing
> implementations, so perhaps a separate tag would be required.

Perhaps, but the verifier needs to be told exactly how to identify the signed 
part in order to feed it to the hash algorithm.  So instead, something like a 
rule that says "remove up to x bytes from the Subject: field, including any 
enclosing square brackets", with a constraint on allowed characters inside the 
square brackets, might be a better approach.

> Maybe the l= syntax could be extended. Eg, l=12544+512 would mean "I'm
> signing 12544 octets, and permitting the addition of a further 512

I would simply add an "la" tag defining the amount that can be appended rather 
than changing the syntax of "l=", so as to be back-compatible with current 
implementations.

> Well, if the sender knows that the list is going to add a List-ID header,
> then it could add that before signing. I doubt this would scale well,
> though.

Why's that?

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] mailman and DKIM

2011-03-03 Thread Murray S. Kucherawy 
> -Original Message-
> From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk]
> Sent: Thursday, March 03, 2011 8:58 AM
> To: Murray S. Kucherawy; mailman-developers@python.org
> Subject: Re: [Mailman-Developers] mailman and DKIM
> 
> >> Perhaps you could modify the syntax of the h= tag, to allow, say
> >> [12]+subject+[5] to mean that 12 unknown characters may prefix the signed
> >> header, and 5 may follow, provided they are bracketed. I'd suggest only
> >> permitting bracketed additions, so perhaps this could be expressed as
> >> 12+subject+5 instead. I suppose all of this might break existing
> >> implementations, so perhaps a separate tag would be required.
> >
> > Perhaps, but the verifier needs to be told exactly how to identify the
> > signed part in order to feed it to the hash algorithm.  So instead,
> > something like a rule that says "remove up to x bytes from the Subject:
> > field, including any enclosing square brackets", with a constraint on
> > allowed characters inside the square brackets, might be a better approach.
> 
> I think that's the same thing, isn't it?

It wouldn't break existing implementations because it would name a new "c=" 
value.  Existing (compliant) implementations would simply ignore such 
signatures.

I think your idea was to delete up to 12 in front of whatever "subject" is and 
5 after, where mine was just to go left-to-right deleting up to the specified 
number in only the first such block of characters.  Slightly different.  But 
either mechanism would mess with an otherwise legitimate Subject: that used 
square brackets for some reason, so that's a concern.

The other suggestions made here discuss the body as more of a concern, since 
Mailman flattens a multipart/alternative into a simpler form.  It could be that 
the proposed MIMEAUTH would work here; sign both parts of the original, and 
then even if Mailman tosses all but the text/plain part and even adds its own, 
the signature on the original text/plain part would still pass.  That, coupled 
with a new header canonicalization mode that tolerates rudimentary Subject 
tagging, might be useful.

(MIMEAUTH: http://tools.ietf.org/html/draft-crocker-doseta-mimeauth-00)

-MSK

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-12 Thread Murray S. Kucherawy 
Hi all,

The IETF recently issued an RFC, with BCP status, regarding interaction between 
DKIM and MLMs.  It seems like this community might be interested.

http://www.ietf.org/rfc/rfc6377.txt

Long ago I mentioned on this list that the IETF was undertaking this effort; 
this is the final product.  I hope it's helpful.

Thanks,
-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-13 Thread Murray S. Kucherawy 
> -Original Message-
> From: Barry Warsaw [mailto:ba...@list.org]
> Sent: Thursday, October 13, 2011 8:30 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> For Mailman, I think we'd like to, and would generally be able to be
> more DKIM-friendly, if we actually knew what to do.  Short of not
> modifying the incoming message at all, and absent clear guidelines in
> this or any other RFC, we're just flailing in the dark.  I think the
> RFC makes it clear though that there really are no good answers.  It's
> a minor point that has no practical effect, but I think it states our
> project's general policy of wanting to be as RFC-compliant as possible.

The document does point out that the "friendly" approach is to put stuff like 
URLs for querying archives and unsubscription instructions up in the header 
using the List-* fields specified in RFC2919 and RFC2369 rather than as body 
suffixes, and don't tag Subject: fields (or, at least, have that 
off-by-default).

Essentially to be "DKIM-friendly" you're free to make any changes you want to 
the message so long as they are confined to those parts of the message not 
"covered" by the DKIM signature.  So if a signature doesn't cover Subject:, 
you're fine.  Obviously there are many MUAs out there that filter/sort based on 
the Subject: tags that will be affected to some degree, but they could also 
take the same action on a List-ID: field just as easily.  And any MUA that 
orders a mailbox based on threading using References: and In-Reply-To: won't be 
affected at all.

> Again, thanks.  It's nice to see specific guidelines published as an
> RFC which we can then refer to for justification of Mailman's policy
> and features.

Glad we could be of service!

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-13 Thread Murray S. Kucherawy 
> -Original Message-
> From: Stephen J. Turnbull [mailto:step...@xemacs.org]
> Sent: Thursday, October 13, 2011 6:49 PM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> That's not true for Mailman topics, though.  I guess we can add an
> X-Mailman-Topic field to handle that.

There's movement afoot to deprecate use of "X-" in header field names.  Just 
call it "Mailman-Topic".  And if it's worthwhile, consider registering it with 
IANA.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-24 Thread Murray S. Kucherawy 
> -Original Message-
> From: Ian Eiloart [mailto:i...@sussex.ac.uk]
> Sent: Monday, October 24, 2011 7:00 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> Of course, that's DKIM friendly. But, while most mail clients don't
> expose those headers to the users, it isn't user-friendly. And, in most
> of Europe, for many lists, it isn't legal to hide an unsubscribe
> address in the headers.

Isn't "hide" a function of the MUA, not the MLM or MTA?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-24 Thread Murray S. Kucherawy 
> -Original Message-
> From: Ian Eiloart [mailto:i...@sussex.ac.uk]
> Sent: Monday, October 24, 2011 7:24 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> > Isn't "hide" a function of the MUA, not the MLM or MTA?
> 
> No. "Display" or "Expose" might be a function of the MUA. "Find" might
> be something that the user does. To hide something is to put it in a
> location where it's unlikely to be found.
> 
> As long as you know that people aren't looking there (and they're not),
> putting information in a header (other than to, from subject and date)
> is "hiding".

My point is that if using header fields is the right way to encode this 
information in a protocol sense, then the issue is really that the MUAs need to 
expose that information somehow.

I have some trouble with the assertion that making the MLM and MTA do what we 
all agree is the right thing to do constitutes "hiding".
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-25 Thread Murray S. Kucherawy 
> -Original Message-
> From: Stephen J. Turnbull [mailto:step...@xemacs.org]
> Sent: Monday, October 24, 2011 10:38 AM
> To: Murray S. Kucherawy
> Cc: Ian Eiloart; mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> The success of the IETF RFC process is due to the fact that protocol
> is built on existing practice, and compatible with it.  Asking that
> reality serve the needs of your spec is neither workable[1] nor
> compatible with the philosophy of the RFC process.

I don't have a reality suspension field in effect on this topic.  I was simply 
disputing the claim that complying with the List-Unsubscribe RFC constitutes 
"hiding" of those details.  I understand the legal issues, and so I suggest 
that bringing them to the attention of MUA vendors might be a better solution 
given the pressures of the current evolution of the email environment.

I don't claim MLMs are broken in this regard, but I do think some more modern 
thinking by all components is in order.

> Footnotes:
> [1]  Good luck getting Joe Average to give up his Outlook, and even
> better luck getting Microsoft to expose protocol headers in a sane way.

Microsoft, for example, appears to be paying a little more attention to this 
stuff than they used to as they (quietly) begin supporting things like DKIM.  
Thus, I'm ever so slightly more hopeful than I used to be.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-25 Thread Murray S. Kucherawy 
> -Original Message-
> From: Stephen J. Turnbull [mailto:step...@xemacs.org]
> Sent: Tuesday, October 25, 2011 2:50 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> I agree, and have no objection to advocacy, or to RFCs that take
> advantage of more modern thinking.  But that's very different from
> arguing that a defect in the DKIM RFC is really a problem of the
> implementations.

Well, I also don't agree with characterizing this as a defect in the DKIM RFC.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-25 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On
> Behalf Of Stephen J. Turnbull
> Sent: Tuesday, October 25, 2011 6:04 AM
> To: Patrick Ben Koetter
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> Patrick Ben Koetter writes:
> 
>  > Is it possible to register a prefix (namespace) such as mailman-. Anything
>  > below would be mailman related. Stupid idea?
> 
> Very plausible, but I suspect there are good reasons not to allow it
> in the RFC 822/1036 messaging series.  In any case, no, it's not
> possible.
> 
> There is a way to do it in other namespaces though, eg, in MIME media
> types you have the vnd.* space.

I agree.  The best you could do is just claim the "Mailman-*" space de facto by 
starting to use it, and then start registering the ones that appear to be 
useful and popular.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-25 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On
> Behalf Of Richard Damon
> Sent: Tuesday, October 25, 2011 7:27 AM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> > Well, I also don't agree with characterizing this as a defect in the
> > DKIM RFC.
> 
> I would consider an RFC that tells some people they need to violate the
> laws of their country to follow it to have a defect.

The RFC doesn't say you have to do that.

What it says is the list should re-sign if it modifies the message (or, in 
general, re-sign anyway).  So append whatever you want, just re-sign the 
message.  Are you insisting that advice is defective?

What it also says is if you want author signatures to survive MLMs, then you 
have to re-think those practices.  But nobody really expects that right now, I 
think.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-10-28 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Barry Warsaw
> Sent: Friday, October 28, 2011 3:43 PM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> >> >This also looks like a candidate for, say, a List-Approved-Date
> >> >header.
> >
> >It's not available in RFC 2369. We will have to propose 'List-Approved-Date'
> >as a new standard. Should we?

I've got a separate draft that adds to Received: fields a tag that indicates 
transitions of messages into administrative hold states (quarantining, timed 
delivery and list moderation are included in the initial list of reasons) ready 
to go.  I just missed the -00 submission deadline prior to the next IETF 
meeting in November, so it's not in the IETF datatracker but it is here: 
http://www.blackops.org/~msk/draft-kucherawy-received-state.txt.  Comments 
welcome.

The idea: When the MLM selects a message for moderation it would a Received: 
field with such a tag, and then on release the next MTA in the chain adds 
another Received: as per normal which, presumably, completes the handling chain 
in a way that the end user can see what happened (i.e., when it entered the 
hold and when it came out).

This doesn't include a mechanism for tracking who did the approval, but you've 
got that separately on your list anyway.

-MSK

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs)

2011-10-28 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On
> Behalf Of Stephen J. Turnbull
> Sent: Friday, October 28, 2011 5:46 PM
> To: Barry Warsaw
> Cc: mailman-developers@python.org
> Subject: [Mailman-Developers] Mailman headers (was Re: New RFC on using
> DKIM with MLMs)
> 
> I think that's a bad idea.  The version string should go in a *-Agent
> header, along with the agent's identity.

Agreed.

> While I disagree with having Mailman be a User-Agent, I can't actually
> say there are useful semantics to having a separate List-Agent.  Nor
> do I see a real problem with having multiple User-Agent headers, if
> multiple agents have handled the message.

I think having a message with User-Agent and List-Agent is less confusing than 
one with two User-Agents.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman headers (was Re: New RFC on using DKIM with MLMs)

2011-10-29 Thread Murray S. Kucherawy 
> -Original Message-
> From: Stephen J. Turnbull [mailto:step...@xemacs.org]
> Sent: Saturday, October 29, 2011 12:50 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] Mailman headers (was Re: New RFC on
> using DKIM with MLMs)
> 
> Who's going to be confused?  Not end users.[1]  I would think the real
> application is for an administrator or software to look at them and
> go, "Uh-oh, it's another Outlook|fml|... message" and deal with that
> agent's peculiarities.  As long as there's only one set of foibles
> associated with Outlook, and another with fml (perhaps not disjoint
> from Outlook and perhaps associated with several fml-wannabes as well,
> but consistent across those MLMs that emulate fml), you probably don't
> need to distinguish -- "MLM" vs. "end-user client" is something (ie, a
> foible) you can deduce from the agent's name and version string.

So your perspective is "why bother", basically?  That's fair, I guess, but at 
the same time, what's the harm in making the distinction?  If for some reason 
something down the road wants to indicate the two separately, this would make 
it easy.

If your concern is the cost of the process of registering "List-Agent", I'll do 
it for you.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman headers roundup

2011-10-30 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Patrick Ben Koetter
> Sent: Sunday, October 30, 2011 12:04 PM
> To: Mailman Developers
> Subject: [Mailman-Developers] Mailman headers roundup
> 
> I've created a list to sum up the current discussion/threads on the mailman
> header work.
> [...]

Nice!

For the ones that are at "Create RFC", does someone have a specific syntax they 
should follow, especially something like ABNF?  That plus a description makes 
crafting the RFC easy.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman headers roundup

2011-11-03 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Mark Sapiro
> Sent: Wednesday, November 02, 2011 2:57 PM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] Mailman headers roundup
> 
> I think the Message-ID to which you refer in the above paragraph is the
> Postfix queue ID and has nothing whatsoever to do with the Message-ID:
> header or (X-)Message-ID-Hash which is a hash of that header.

Sometimes Message-ID includes the queue ID.  That's the case with sendmail, as 
I recall.

The queue ID is also typically part of the Received: field already.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-11-15 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Barry Warsaw
> Sent: Tuesday, November 15, 2011 6:45 PM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> That's pretty interesting.  Currently MM3 doesn't add any Received
> headers, but this bug tracks that:
> 
> https://bugs.launchpad.net/mailman/+bug/885715

Excellent.

The draft is now posted: 
http://datatracker.ietf.org/doc/draft-kucherawy-received-state/

Comments welcome, ideally to the ietf-smtp mailing list.

-MSK

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Mailman headers roundup

2011-11-15 Thread Murray S. Kucherawy 
Whatever you folks decide about List-Agent vs. Mediator, I'd be happy to help 
write up an RFC draft that registers the various header field names and 
descriptions and start it on its path to standardization.

However, the IETF might want to change it to the opposite name from the one you 
pick, or even something else.  So you're quite possibly going to repeat this 
debate in their forum, so save (some of) your strength.

"Just saying."  :-)

-MSK

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] New RFC on using DKIM with MLMs

2011-11-28 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Stephen J. Turnbull
> Sent: Tuesday, November 15, 2011 8:02 PM
> To: Barry Warsaw
> Cc: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> 
> Barry Warsaw writes:
>  > On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote:
>  >
>  > >I suggest we use the term 'Mediator' as introduced by D. Crocker in
> RFC 5598  > > instead:
> [...]
>  >
>  > That makes a good case for Mediator.
> 
> +1, but only for the case of modification IMO.

Works for me.  If it includes the hostname where the mediator is running, it 
can go a long way toward debugging things like DKIM validation problems or 
other "What the hell happened to this message?" things.

But then again, if we go with the received-state idea, mailman could do what 
other MTAs do and write its name and version information in a comment in a 
Received field.

>  > >List-Approved-Date
>  > >RFC 2822 date timestamp when message was approved by
> moderator
>  >
>  > What if the message is automatically approved?  Does it get a  >
> List-Approved-Date header?  Merging with Murray's concept of Received
> states,  > it might just make more sense to put all that information
> into Received  > headers.
> 
> -1 on using "Received" for approvals.  The approval

Incomplete thought here?

If the received-state idea is adopted, a second Received: is the perfect way to 
show when something entered an approval hold and when it came out, without 
registering a new header field dedicated for this purpose.

> Also (per site or list policy) I would suggest that instead of a family
> of List-Approved-* headers, there should be a single List-Approved
> header with variable format.  If present, it MUST contain an action
> ("Approved", "Denied", "Rejected", "Held"), MUST contain "at" and a
> timestamp, MAY contain "because" and a rule ("list member",
> "moderator", "spam score exceeded threshold"), and MAY contain "by" and
> a moderator ID (arbitrary token, could be a name, a numerial ID, or
> generic tokens like "mailman" (the name of the MLM in general), "list-
> owner", "moderator").  (I'm not wedded to the field tags, of course.)
> [...]

If this is meant to be machine-parsable versus user-parsable, it'll need to be 
more rigid than that.  But I see where you're going.  Phrases in particular are 
a pain unless they're meant to be quoted strings that machines don't care about 
using.

So I guess we need to be clear on how these various new fields are expected to 
be used.

> Secret moderator IDs would serve to anonymize.

As long as the MLM keeps track of who they are so administrators can track 
actions, sure.

>  > We can't use Keywords, because that header is already used as input
> > to various functions such as the topic tagger.
> 
> Worse, it's already standardized by RFC 5322.  In general, I take a dim
> view of a MLM hijacking any headers standardized by RFC 5322; those
> headers are basically for use of *authors*, though the common practice
> of adding various tags to Subject doesn't bother me *too* much, and
> exceptions might need to be made for Date and (especially) Message-ID,
> although maybe the MLM can just add those as Resent-* fields and
> abdicate responsibility if the user did.

I think RFC5598 suggests that the MLM re-mailing should generate a new 
Message-ID and a new Date, and observes the common Subject: tagging practice, 
but I don't think anyone expects the other stuff to be renamed to Resent-* 
first.

> What's wrong with List-Topics or List-Keywords?  List-Tags is OK, I
> guess, but I think of tags as user-provided information for other users
> (not necessarily provided by the author, and not necessarily usable for
> automatic association of different posts).

As above, how are they typically consumed?  That might help to answer these 
questions.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM

2011-12-06 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Barry Warsaw
> Sent: Monday, December 05, 2011 4:54 PM
> To: Monica Chew
> Cc: Terri Oda; mailman-developers@python.org
> Subject: Re: [Mailman-Developers] feature request: one-click setting to 
> preserve DKIM
> 
> On Dec 05, 2011, at 03:50 PM, Monica Chew wrote:
> >Having worked in the DKIM-for-anti-phishing space for a couple of
> >years, there is no good way to solve the DKIM problem in Mailman.
> 
> I think this is the one big lesson from these discussions: DKIM is
> mostly incompatible with mailing lists.  Where the two must be
> integrated, some usability will likely be compromised.

It depends on your expectations.  If there's an expectation that the author's 
signature will/should/must persist through a mailing list, then I agree that 
they're largely incompatible.  If on the other hand you intend for lists to 
re-sign mail and for receivers to evaluate the message based on the list 
signature rather than the author signature, then it's entirely workable.  Of 
course, sometimes the author signature will indeed survive, and then you have 
two domains to evaluate instead of one.  Bonus!

As Monica points out, DKIM itself is oblivious to the context in which it's 
being used.

> I'm no DKIM expert by far, but it seems to me that a mailing list
> message has enough clues that a DKIM verifier could do a better job at
> helping recipients make good choices.  For example, all Mailman
> messages have a List-Id header that contains the domain name hosting
> the list server.  With re-signing, why couldn't you verify the
> signature against the List-ID host instead of the original sender?

You could.  The issue isn't that doing so is wrong or impossible.  It's simply 
that those semantics aren't built into DKIM, largely because we have no 
evidence that that's a useful test.

The ESP community has argued that third-party signatures (those different than 
the one in the From: field) shouldn't be valued any less than one that does 
match, for various reasons.  That argument was apparently persuasive.

ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do more 
than just say "domain X handled this message" (which is really all a valid DKIM 
signature tells you).  They both attempt to say things based on whether the 
domain delivered as part of a valid DKIM signature matches some identifier in 
the message, like the domain in the From: or in the List-ID field.  If Mailman 
(or an MUA, or a filter, or something) implements such checks and finds that 
it's operationally beneficial to end users do so, then it could publish that 
mechanism in an RFC or elsewhere, and people could start to use it.  The 
resistance isn't that this is a bad idea, but just that there's no evidence to 
back it up that would justify its standardization.

The trick, of course, is not just to do something like this, but to get MUA 
buy-in.  That is, when a signature validates and it presents a domain name that 
matches some identifier, change the presentation of the message to show this in 
some meaningful way.  And then make sure in doing so that you don't 
inadvertently discredit legitimate messages for which that's not true.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM

2011-12-06 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Terri Oda
> Sent: Tuesday, December 06, 2011 11:36 AM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] feature request: one-click setting to
> preserve DKIM
> 
> There were a lot of "it depends" in your email, so maybe I've mis-read,
> but it sounds to me like the long-term path of least user/list admin
> hassle for Mailman probably is to just re-sign the messages.  Except
> that there's no standard for third parties doing re-signing, and no
> one's sure how to interpret it if we do?

Right, except for the last bit.  The common practice at the moment is to 
evaluate (the reputation of) any DKIM domain whose signatures survive transit.  
They are the only bits of the message guaranteed to be "true" in some way 
(except maybe the details of the last Received: field, because it's yours).  In 
the case of author-signed mail transiting a list that re-signs, it's most 
likely I'll get the latter, but I might also get the former.  This is basically 
what RFC6377 says.

There is some automatic, intuitive desire to evaluate the message's author 
domain rather than the message's re-signer domain(s).  That's why there's all 
this pressure to tweak MLMs and other components of the infrastructure to 
permit author domain signatures to survive to the ultimate recipient.  DKIM 
doesn't require this, but intuition would really like it to be so.

It's not really true that "it depends" permeates DKIM's definition.  It's 
pretty clear what DKIM does and doesn't do.  But there's a lot of need for 
stuff just outside the edges of what DKIM does.  That's what's creating all 
this activity around MLMs, reputation, and other adjacent topics.

> Which is a pity, because this seems like a great opportunity for us to
> trailblaze and help correct a mistaken assumption in DKIM.

Which assumption is that?

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] FW: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01

2012-01-05 Thread Murray S. Kucherawy 
This effort has been started inside the IETF.  Does Mailman have any input it 
might like to contribute on updating either of these two drafts?

I've already submitted an initial review of both to the apps-discuss list:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04039.html

Perhaps this work could be combined with your desired effort to register all 
the unregistered email header fields you're currently using.

-MSK

-Original Message-
From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On 
Behalf Of S Moonesamy
Sent: Wednesday, January 04, 2012 12:18 PM
To: apps-disc...@ietf.org
Subject: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and 
draft-moonesamy-rfc2919bis-01

Hello,

I would appreciate some feedback on draft-moonesamy-rfc2369bis-01 [1] and 
draft-moonesamy-rfc2919bis-01 [2].  The I-Ds are about the List- header fields.

The changes from RFC 2369 are:

   o  URL changed to URI

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
  generating the header fields SHOULD".

   o   Replaced MTAs with mailing list managers in the sentence: "MTAs
   MUST NOT insert whitespace within the brackets" in Section 2

   o  In Section 2, client application SHOULD ignore whitespace within
   brackets

   o  Updated references

   o  Added informative reference to RFC 5064

   o  Editorial changes

   o  Removed Background Discussion

The changes from  RFC 2919 are:

   o  Removed text about the domain name system and domain ownership in
  Section 2

   o  "localhost" replaced with "invalid"

   o  Replaced MTAs with mailing list managers in the sentence: "MTAs
   MUST NOT insert whitespace within the brackets" in Section 3

   o  Case independence in Section 6 changed to case insensitivity for
  ASCII

   o  Added a paragraph in the appendix about subject tags

   o  Updated references

   o  Editorial changes

Regards,
S. Moonesamy

[1] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2369bis-01.txt
[2] http://www.ietf.org/internet-drafts/draft-moonesamy-rfc2919bis-01.txt

___
apps-discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM

2012-01-05 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Barry Warsaw
> Sent: Thursday, January 05, 2012 4:42 PM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] feature request: one-click setting to 
> preserve DKIM
> 
> Actually, I was asking about the default for personalized vs. non-
> personalized delivery.  Right now, the default is to send all users the
> same copy of the message (with some configurable batching sizes) in
> order to reduce network bandwidth, i.e. non-personalized.  By switching
> to personalization by default, we can enable VERP by default,
> personalized footers, etc.  Personalization would allow for giving
> users more choices about subject munging, footer adding, etc. but of
> course it would consume more network bandwidth and server resources to
> stitch together individualized messages.

A little optimization is possible in that scenario, namely the cross product of 
all the possible munging options that the current subscriber list has enabled.  
I don't know how easy or hard that might be to code in mailman, but I imagine 
it's possible.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] feature request: one-click setting to preserve DKIM

2012-01-05 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On Behalf Of 
> Barry Warsaw
> Sent: Thursday, January 05, 2012 5:23 PM
> To: mailman-developers@python.org
> Subject: Re: [Mailman-Developers] feature request: one-click setting to 
> preserve DKIM
> 
> Possibly, but it depends on the level of individualization.  If you're
> doing VERP or personalized footers you pretty much have to send one
> message per user.

Ah, quite right.  I was only thinking of content variants, and didn't consider 
what VERP imposes.

(Granted the body would be largely static, but you still have one envelope per 
recipient.)

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] draft-kucherawy-received-state

2012-01-09 Thread Murray S. Kucherawy 
Hi all,

Over on ietf-smtp, 
https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ was developed 
late last year.  This is an optional tweak to email Received fields allowing 
annotation of entry into special states of mail handling, such as quarantines 
or hold-for-moderation MLM actions that would help to explain large gaps in 
timestamp sequences.

I'm looking for a wider audience of reviewers and (hopefully) supporters.  If 
this sort of thing seems like a good (or terrible) idea, please do follow up 
and comment on one of these IETF lists:

apps-discuss: https://www.ietf.org/mailman/listinfo/apps-discuss
ietf-822: http://www.imc.org/ietf-822/
ietf-smtp: http://www.imc.org/ietf-smtp/index.html

How much and what kind of support is evident will guide the choice of what its 
next steps are (if any).

Thanks,
-MSK

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Presenting on anti-abuse developments

2012-04-02 Thread Murray S. Kucherawy 
Hi all,

One of the hats I wear these days is technical committee co-chair for the 
Messaging Anti-Abuse Working Group (MAAWG).  I'm looking to fill slots for our 
Berlin (June) and Baltimore (October) conferences.

If someone on the mailman development team would like to come and speak about 
developments and features of Mailman (especially the new version) that try to 
deal with abuse mitigation issues, please contact me off-list.  I have a 
request in to the executive director to find out what support we offer to 
speakers in terms of expenses, etc., so I'll pass that on once I have it to 
anyone that replies.

Thanks,
-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Password reminders

2012-05-01 Thread Murray S. Kucherawy 
Do you folks ever get complaints about password reminders sending passwords in 
the clear?  Is there an open bug about that?

Once a month I get someone nagging at me that this isn't a secure thing, 
possibly because it's a security-related mailing list (i.e., picky audience).  
My only choice in the current version is to turn off the reminders altogether.  
Perhaps it would be possible to add a switch that just turns off the password 
part?

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Presenting on anti-abuse developments

2012-05-10 Thread Murray S. Kucherawy 
> -Original Message-
> From: mailman-developers-bounces+msk=cloudmark@python.org 
> [mailto:mailman-developers-bounces+msk=cloudmark@python.org] On
> Behalf Of Murray S. Kucherawy
> Sent: Monday, April 02, 2012 2:59 PM
> To: mailman-developers@python.org
> Subject: [Mailman-Developers] Presenting on anti-abuse developments
> 
> Hi all,
> 
> One of the hats I wear these days is technical committee co-chair for
> the Messaging Anti-Abuse Working Group (MAAWG).  I'm looking to fill
> slots for our Berlin (June) and Baltimore (October) conferences.
> 
> If someone on the mailman development team would like to come and speak
> about developments and features of Mailman (especially the new version)
> that try to deal with abuse mitigation issues, please contact me off-
> list.  I have a request in to the executive director to find out what
> support we offer to speakers in terms of expenses, etc., so I'll pass
> that on once I have it to anyone that replies.

I'd like to repeat this invitation.  We've filled our slots for Berlin, but I 
have three available for Baltimore and I think any information you'd like to 
share on anti-abuse measures going into Mailman v3 would be of great interest.  
The slots are an hour long each.  If you don't think you could fill that time, 
I can possibly pair you up with another half-session.

If you'd like to make a proposal, feel free to say so here or off-list.


M. S. Kucherawy
MAAWG Technical Co-chair, Messaging

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Adding DMARC support for Mailman 3

2013-07-07 Thread Murray S. Kucherawy 
On Mon, Jul 1, 2013 at 3:44 PM, Patrick Ben Koetter  wrote:

> Before we take out to write code, I would like to ask mailman-developers
> how it
> should be done to fit best into Mailman's architecture. Here are the DMARC
> features that should go into Mailman 3:
>
> - don't allow email that comes from a domain with a DMRAC record of
> p=reject
> - take ownership of the email and send it with a From: using the
>   domain of the mailing list. (There's a patch for this for Mailman 2.1,
> which
>   might might be helpful for Mailman 3.)
> - find the authentication-results header and rewrite it as an
>   Original-Authentication-header:
>   http://tools.ietf.org/html/draft-kucherawy-original-authres-00.html
>

I'm all for experimentation and being adaptive as new things come along,
and I'm obviously supportive of the DMARC effort.  That said, I hope that
these are going to be configurable options, defaulted "off" for backward
compatibility.  This is because:

(a) the second bullet above is a significant departure from current use (as
I understand it), and fails the test of least surprise if we were going to
suddenly see that MM3 does things quite differently than previous versions
or, indeed, other packages; and

(b) I'm uneasy about Original-Authentication-Results.  As far as I'm aware
there's only a single, proprietary implementation.  Its proponents have
explained the logic to me several times, but I remain unconvinced.  I'm all
for experimentation in order to provide data for future efforts, so I don't
really object, but this shouldn't be taken as a well-vetted proposal just
because there's an (expired) draft about it.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Adding DMARC support for Mailman 3

2013-07-08 Thread Murray S. Kucherawy 
On Mon, Jul 8, 2013 at 12:26 AM, Franck Martin wrote:

> 1) may not be necessary, if mailman recognizes the bounce message as in
> section
> http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-15.8
> eg "550 5.7.1 Email rejected per DMARC policy for example.com"
> and does not increase the unsubscribe/bounce counter for the receiving
> email address. I suppose MM3 bounce processing is better than with MM2, so
> this may be already addressed.
> Some people have requested this feature, so it is fair to include it,
> rather than them having to tweak the associated MTA (which some do not have
> control).
>

I don't think the idea of telling people to include or go look for a
particular substring in the SMTP reply text will ultimately work in a
standards document, which relegates this logic to the realm of heuristics.
We've already seen resistance to that effect on the IETF lists.  We'd be
better off trying to register some enhanced status codes and asking the
community to begin using those.


>
> 3) This draft has been on the table for a while, as Murray points, one
> large mailbox provider uses it in a proprietary way, but similar to what is
> in Murray's draft. So there is experience, and as far as I know they still
> do not think it is a bad idea. Nevertheless, I think mailman should not do
> the email authentication part, but be able to recognize "true"
> authentication-result headers coming from the MTA mailman uses and be able
> to rewrite them as an OAR. This keep the logic simple, and should be
> enabled if the MTA can control Authentication-Results headers and remove
> spoofed ones. Personally I think 3) is more complicated than 2) to put in
> place correctly as it requires tight configuration between MM3 and the MTA.
>

Well, one (or two) parties have experience with OAR.  It would be nice if
this was broader, but that there is not after all this time is something I
take to mean it's not a pain point others are feeling.  It might work great
for MM3, to be sure, but they'd effectively be the broad-scale pioneers
here.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Adding DMARC support for Mailman 3

2013-07-08 Thread Murray S. Kucherawy 
On Mon, Jul 8, 2013 at 2:01 AM, Stephen J. Turnbull wrote:

>  > PS: Stephen, Murray does not work for Google, and therefore cannot
>  > change the way gmail works.
>
> I'm aware of that.  I was ribbing him for his choice of mailbox at
> Gamil.  He obviously thinks it's funny; nobody imposed it on him!
>

I'm amazed I was able to get it.  It's resulted in a lot of kudos, but also
some very interesting spam.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

2013-09-19 Thread Murray S. Kucherawy 
I really wish I could keep up with all the lists where interesting stuff is
going on.

We produced an RFC a few years ago that tries to tackle the names and
definitions of all the various roles (RFC 5598).  That document
deliberately avoided defining what a Sender is because that word has become
so overloaded as to be hyper-ambiguous.  Thus:

On Fri, Sep 13, 2013 at 12:13 PM, Stephen J. Turnbull wrote:

> Franck Martin writes:
>
>  > In the upcoming mailman 2.1.16 there has been the introduction of
>  > the optional feature author_is_list
>  >
>  > "Replace the sender
>
> Before you release, s/sender/author/, please.  When discussing
> Internet email, sender != author.  The name of the feature, "author is
> list", is an obvious falsehood: lists don't write posts, they relay
> them.  These policies do not conform to the email RFCs.  (Given the
> semantics of "From" set out in RFC 5322, they may even constitute
> copyright infringement in the absence of a license from posters
> permitting From-munging.  But that's not the topic here.)
>

I disagree.  Formally, Mailman is creating a new message using (likely) a
large portion of the original message.  Unless the output is completely
identical, Mailman is an Author.  So I think the name is right, unless you
want to tie the name of the feature to the list's configuration, and I'm
sure you don't want to do that.

This isn't absolute of course.  There are mushy topics like "Did the
Message-Id change?"  (One could argue that if the Author changes, a new
Message-Id should be generated.)  "Should a new Message-Id have been
generated?"  (Yes, if there was any meaningful content change whatsoever.)

Either way, I think the name is right as-is.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

2013-09-19 Thread Murray S. Kucherawy 
On Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull wrote:

> That's nonsense.  There's no reason to do this in the absence of
> correct DKIM signatures by Mailman or its MTA, and every reason
> (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so.  Of
> course if the point is to violate the RFCs, then this will still
> violate the RFCs without the MTA and DNS changes.  But surely that's
> not what Franck means by "useful".
>

I'm familiar with RFC 822 and up, but can you specify what exactly is being
violated?  I'm not saying I disagree, I just want to go to the
reference/rule you have in mind.

If the concern is with replacing the From: field on a relayed message, then
one could argue Mailman is issuing a new message anyway, so it's free to
replace or rewrite anything it chooses.  Again referring to RFC 5598, it's
a Mediator, not a Relay, though it could also be configured to act as a
Relay.  But if it were doing that, DKIM signatures would almost always
survive.

If it's something else, I'd like to understand.


The only real alternative to DKIM signingby Mailman or its MTA is to
> pass the original message through, optionally with additional headers
> (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing
> signatures won't be corrupted.
>

Relay vs. Mediator mode, basically.


>
> There is an alternative to From-munging, though, which is to
> encapsulate the whole message (either as message/rfc822 MIME type, or
> as a one-message digest).  Then the Mailman host can DKIM sign the
> wrapper message without invalidating the signature on the main
> message.  In theory this could also be done with a multipart/mixed
> (*not* multipart/digest), with a structure like
>
> multipart/mixed
> text/plain; Mailman list header
> message/rfc822
> text/plain; Mailman list footer
>

Right, that's an option.


>
> I have no idea what MUAs would do with that, though. :-(
>

Me either.


>
>  > All of this leads me to think that making this available to list
>  > owners should be an installation decision rather than being done by
>  > default.
>
> If the Mailman host is using DKIM, then list owners will definitely
> want the option available.  So site owners should have to make a
> conscious decision to shut it off.  On the other hand, since it does
> involve a serious systematic RFC violation, I think it would be a good
> idea to eliminate the DEFAULT_AUTHOR_IS_LIST option.  Ie, require list
> owners to set it explicitly, or site owners to hack code.
>

I definitely agree that it should be off by default as it violates the
Principle of Least Astonishment.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

2013-09-25 Thread Murray S. Kucherawy 
On Sun, Sep 22, 2013 at 2:12 PM, Barry Warsaw  wrote:

> End users just care about how the email looks in their mail readers.  I'm
> concerned that this will be a nice, RFC-compliant feature that makes things
> easy and workable for all the automated systems involved, but will look
> horrible to end-users and just make them upset.  If that's the case then
> IMHO,
> it a failure.
>
> OTOH, maybe we won't know for sure until it gets *a lot* more testing.
>  But I
> think it's a mistake to say "well, we just have to force MUA developers to
> catch up".  As we've seen with something presumably as simple as
> reply-to-list, it (almost) never happens.
>
>
We as developers and standards people often avoid engaging UI people (MUAs,
in our case) and issues specifically because it's a space that doesn't
follow rules, which is what we're used to.  That partition allows us to be
able to declare victory on our side of the line most of the time, but it
leaves us with the frustrations you've described here.

I wonder how long we can hold out before we start trying to drag them into
our conversations, which might be the only way to solve these pain points
long term.  It seems to me that Gmail, Yahoo Mail, Thunderbird, etc., must
have either a team or an individual that spends time thinking about and
testing user-visible solutions to these problems, so perhaps it's time to
start asking them for help.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Thinking about list footers

2014-05-30 Thread Murray S. Kucherawy 
Right now list footers are a common feature of Mailman and other MLMs.  The
typical way of doing this is to just append some content, probably after
"--", that indicates the location of archives and maybe some administrative
information (unsubscribe instructions, for example).

What's the expertise on the idea of adding footers in a new MIME text/plain
part rather than just bolting it onto the text as-is?  (Or is that already
done?)  What do MUAs generally do with multipart text/plain bodies?

And along those lines, do any MUAs do useful things with the various List-*
fields, other than permitting one to sort on them?

I'm brainstorming on some possible solutions to DMARC and DKIM matters, and
I don't want to reinvent any wheels.

Thanks,
-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Thinking about list footers

2014-06-02 Thread Murray S. Kucherawy 
On Sat, May 31, 2014 at 4:30 AM, Stephen J. Turnbull 
wrote:

> Also, the last time partial signatures came up, it was pointed out
> that there are *no* MUAs that differentiate between signed parts and
> unsigned parts.  You don't get a warning when your eyes move from a
> signed part to an unsigned part or vice-versa the way you do when
> following a link from an HTTP URL to an HTTPS URL in a browser.  The
> DKIM advocates have not liked the idea of signatures that don't apply
> to the whole message at all.
>

All true, but that's mostly specific to MUAs.  There's nothing saying a
filter of some kind could do something special with appended content when
it senses a message that's bigger than what was signed.  The library in
OpenDKIM does make it easy to spot these, for example, and can tell you
stuff like which header fields were added or modified and in what way, or
how much of the content was signed and how much wasn't.

We didn't intend for this to be used by MUAs, however, so to some degree
they're doing what we expected.

The reason I asked is that there's a proposal for a DKIM canonicalization
that could survive modifications if the modifications are entirely in new
MIME parts.  Thus, if an MLM altered the message strictly by adding parts,
the added parts could be easily isolated by this method, and the remainder
verified against an author signature that should still validate (modulo
Subject field changes).  So you'd have a DKIM signature from the author
domain that validates on the original author content (the final content
minus the added part), and a DKIM signature from the list domain that
validates on the modified content.  I'm trying to figure out if that would
be useful at all, but it sounds like MUAs are the showstopper there.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Thinking about list footers

2014-06-09 Thread Murray S. Kucherawy 
On Wed, Jun 4, 2014 at 8:39 AM, Stephen J. Turnbull 
wrote:

> If I understand you correctly, we actually already have the mechanics
> for this in place.  Most sites like Yahoo! allow you to whitelist a
> sender.  This could be extended to allow whitelisting based on the RFC
> 2369 List-Post field (simple to implement but requires subscriber
> action if the List-Post address changes) or the RFC 2919 List-Id field
> (complicated because it doesn't correspond directly to any domain,
> you'd need some kind of DNS support which would be a bad idea to
> special case lists).
>
> Then just DKIM sign, and have the destination check for List-Post (not
> from) identity alignment.  Not as much trouble as you suggest.
>
> Murray, is there something here?
>

Unless I'm missing something (which is likely given how little caffeine has
hit my system so far this morning), this reduces to whitelisting the DKIM
signing domain which in this case would be the list operator's domain,
correct?

If that's the case, you still have the scaling problem of populating the
whitelist.  How would Yahoo! go about doing that, for example?  They claim
at least 30,000 such cases that ideally would land in that list
automatically somehow.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] MIME footers

2015-02-24 Thread Murray S. Kucherawy 
Hi there,

A while back I introduced an experimental draft about DKIM signature
generation that's sensitive to MIME structure.  I'm planning to revisit and
maybe even implement this to get some experimentation going.  It would help
guide the design work if I knew this:

How does, or how would, Mailman add a footer to a MIME message?  My guess
is that it would make a multipart that contains the original message
(message/rfc822) as one part and the footer as a text/plain in a second
part, but that's purely a guess.  Equally important: What would it do to
sign a message that's not MIME to begin with?  Could it be compelled to
turn it into a MIME message, perhaps treating the original as a single-part
text/plain message and doing the same wrapping I described?

Thanks,
-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MIME footers

2015-02-27 Thread Murray S. Kucherawy 
On Tue, Feb 24, 2015 at 2:08 PM, Daniel Kahn Gillmor 
wrote:

> > Equally important: What would it do to sign a message that's not MIME
> > to begin with?  Could it be compelled to turn it into a MIME message,
> > perhaps treating the original as a single-part text/plain message and
> > doing the same wrapping I described?
>
> Mailman doesn't usually sign messages.  What kind of signatures are you
> asking about?
>

Sorry, by "sign" I meant "add a footer".  I probably said "sign" because
this is related to some DKIM work I've been planning, and the morning's
caffeine was already wearing off.

Thanks for that detailed answer (and Barry for his followup).  It's
precisely what I was looking for.

How absurd would it be to propose a flag for Mailman that would take your
first case (non-MIME, or single-part text/plain) and convert it to a
multipart/mixed with a child part of the original text/plain, and then
apply the algorithm you have?

The impetus here is DKIM survivability across lists.  Suppose we had a DKIM
canonicalization that was MIME-aware, so that it could sign the specific
MIME parts or sets of parts.  That signature would fail on the message as a
whole -- with the footer part added -- but could in theory pass if an
appended part were omitted from canonicalization.  To put it in context,
suppose there were a DKIM canonicalization where the signer signed (using
your examples) the CDE message; the receiver gets FGHI which fails, but
also has enough information to know that merely verifying FGH will pass; it
then knows that FGH was "legitimate" and I was added post-signing, and may
or may not be "safe" (for some value thereof) content.

What I'm worried about with such a design is the trivial text/plain
message.  Obviously merely appending the footer destroys any hope of
validating only the original content.  We'd have to entertain the idea that
Mailman would make the simple message into a multipart/mixed + text/plain,
then append the footer part and sign that; the verifier would drop the
footer and then strip off the MIME to see if it can verify the original
signature that way.  That seems like its easy to get wrong, though it's
likely to be a very common case.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MIME footers

2015-03-10 Thread Murray S. Kucherawy 
OK, this time I was properly caffeinated, but that also meant I had a short
attention span.  :-)  Sorry for the long delay replying.

On Fri, Feb 27, 2015 at 12:55 PM, Daniel Kahn Gillmor  wrote:

> One issue this process brings up is that it's now necessary to treat
> pretty much every part of the message as though it is
> multipart/signed -- that is, it needs to be handled bytewise opaquely,
> on pain of breaking the DKIM header.
>
> We already know that there are tools that do things like re-encode
> messages from base64 to q-p, or change character sets, or just re-flow
> long lines (FSVO "long") in the mime boundary subheaders.  They're not
> supposed to do this with multipart/signed messages, because the RFCs
> point out that opaque handling is required, but they sometimes break
> them anyway.  I imagine the same risk would now apply to all DKIM-signed
> messages using your scheme.
>

The proposal I cobbled together (which is now in an expired IETF draft; I
need to post an update so it's visible again, late this month probably)
actually required that the canonicalized form of a MIME part is the fully
decoded form.  That way, 7bit, 8bit, q-p and base64 re-encodings would have
no effect on the produced hash, and the signature would survive.
Theoretically.

The tricky part is going to be the question of how to sign something that's
not MIME, and then how to handle stuff like MIME preambles and postambles.
There's going to be a lot of fussing over what various MUAs do with such
content, and whether that should be signed, and so on.  The best I think we
can do is sign the actual part content, and be exceptionally clear about
what leading and trailing spaces get included or omitted, etc.  One byte of
ambiguity and you're toast.  That said, DKIM itself did a pretty good job
of this, so we have that to use as a model.

And, if I may reply to some other points made on this thread:

As to the question of crusty MUAs, I'm inclined to agree with the
"vanishingly small" characterization, except that as is typical in these
situations, it's a rather vocal small.  I know for example that alpine
shows the preamble even though one could argue that it's not a usable part
of a MIME message.  Certainly the goal is to be as incremental and
non-disruptive as possible, so I'd be inclined to do what someone
suggested, which is to make it a flag (a list flag, or maybe a user flag),
defaulting to something sane.  But at some point we have to give up here, I
feel; stuff like this becomes an attack directly on the MUA, and I would
argue that there's only so much an MLM can (or should) do to protect users
from crappy software.

I had forgotten about message headers (i.e., prepended text).  Are those
common?  I had thought pretty much everyone uses footers only.  It's
certainly the case that this proposal only deals well with footers.  The
specific algorithm is to construct a MIME tree and sign parts of it;
specifically, sign all of it, and then verify all of what you get first.
The changed part would be in a new leaf, which is easy to exclude from hash
generation.  Excluding a part at or near the top might not be so
straightforward.  Anyway, that's an answer to Mark's "how do you determine
what got signed?" question.

To Mark's second question, the idea is that the final receiver would get
two signatures: The first was added by the author and signed the
author-generated content, and the second was added by the MLM and included
the author content plus a footer in such a way that the two are separated
in a structured way (MIME boundaries) in contrast to DKIM's simple (and
deprecated) "l=" tag.  The MLM signed the whole thing, while the author
signed only the original content.  We like to say that DKIM allows a domain
to take some responsibility for a message and its content; you could then
determine for which parts each of the two parties is responsible.
Translate this into the DMARC world: I could now tell that this message was
signed by the author, and this added part was signed by an MLM which
probably means the MLM added the extra part, which contains only text, so
now DKIM passes, and DMARC is satisfied.

A "real world" example: I'm A at a domain with a "reject" DMARC policy,
mailman's running at B, and subscriber C runs at a domain that checks DMARC
inbound.  I send mail to a list at B, and sign it with my domain's
signature; the MLM at B appends a footer in the MIME way and re-signs a
message using this list-aware canonicalization; C confirms that (1) most of
the content is signed by A, (2) one added text/plain or text/html part was
added by B, (3) B doesn't have a scary reputation or isn't blacklisted, and
(4) B's signature covered the added part; C considers that a DKIM pass for
A, which is "aligned" (in DMARC terms), and thus DMARC is satisfied.

In theory, to deal with the non-MIME case, we could invoke DKIM's "l=" tag,
but it would be an understatement to say the community would be pretty
allergic to that idea.

-MSK
___

Re: [Mailman-Developers] MIME footers

2015-03-19 Thread Murray S. Kucherawy 
On Tue, Mar 10, 2015 at 6:51 PM, Stephen J. Turnbull 
wrote:

>  > It's certainly the case that this proposal only deals well with
>  > footers.  The specific algorithm is to construct a MIME tree and
>  > sign parts of it; specifically, sign all of it, and then verify all
>  > of what you get first.
>
> I think this is the wrong algorithm.  I suspect that "the community"
> is going to be almost as leery of this proposal as they are of l=, and
> for similar reasons.  Given that, I really think the right thing to do
> is to take the MIME structure seriously and sign part-by-part.
>

The difference between this idea and "l=" is that there's still a signature
covering the added part, that of the MLM.  It has taken "some"
responsibility (where "some" means "an unspecified amount, but not zero")
for the added content.  By contrast, "l=" leaves the appended bit unsigned.

This scheme does sign individual parts as well, and then does merged
signatures in each non-leaf node (corresponding to a "multipart/blah" node
in the tree).  This makes it easy to figure out below which non-leaf
node(s) a change occurred.  If you have two signatures in-hand (one author,
one mediator), it's fairly straightforward to isolate the change and then
figure out if you want to render/scan/remove/whatever it.

-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9