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 Terri Oda 

On 12/06/11 11:17, Murray S. Kucherawy wrote:

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!


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?


As a developer, this sounds the makings of one of those life-sucking 
projects you shouldn't touch with a 10-foot pole unless you're getting 
paid to define and defend a standard.  There's no guarantee that 
anything we choose to do will ever be considered correct, and it could 
wind up being a lot of arguing and wasted effort at a time when I think 
we're better off just getting mailman 3 out the door.


Which is a pity, because this seems like a great opportunity for us to 
trailblaze and help correct a mistaken assumption in DKIM.  Maybe the 
other developers are a lot more excited about that than I am and willing 
to take the risk of implementation, but maybe we should just keep an eye 
on the expansion of DKIM and revisit this issue after Mailman 3 is released?


It sounds like our best option for the near future is to write up a nice 
little document describing the issue, Monica's fix for lists where DKIM 
is essential, and leave it at that as far as code goes until things move 
a bit closer to consensus on how DKIM should handle mailing lists 
long-term.  As a bonus, a nice little document could also be usable with 
2.1! If anyone needs wiki author permissions to do this, let me know.


 Terri
___
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

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

2011-12-06 Thread Mark Sapiro 
On 12/5/2011 10:58 AM, Monica Chew wrote:

> For context, I work at Google on Gmail spam, and one of the things we've
> been doing as an anti-phishing measure is enforcing that mail from certain
> highly-phished domains must be signed with the DKIM key of the purported
> sender. We started this several years ago for just ebay and paypal (
> http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html)
> and for the last couple of years have been trying to do it for
> google.comand a handful of other domains as well.
> 
> A side effect of this has been that mailing-list mailing has been
> particularly difficult to classify. We've mostly solved the problem for
> groups that we host, but external mailing lists have been a continual
> challenge. As a result, many Google employees who want to participate in
> standards and open source communities have been unable to (see for example
> http://lists.openid.net/pipermail/openid-general/2009-June/018364.html,
> where both mail from Google and Facebook employees were not delivered to
> openid gmail members) with their standard mailing address.


It seems you could solve this particular problem by allowing gmail users
an option (non-default) to receive such mail with a "phish" warning
rather than not receiving it at all.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
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 Barry Warsaw 
On Dec 05, 2011, at 05:12 PM, Monica Chew wrote:

>> Mailman 3 supports list-styles, which in theory are composable.  Coming up
>> with a good ui for that is a whole 'nuther issue, but the core could support
>> something like this fairly easily.
>
>Could you elaborate more? I couldn't turn up documentation on this. If
>you mean sufficient hints in the headers to the MUA render subject
>tagging and unsubscribe footers unnecessary, then I agree.

Hi Monica.  I was really just talking about a way to make the setting of list
configuration variables more user friendly.  A "list style" is just a
collection of settings that is applied to the list when it's created.  A style
could also in theory be applied to a list after it exists.  Styles have names,
so you could make one available to list owners called "make-dkim-not-break" or
some such :).

This is the current documentation on that feature:

http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/app/docs/styles.rst

Cheers,
-Barry
___
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 Barry Warsaw 
On Dec 06, 2011, at 10:17 AM, Murray S. Kucherawy wrote:

>> 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!

My own personal feeling is that having lists re-sign messages is the best
expectation to put forward.  You're subscribed to a mailing list, so you trust
that list much more than you trust the senders on that list.  So having the
mailing list site re-sign the outgoing messages seems to me to be best
practice.  My inclination is that removing the original author's signature
first is not entirely inappropriate.

Note too that Mailman supports anonymizing list traffic to the extent that it
would wipe out the original From header.  Some lists turn this on for a higher
degree of privacy than you see on most open discussion lists.  In that case,
the From header would look like it's coming from the mailing list, and then it
would make the most sense to remove any original signature and leave only the
list's signature.

It seems to me that relying on From header signing of mailing list messages
just isn't that useful.

>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.

In that case, it would be interesting and feasible for you to perhaps line up
some mailing list sites to enable this and gather some statistics.  It would
be pretty easy to do (I think) in Mailman 3 (though that's unreleased) and
probably not hard to do in Mailman 2.

>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.

Right.  So, Gmail is probably the 800lb MUA gorilla here.  Monica, do you have
any thoughts on how you could run such an experiment and find out what is most
useful to your users?

Cheers,
-Barry
___
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 Barry Warsaw 
On Dec 06, 2011, at 12:36 PM, Terri Oda wrote:

>As a developer, this sounds the makings of one of those life-sucking projects
>you shouldn't touch with a 10-foot pole unless you're getting paid to define
>and defend a standard.  There's no guarantee that anything we choose to do
>will ever be considered correct, and it could wind up being a lot of arguing
>and wasted effort at a time when I think we're better off just getting
>mailman 3 out the door.

I agree completely. (he says, still struggling with REST
authentication/authorization :).

>Which is a pity, because this seems like a great opportunity for us to
>trailblaze and help correct a mistaken assumption in DKIM.  Maybe the other
>developers are a lot more excited about that than I am and willing to take
>the risk of implementation, but maybe we should just keep an eye on the
>expansion of DKIM and revisit this issue after Mailman 3 is released?

What Mailman 3, and to some lesser extent MM2 can do today, is to provide a
framework for experimentation, for those folks who are motivated to improve
the current situation.  Fortunately, I think MM3 has everything you'd need to
do that.  A team working on improving things should be able to distribute a
plug-in that implemented their experiment for sites that wanted to
participate.

-Barry
___
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 Florian Fuchs 
Hi, 

> users will balk at having the subject line tags removed, and many list 
> owners will balk at having unsubscribe footers removed, 

Agreed. OTOH, if this were yet another setting, it would be the list owner's 
decision to use it or not.

> That said, we've talked a lot about having simplified interfaces for 
> quick list administration and interfaces designed for specific purpose 
> lists. It seems like this might fit in nicely with some of those ideas, 
> so I'm definitely not adverse to keeping it in mind as an interface 
> option if there's evidence that this would be useful to enough list owners.

I also think it's worth considering. For instance, those settings could be part 
of one or more "DKIM compatible" list templates. But even if we "bundle" this 
inside a template it will probably still cause a bit of confusion (how many 
people will know what the label 'DKIM compatible' means?). 

Another idea: We could still let the person installing the web-ui decide if 
they want to make those options available. Maybe by means of an additional 
django app that adds this functionality to the settings.

Florian


___
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 Monica Chew 
Hi Terri,

On Tue, Dec 6, 2011 at 11:36 AM, Terri Oda  wrote:
> 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?

I came up with something for groups that we host and would love to see
another MLM implement it. It is a header that stores a copy the
original authentication results as received by the MLM (or any
forwarder, really) before destroying the signature. Respecting this
header requires the expanded message to be re-signed by a trusted
forwarder (easy in my case, since googlegroups.com uses its own DKIM
key) -- so long as this header exists and is signed by a trusted
forwarder, then on inbound we trust the original authentication
results and don't care if the message is signed with a DKIM key that
doesn't match the From.

Maintaining the list of trusted forwarders then becomes a problem for
receivers, but it's one that's a lot more manageable than today's
situation because as Murray points out, many reputation systems have
already been developed around DKIM.

> As a developer, this sounds the makings of one of those life-sucking
> projects you shouldn't touch with a 10-foot pole unless you're getting paid
> to define and defend a standard.

That is not out of the question.

> It sounds like our best option for the near future is to write up a nice
> little document describing the issue, Monica's fix for lists where DKIM is
> essential, and leave it at that as far as code goes until things move a bit
> closer to consensus on how DKIM should handle mailing lists long-term.  As a
> bonus, a nice little document could also be usable with 2.1! If anyone needs
> wiki author permissions to do this, let me know.

Would that go here? http://wiki.list.org/display/DOC/3+List+administrator+tasks
I'm highly motivated to help :)

Thanks,
Monica
___
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 Monica Chew 
On Tue, Dec 6, 2011 at 1:30 PM, Mark Sapiro  wrote:
> On 12/5/2011 10:58 AM, Monica Chew wrote:
>
>> For context, I work at Google on Gmail spam, and one of the things we've
>> been doing as an anti-phishing measure is enforcing that mail from certain
>> highly-phished domains must be signed with the DKIM key of the purported
>> sender. We started this several years ago for just ebay and paypal (
>> http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html)
>> and for the last couple of years have been trying to do it for
>> google.comand a handful of other domains as well.
>>
>> A side effect of this has been that mailing-list mailing has been
>> particularly difficult to classify. We've mostly solved the problem for
>> groups that we host, but external mailing lists have been a continual
>> challenge. As a result, many Google employees who want to participate in
>> standards and open source communities have been unable to (see for example
>> http://lists.openid.net/pipermail/openid-general/2009-June/018364.html,
>> where both mail from Google and Facebook employees were not delivered to
>> openid gmail members) with their standard mailing address.
>
>
> It seems you could solve this particular problem by allowing gmail users
> an option (non-default) to receive such mail with a "phish" warning
> rather than not receiving it at all.

Ah, yes, the old trick of relying on users to correctly identify phish
:) Unfortunately this rarely works well in practice. If the email
looks good (e.g., the spammer just copies a legitimate message and
replaces the login link with a phishing site) then most people
typically don't notice that the URL is a phishing site. Some users
even dig these out of their spam folder, even though the message has a
big red banner at the top.

In any case, a non-default setting is not going to solve the problem
of senders from highly-phished domains to communicate with gmail and
yahoo users through mailman. How would the list members even know to
change this setting?

Thanks,
Monica
___
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 Monica Chew 
> My own personal feeling is that having lists re-sign messages is the best
> expectation to put forward.  You're subscribed to a mailing list, so you trust
> that list much more than you trust the senders on that list.  So having the
> mailing list site re-sign the outgoing messages seems to me to be best
> practice.  My inclination is that removing the original author's signature
> first is not entirely inappropriate.

This is why Google Groups removes incoming DKIM signatures and
re-signs, because chances that the original signature survives are
vanishingly small given most people's list settings.

> Note too that Mailman supports anonymizing list traffic to the extent that it
> would wipe out the original From header.  Some lists turn this on for a higher
> degree of privacy than you see on most open discussion lists.  In that case,
> the From header would look like it's coming from the mailing list, and then it
> would make the most sense to remove any original signature and leave only the
> list's signature.

If From is wiped out, great! Problem solved, at least for me.

>>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.
>
> Right.  So, Gmail is probably the 800lb MUA gorilla here.  Monica, do you have
> any thoughts on how you could run such an experiment and find out what is most
> useful to your users?

In a sense we are already experimenting here. For example, this year
there are new UI warnings when the payload From says gmail, but the
message is not signed by Gmail
(https://mail.google.com/support/bin/answer.py?answer=185812).[1] This
either appears as a "this message was sent via "
informational bar or more serious warning, "this message may not have
been sent by f...@gmail.com", if the message doesn't authenticate at
all. Needless to say this is affecting lots of list traffic, and many
people don't like it:

http://snowulf.com/2011/06/29/gmail-thinks-this-message-may-not-have-been-sent-by-you/
http://www.yellowjug.com/how-to/gmail-phishing-alert-mailman-mailing-lists-spf-record/
http://www.drake.org.uk/2011/06/googles-new-gmail-phishing-detection-system-hates-mailman/

The pipe-dream fix for this, at least as far as mailing lists go, is
to do better mailing list detection on the recipient side and maintain
a list of lists that the user belongs to for suppressing warnings. We
can't just ignore all mail that has a List-Id, though, because that's
much too easy to forge.

Thanks,
Monica

[1] Why are we doing this? Well, it turns out that account hijacking
has been a huge problem in the last couple of years, and along with
theft of contact information phishing scams have gotten more
sophisticated, appearing to come from people that you know. Since
Gmail signs all outbound mail adding warnings was one easy way to warn
users when they get mail from someone pretending to be their contact
but not actually coming from Gmail.
___
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 topreserve DKIM

2011-12-06 Thread Mark Sapiro 
Monica Chew wrote:
>
>In any case, a non-default setting is not going to solve the problem
>of senders from highly-phished domains to communicate with gmail and
>yahoo users through mailman. How would the list members even know to
>change this setting?


The same way they now know that they aren't seeing this mail.

The same way they ultimatly figure out that they never receive copies
of their own posts to the list. BTW, you may be interested in the 3rd
paragraph of the answer at .

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
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 topreserve DKIM

2011-12-06 Thread Mark Sapiro 
Monica Chew wrote:
>
>This is why Google Groups removes incoming DKIM signatures and
>re-signs, because chances that the original signature survives are
>vanishingly small given most people's list settings.


And it is fairly simple to configure a Mailman installation to do the
same, but this won't satisfy you unless the list is also anonymous.

What do you say to some other service that applies the same policies as
Gmail when they complain their users don't receive Google Groups mail
from some senders?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
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 topreserve DKIM

2011-12-06 Thread Monica Chew 
On Tue, Dec 6, 2011 at 4:23 PM, Mark Sapiro  wrote:
> Monica Chew wrote:
>>
>>This is why Google Groups removes incoming DKIM signatures and
>>re-signs, because chances that the original signature survives are
>>vanishingly small given most people's list settings.
>
>
> And it is fairly simple to configure a Mailman installation to do the
> same, but this won't satisfy you unless the list is also anonymous.
>
> What do you say to some other service that applies the same policies as
> Gmail when they complain their users don't receive Google Groups mail
> from some senders?

I would say the same thing (switch domains), although I do not get
complaints from Yahoo users that their openid messages are not
appearing from Paypal senders, since I don't work for Yahoo. Yahoo is
applying the same DKIM policies as Gmail for Paypal, so I assume it is
also a problem for them.

Thanks,
Monica
> --
> Mark Sapiro         The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>
___
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 Stephen J. Turnbull 
Barry Warsaw writes:

 > My own personal feeling is that having lists re-sign messages is the best
 > expectation to put forward.  You're subscribed to a mailing list, so you 
 > trust
 > that list much more than you trust the senders on that list.

But as Monica points out, sometimes you need to evaluate whether you
trust the sender, because otherwise you need to trust *all* of the
list's competence to evaluate senders, congruence of the list's trust
policy with your own, *and* the honesty of the list's host
adminstrators.

 > So having the mailing list site re-sign the outgoing messages seems
 > to me to be best practice.  My inclination is that removing the
 > original author's signature first is not entirely inappropriate.

But that doesn't work in the case in point, unless you also change the
from field to reflect the list's domain.

What do these DKIM-strict domains do with digests?  Do they actually
check the content (ie, individual messages) for source domain and
verify their DKIM signatures?

If not, just have those people who aren't getting messages turn on
digest mode with maximum frequency. :-)

Of course, all the phishers out there are reading this message, and
will shortly be using this technique to phish gmail users, so you'll
have to extend DKIM checks to the content of digests and forwards

What really ought to be done is to format secured messages as
multipart, and sign the overall header "From" and individual parts
(perhaps identified by some kind of content ID).  Then have the *MUA*
(not the MTA!) check for alleged sender, and for highly-phishable
alleged senders display *only* authenticated portions (plus maybe
buttons to see unauthenticated content at user option).

Dream on, Steve ...
___
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