[Mailman-Developers] dkim and email list software

[Daniel Black]

Hey Stephen and others,

On Friday 09 October 2009 22:55:22 Stephen J. Turnbull wrote:
>  > Apart from the assertions of mailing list software developers I'm
>  > yet to receive a strong assertion from list operators or
>  > users.
> 
> Er, do you think we write open source purely out of charity?  We are
> all operators and users ourselves.
quite right. sorry.

> (Non-developer) users and list
> operators?  See
> http://wiki.list.org/display/DOC/From+field+displayed+by+Microsoft+Outlook
> for what they think of the kind of display the munging you suggest
> produces.  (The point is it's a FAQ; they *do not* like it.)  And can
> you imagine what that will look like when combined with the munging
> you suggest Mailman do to fake out ADSP?

good point. Though seeing it suggests that maybe ADSP could cover Sender: and 
at least some users with MUA's that display things a little ugly could tell 
the difference between a spoofed email on a mailing list they subscribe to.

>  > Even less forthcoming is the reasons the lack of acceptability that
>  > could guide standards or implementations.
> 
> 1.  Spoofing authorship is what the phishers and the spammers do.
>     We're the good guys, remember?  Note that the name of the standard
>     you are trying to promote here is *Author* Domain Signing Policy.
>     What that means is that the list's domain is claiming authorship
>     of the post.  This is problematic in any number of ways.
> 
> 2.  Authorship information is lost, or at best obscured.  You point
>     out that most MUAs don't present List-* headers.
which I'm working on btw http://reviewboard.kde.org/r/1768/
>     Well, they don't
>     present Sender or In-Reply-To either (except for Outlook).
do you think MUAs should show Sender and/or Reply-To?
if so would making mailman set these to the list address be acceptable for 
users?
>     You're
>     either in the From header, or the users don't know about it.

> 
> 3.  Sophisticated users filter on From.  This breaks the filters
>     bigtime once, and makes them more fragile forever after.
> 
> 4.  It's ugly.

Thank you for verbalising these four reasons. I accept all of these as reasons 
for not changing the From address and are unlikey to mention it again.

>  > there's a development cost that I'll consider contributing to but I'm
>  > not going to develop stuff that has no change of being accepted.
>  > I will consider writing patches for:
>  > 1. global dkim-friendly= true to disable list modifications parameters
>  > 2. From: rewriting
> 
> 1.  dkim-friendly is CAN-SPAM unfriendly.  Specifically, best practice
>     (and maybe the law AIUI) requires you to put an unsubscribe notice
>     in somewhere.  As you point out, the List-Unsubscribe header just
>     won't do....
This can probably be accounted for by DKIM l= tags (the signed length is..) on 
the sender's behalf and still allow additions of unsubscribe notices. If I 
account for this provision would it be considerable?

(cut other information that I generally accept - thank you)

>  > A proposal for author domains to authorize third party lists is in
>  > development. http://mipassoc.org/pipermail/ietf-dkim/2009q4/012592.html
>  >
>  > It does place a large burden on author domains to deploy DNS records
>  > pre- presenting every list their user base send email too.
> 
> So it certainly loses in my use case: I run support lists.  I really
> don't think someone whose editor has crashed and wants to know if they
> can recover the data they were editing is going to wait for IT to
> deploy DNS records before posting.

true, though automated techniques may help http://tools.ietf.org/html/draft-
kucherawy-dkim-reporting-05. I'll ask Murray about the future here.

I'm a lot more included to support your LDSP proposal scoped with security 
concerns addressing forgery and reputation and/or a sender domain signing 
practices document.
 
>  > > The only real problem with this is getting the big ISPs to implement,
>  > > but that's nothing new.  In fact if it's as easy as adding routines to
>  > > process the RFC 2369 + RFC 2919 set of headers "just like" ADSP
>  > > handles "From:", I bet most would be happy to sign on.
>  >
>  > So this is for mailing list that send though big ISPs that can't
>  > apply their own DKIM signatures? Not totally sure what you mean
>  > here though signing is the easy part compared to applying filtering
>  > on verification results.
> 
> No, my mailing lists, and those like them, can deploy signatures and
> DNS easily enough.  The question about the big ISPs is will they
> bother to do something to make things more comfortable for discussion
> lists.

Is this a matter of:
1. technology standardisation - (LDSP, DKIM Third-Party Authorization Label, 
Sender DSP)
2. deployment practice standardisation - http://tools.ietf.org/html/draft-
ietf-dkim-deployment-08#section-6.3
3. deployment promotion - inclusion in, for example, mailman installation 
manual / site administrator documentation
4. ensuring DKIM verification tools development supports this.
5. some marketing / guides for ISPs with respect to DKIM

There are other's battling in consideration of mailing lists (and are more 
sensible than me).
http://mipassoc.org/pipermail/ietf-dkim/2009q4/012596.html

Many would love to have your involvement there if you're interested.

-- 
Daniel Black
Infrastructure Administrator
CAcert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20091010/6414bce3/attachment-0001.pgp>