Re: [Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Michael Thomas writes:

 > I'm not saying I think that resigning is a Bad Thing, I'm saying that it's
 > speculative whether it's a Good Thing. You seem to keep ignoring the
 > inherent attack involved with resigning:

Have you actually read my posts, or just enough to feel defensive?

I have specifically referred many times to the user-list trust
relationship implicit in a double-opt-in list.  I have provided
examples of how the receiving system can acquire information about
such relationships, as well as acknowledging that getting such
information is a nontrivial problem in the context of busy admins and
slow implementation cycles.

The standard specifies that whether to trust a signature is a local
policy decision.  It seems to me that Mailman's decisions about
whether to put signing and verification capabilities into Mailman
itself will depend on the developers' estimate of whether list
signatures will be trusted in those local policies.  It seems to me
that Mailman's decisions about how to default the signature-stripping
functionality depend on our estimate of whether broken signatures will
be given negative weight compared to no signature.

My position is that Mailman lists[1] SHOULD participate in the DKIM
protocol, because I think that if Mailman lists are important to
users, they will respond to DKIM-related obstruction of their traffic
by demanding that their MTAs trust their Mailman lists.  If that's a
PITA for the admins, too bad---that's the flip side of the admin
benefits that come with use of DKIM to filter spam.  And of course
admins and MUA developers *will* develop trust management tools.
Maybe you have less confidence in your vendors, of course---I *know*
mine will rise to the occasion.

So far, you talk out of both sides of your mouth.  On the one hand,
you fault my proposal because of the attacks inherent in trusting any
old re-signature; on the other, you claim that you don't have trust in
anybody's signature, and you don't even treat your own specially!
Elsewhere you have implied that for you verification == trust if
"From == signing domain".  Just generalize that to include
"List-Id == signing domain" in the policy agent software!  And
"Sender == signing domain".

Users need never know that the "sender" who was verified is not the
>From header.  Why not recommend that UIs SHOULD treat *any* of the
three conditions above as "sender verified", until experience shows
that's a bad idea?  I suspect that naive users will happily accept it
if policy agents tell them "sender was verified, so we present you
with this mail for your consideration."  They may misconceive that the
>From header was verified, but why should that matter?

If it *does* matter to them (eg, because they know that "Mom would
never send me porn spam"), then here's the recommended UI for spam
discards when the sender has been verified as a mailing list:

Treat similar messages as spam?  [[yes]] [no]

Note: this message was verified to have been relayed by the Mailman
Developers mailing list at python.org, which accepts responsibility
for relaying it to you.
( ) I am not a member of this list.  Treat messages from this list
as spam in the future.
(o) I am a member of this list.  Carefully scan messages from this
list in the future.

Something similar could be recommended for other cases where the
verified sender is in a different domain from "From" (as I am, for
example).  Isn't that the way it's supposed to work?  Do you really
think that users will care as long as you explain that they're not
blacklisting their mothers, and the spammer does get blacklisted?


Footnotes: 
[1]  Whether Mailman itself should be a signer or verifier is another
question; I'm agnostic on that.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Barry Warsaw writes:

 > > Make sure no spam gets through your double opt-in list, and you're
 > > golden, no?
 > 
 > Ideally yeah.  But python.org does get reported occasionally since  
 > while I think we do a pretty good job of blocking most spam, some  
 > nasties gated from Usenet still get through.  Sigh.

*sigh* is right.  Mailing lists will take *some* collateral damage.

But DKIM is a very plausible approach to not just nibbling at spam,
but biting off as much as we can chew.  Especially since (unlike SPF
and challenge-reponse) it's already widely implemented.  The benefits
have to be assessed as potentially much bigger than the small
deviation from the ideal.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Mark Sapiro]

Michael Thomas wrote:
>
>On Wed, 7 Feb 2007, Mark Sapiro wrote:
>
>> Mike talks about the l= parameter allowing adding trailing content, but
>> I don't see Y! and Gmail using it, and even if they did, how would we
>> (could we) add a footer without breaking either the signature or the
>> MIME structure of the message.
>
>   l= is the number of canonical bytes added to the body hash.
>   If l=5, for example, anything past the 5th canonical byte will
>   not affect the verification of the signature. That's the reason
>   we get such high verify rates through mailing lists.



My point is that for what I consider good reasons, Mailman will add the
msg_footer to such a message by wrapping additional MIME structure
around the original multipart/alternative message.

I.e., the original

multipart/alternative
text/plain
text/html

message will be recast as

multipart/mixed
multipart/alternative
text/plain
text/html
text/plain

with the final text/plain part containing the footer. Given that the
original content-type header is included in the signature, the
signature is now broken.

If we were to take a different approach with a signature containing l=,
either the l= includes all the text/plain and at least part of the
text/html, in which we can't add the footer to the text/plain
alternative without breaking the signature, or the l= includes none of
the text/html part in which case the signature is not very good at
verifying the validity of the text/html part. This further assumes we
even know how to add a footer to a text/html part.

See

for some discussion of why we do it the way we do.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   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://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Mark Sapiro]

John W. Baxter wrote:

>On 2/7/07 8:46 AM, "Barry Warsaw" <[EMAIL PROTECTED]> wrote:
>
>> Should we strip DKIM by default or not?
>
>Not strip by default.
>
>Even though that changes the default vs the most recent Mailman, it leaves
>the default alone for everyone who jumps to 2.1.10 from earlier versions.


I think I am swayed by the arguments in this thread to favor Not Strip
as the default, and I agree with John WRT its not being a behavior
change for many.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   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://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[John W. Baxter]

On 2/7/07 9:19 AM, "Barry Warsaw" <[EMAIL PROTECTED]> wrote:

> OTOH, how many people would smell something fishy if this
> message had this header:
> 
> From: Barry Warsaw <[EMAIL PROTECTED]>

With many MUAs (including the vast majority of different MUA programs and
versions) that would pass totally unnoticed, as the user only sees
From: Barry Warsaw
without taking some action.
 
  --John


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[John W. Baxter]

On 2/7/07 8:46 AM, "Barry Warsaw" <[EMAIL PROTECTED]> wrote:

> Should we strip DKIM by default or not?

Not strip by default.

Even though that changes the default vs the most recent Mailman, it leaves
the default alone for everyone who jumps to 2.1.10 from earlier versions.

  --John


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Mark Sapiro]

Michael Thomas wrote:
>
>Frankly I think you'll be screwed even if you remove them too; removing
>them will not allow you to fly below the radar. Consider if Y! and Gmail
>had a bilateral agreement that they expect each other's mail to be signed
>and to put it in the bit bucket if it wasn't. It makes no difference whether
>you removed it or not: it lacks a valid signature in both cases. In that 
>case,
>the only thing you could do is not destroy and/or remove the signature.


Consider the headers and structure as follows (From: munged) of a
message I just received from a Y! user.


DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
 
h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
 
b=Cz7v0Jd51rc72THmOlqA/rac152bUZdiFm2T2IAFflFuxVHHKJmabS0rzD2tU5zVSofVoc0rVg0g7t0NaDGRMt7JxXK8reox7TzMephYOxI0zcr5iWGejG57Fn/gcQtqng8uG0vAJLw1mfXHMaCcz726cj4iYQOYzbCb6UxXH4g=;
X-YMail-OSG:
9QE.IHIVM1k8MHil45oNbkt10TvkD0DVytKmI1Ki4W.WDhIT4Qq6HnLM6dCWNcikXlMu.1lftQrfhq1fgEKml97AoKamDnsG4bZNT_FRLyHVTcU_cuUp7W04PgOjiNd9HJK6MSNeJsfDUfVqrnegItcDfJ1Kjs5tGYyMqDp084T22mRvpc3swag-
Received: from [69.232.227.173] by web82813.mail.mud.yahoo.com via
HTTP; Wed, 07 Feb 2007 15:00:43 PST
Date: Wed, 7 Feb 2007 15:00:43 -0800 (PST)
From: x
Subject: Re: feb. 25th
To: Mark Sapiro <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="0-1589639226-1170889243=:32077"
Content-Transfer-Encoding: 8bit
Message-ID: <[EMAIL PROTECTED]>


--0-1589639226-1170889243=:32077
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit




--0-1589639226-1170889243=:32077
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


--0-1589639226-1170889243=:32077--


(My MUA will mung the DomainKey-Signature: by wrapping, but it looked
OK as I received it)

I submit that there is nothing that Mailman could do to this message in
the way of filtering content or adding msg_footer that wouldn't break
the signature.

I also submit that this message structure is typical of the vast
majority of mail that originates from Y!

Thus, it seems that the choice is break the signature or make no
changes whatsoever to the message other than adding more headers.

Mike talks about the l= parameter allowing adding trailing content, but
I don't see Y! and Gmail using it, and even if they did, how would we
(could we) add a footer without breaking either the signature or the
MIME structure of the message.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   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://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[John W. Baxter]

On 2/7/07 7:32 AM, "Barry Warsaw" <[EMAIL PROTECTED]> wrote:

> Either they have a milter that refuses to
> resign or they have a working milter.  If their milter doesn't
> resign, then less harm is done by stripping the header.  If their
> milter does resign, then less harm is done by allowing it to resign,
> even if Mailman has broken the original signature.

Or they have an MTA that doesn't care at all about DKIM, in which case less
harm is done by not stripping.

  --John


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[John W. Baxter]

On 2/6/07 5:51 PM, "Bob Puff" <[EMAIL PROTECTED]> wrote:

> If a bad DK isn't bad, then how is this supposed to help spam?  I mean, if the
> mere presence of some signature in the headers will increase the likelihood of
> an email being delivered (or at least help it NOT be tagged as spam), surely
> the spammers will pick up on this, and the whole benefit lost.

They have.  Much of the spam I see from the "new breed legitimate spammers"*
contains DKIM signatures.  (I have to assume those verify OK, else why put
them in.)

* "new breed legitimate spammers":  That is, in the US, those who carefully
conform to CAN-SPAM as far as one can tell--one can't really tell whether
they "share" unsubscribed addresses with other spammers as likely new
victims without probing.

  --John


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Mark Sapiro]

Michael Thomas wrote:

>Barry Warsaw wrote:
>>
>> The reason From-forging may not be an effective strategy for the 
>> spambot though is because part of the point is to spoof the From 
>> header so that it looks like the spam is coming from someone you 
>> know.  OTOH, how many people would smell something fishy if this 
>> message had this header:
>>
>> From: Barry Warsaw <[EMAIL PROTECTED]>
>>
>> ?
>
>Er, I'm not following you.


So the bad guy fooled you!

-- 
Mark Sapiro <[EMAIL PROTECTED]>   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://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 5:06 PM, Michael Thomas wrote:

>>> I'm not saying I think that resigning is a Bad Thing, I'm saying  
>>> that it's
>>> speculative whether it's a Good Thing. You seem to keep ignoring the
>>> inherent attack involved with resigning:
>>>
>>> From: [EMAIL PROTECTED]
>>> Sender: [EMAIL PROTECTED]
>>> Dkim-Signature: d=fooledyou.com; [...]
>>
>> So wait, taken to its logical conclusion, doesn't this mean that  
>> really the only thing that DKIM cares about protecting is the  
>> sanctity of the From header?
> No, it doesn't. All it means is that you shouldn't blindly allow a  
> third party
> to vouch for a first party (or any other party for that matter).  
> This is just
> common sense: you need to have some trust in a third party before you
> trust what they have to say about another party, right?

Sure.  I guess my point was, that in your example above, what's being  
signed is the Sender header, and for that header, fooledyou.com /is/  
the first party.  So fooledyou.com is making no assertions about the  
 From header.  Is there a requirement in DKIM that the Sender domain  
is the same as the From domain?

For a non-anonymized non-digest message, where Mailman isn't going to  
change the From header, it obviously cannot sign the From header.  It  
will set its own Sender header, and is able to sign that.  In that  
scenario there's no third party signing going on.  Maybe the  
confusion is in the term "resigning".  I'm not actually proposing  
Mailman (or its downstream MTA) resign anything; I'm proposing that  
we add another signature for the headers that Mailman does control.   
Like Sender.

If we leave the original DKIM-Signature header alone, but simply add  
ours to match our Sender header, then we'll have at least one valid  
DKIM-Signature header, right?  The one for the From header may indeed  
be broken.  Maybe Mailman broke it or maybe some other system  
component broke it.

Is that what you thought I meant?  Is the scenario I just outlined  
inherently unsafe?

So now in fact, this leads to a concrete proposal that is simple, MLM- 
friendly and requires no changes to existing standards: a mailing  
list BCP is to DKIM sign the List-Id header.  You policy engine than  
can add weight for a message with a valid DKIM signature of the List- 
Id, even if other signatures, say by the original author are broken.

I think for now I'll cut this response short, because I'd like to  
know what you think about that.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcpVpHEjvBPtnXfVAQKEagP/WbWH5+rQuAofi5QrWgabibU8RRXZ8yqs
3nY1sZlYB616N6vuJoY4aqVN6Ud4AiXIS4gZPOsX5IEXiihK2XLYEL+JPtHMINHZ
al4aa/6sRxrizDGHDQH8db19umD0R9vYceBAoyjRwrE1b1XbBDh8+ALavXZ0Lum6
sD4/KOQC4+w=
=IUsC
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Michael Thomas]

Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 7, 2007, at 11:45 AM, Michael Thomas wrote:
>
>> I'm not saying I think that resigning is a Bad Thing, I'm saying that 
>> it's
>> speculative whether it's a Good Thing. You seem to keep ignoring the
>> inherent attack involved with resigning:
>>
>> From: [EMAIL PROTECTED]
>> Sender: [EMAIL PROTECTED]
>> Dkim-Signature: d=fooledyou.com; [...]
>
> So wait, taken to its logical conclusion, doesn't this mean that 
> really the only thing that DKIM cares about protecting is the sanctity 
> of the From header?  
No, it doesn't. All it means is that you shouldn't blindly allow a third 
party
to vouch for a first party (or any other party for that matter). This is 
just
common sense: you need to have some trust in a third party before you
trust what they have to say about another party, right?
> Tell me if I'm wrong but couldn't a spambot forge any header, create a 
> valid signature for that header, and inject that message into the mail 
> infrastructure?  It could even forge the From header and have a 
> perfectly valid signature for that.

It can do all of those things _except_ create a valid signature for
a domain that it does not control their DNS (ie, the repository for
the public keys).  That is, you can't forge cisco.com or python.org
if you can't put your keys in our zones. This is really a feature if you
consider it: making an environment where spammers have to sign
their mail limits their degrees of freedom: they have to leave more
tracks by registering domains, etc, etc.
>
> The reason From-forging may not be an effective strategy for the 
> spambot though is because part of the point is to spoof the From 
> header so that it looks like the spam is coming from someone you 
> know.  OTOH, how many people would smell something fishy if this 
> message had this header:
>
> From: Barry Warsaw <[EMAIL PROTECTED]>
>
> ?

Er, I'm not following you. A lot of the motivation around DKIM was to
limit the wholesale forgery that's possible now. If I could guess what you
mean here is that you mean that it lacks a signature at all? That's 
where the
SSP part of the work comes in: if you receive a piece of mail that's 
unsigned,
you do a lookup to see what the originating domain's policy is with respect
to signing mail. If they say "we sign everything", a receiver has a 
pretty good
indication that something's not right and may bias the filtering and/or 
annotation
accordingly.

>> If all it takes to get preferential treatment (FSVO preferential) is 
>> adding
>> any old third party signature, then we can pretty much guarantee that
>> spammers will start doing that when it's in their interest. The draft
>> specifically refers to "acceptable" in this case for that reason. 
>> This is
>> the achillies heel of third party signatures: it presupposes that you --
>> or much worse your mail infrastructure -- knows what constitutes
>> "acceptable". In practice I know that we as an organization have no
>> clue who is acceptable, and I also know that even if we did, there's
>> no infrastructure use/maintain it. I doubt that we're especially unique
>> here.
>
> Then I think we're in a catch-22.  We'd like the MLM to sign the 
> message to verify that it is a valid resender.  We'd like to keep the 
> original signature for forensic reasons at the very least.  Resigning 
> is vulnerable to attack.  There is no standard (de-facto or otherwise) 
> for a valid resender to indicate "I got this message from so-and-so, 
> munged it a bit, and resent it".  We're stuck.

Yes it is. At this point I'm not pessimistic though; from my point of view
it's more that we're just not sure how it will pan out. From that 
standpoint,
we need to keep _all_ of the options open which means that it's prudent
to _both_ try to get mailing lists to be dkim friendly for first party 
signatures
_and_ resign things so that reputation engines, etc, have something to
latch on to.
>
> You suggest that we just let the original signature through saying, 
> well, that works most of the time and if it doesn't work for you, 
> tough luck!  But whatever choices we make will be deployed in the 
> field for years and years and if the 800lb gorillas start to take a 
> much harder line two years from now, our mailing lists will be 
> screwed.  I have a hard time seeing how, given the above scenario and 
> inclination against resigning, that removing the DKIM signature and 
> just letting our messages go through normal spam processing is worse 
> than allowing a broken signature to sneak through.

Frankly I think you'll be screwed even if you remove them too; removing
them will not allow you to fly below the radar. Consider if Y! and Gmail
had a bilateral agreement that they expect each other's mail to be signed
and to put it in the bit bucket if it wasn't. It makes no difference whether
you removed it or not: it lacks a valid signature in both cases. In that 
case,
the only thing you could do

Re: [Mailman-Developers] dkim-signature headers

[Michael Thomas]

Joe Peterson wrote:
> Michael Thomas wrote:
>   
> 2) The outgoing MTA (sendmail) milter seemed to only want to sign emails
> that did *not* already have a signature.  Therefore, Mailman enabled
> them to re-sign by removing the old (presumably invalid anyway)
> signature.  At least this way *some* valid signature, even a Sender one,
> could be placed on the message.  This "restriction" may not apply
> anymore or may be milter-specific...
>   

Yes, it is specific to sendmail's milter. My milter that we use doesn't 
do that.
Actually, you should probably file a bug on that because the signer 
shouldn't
be paying attention to signatures from other domains. My guess is that this
was an attempt to prevent multiple signatures from the same domain, but I
haven't looked at Murray's code to verify that.
> And there is one more thing that, at least in my mind, made leaving the
> "known bad" sig in there a bad thing: if it is destined to be invalid,
> especially if there is almost no way to keep it valid, it seemed best to
> remove the "doomed" signature.  
I don't see why that follows. As I've said, I've not seen anybody whose
actually doing that in the field, and given gmail and Y! signing with DK,
a pretty large percentage of the world's legitimate email is currently being
signed.

> Even though DKIM states that bad sigs
> should be treated like "no sigs", it just seemed wrong to leave known
> bad sigs to potentially make the receiver think there is something awry.
>   

This is really the receiver's business, if you ask me. Bad receivers are
going to do bad things regardless of dkim or anything else, but that's
really their own problem. People make similar mistakes by rejecting
via SPF instead of using it as a data point in a larger filtering decision.
There's really nothing we can do about this. In fact, I'd say there is
just as high a likelihood that receivers will find that mail from domains
that normally sign their mail will look _more_ suspicious to filters if
the signature is stripped. Consider what's happening to your Bayesian
filters right now: they're being trained on DKIM-signature headers from
Cisco as being ham (I hope!) rather than spam. The lack of the signature
means less things for it lock on to...
>  Instead, having the new message signed with a new good signature that
> makes the MLM responsible certainly seemed OK and better.  Also, the
> results of the DKIM validation by the MTA (before it gets to Mailman)
> are *not* removed by Mailman, so there is a trace of the fact that (if
> the MLM host's MTA did DKIM checks) the original signature passed the
> test before the message was transformed, so there is a chain of trust
> (i.e. the reciever trusts the MLM, and the MLM host's MTA verifies the
> original sender and reports that in the header).
>   
Actually, of all things that could be stripped, the verification result is
actually what could/should be stripped since it's not cryptographically
verifiable. I'm pretty simple minded: I either trust the domain that sent
me the mail or I don't. It's mailman's problem, IMO, to determine whether
the original sender should be passed through the list or not.

> Now, after saying all of this, it still may be best to leave the sigs in
> there.  I am not convinced either way yet.  I can see your point about
> the forensic value.  Is there a way, somehow, that Mailman could verify
> the message before transformation (or the MTA could have done this) and
> then again after transformation - and then indicate in the header if the
> original signature has now been rendered invalid (through an as-yet
> undefined header line) - and then re-sign the message again (or maybe
> the MTA would re-sign it on the way out)?  
Yes, absolutely you could do this. In fact, with the milter or other similar
pieces of software your MTA will already do those things for you. I don't
really see the point of inventing a new header to do what an invalid
DKIM-signature header will already do. Especially given that a lot of the
things that you thought were invalid actually weren't.

As for whether mailman itself should sign and/or verify... I suspect that
letting the MTA do that is more expedient and will save a lot of work.
I believe at this point many/most of the MTA vendors have DKIM or
are working on them, as well as the open software community as well.

On the other hand, _using_ dkim results within mailman as an anti
spoofing mechanism might be interesting, though I really have no idea
how much of a problem that is.
> This could perhaps be a way
> for Mailman to indicate to the receiver that an invalid From signature
> is to be expected, and no alarm bells would then go off (the receiver
> could then rely on the chain of trust).  But if the From signature
> proves to be still valid after transformation, the receiver would know
> this is expected and could check this again and be even more confident,
> relying on not only the chain of trust but also on the primary
> signature.  Thi

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

BTW, synchronicity is a weird thing.  A friend of mine -- totally  
unaware of the current discussions -- just sent this to me:

http://it.slashdot.org/comments.pl?sid=218726&cid=17752748

LOL.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoLMXEjvBPtnXfVAQKQHwP+LHBd+K8kS0WP1D/YsZ9SCSzSqgXzqiY+
jjk1cPzvM5diDb9C5j1rkebZHKmHJtLlmgUHb5skxNr2OYz4uvVKFvm1eSWCGASW
V8F9wATj0uO/Hiro+grBLoJsGuVc5+TBRjORqMXp3PPIhQy5rahobhTJSXu/Wya7
txI0BoqSQNY=
=SCfD
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 11:45 AM, Michael Thomas wrote:

> I'm not saying I think that resigning is a Bad Thing, I'm saying  
> that it's
> speculative whether it's a Good Thing. You seem to keep ignoring the
> inherent attack involved with resigning:
>
> From: [EMAIL PROTECTED]
> Sender: [EMAIL PROTECTED]
> Dkim-Signature: d=fooledyou.com; [...]

So wait, taken to its logical conclusion, doesn't this mean that  
really the only thing that DKIM cares about protecting is the  
sanctity of the From header?  Tell me if I'm wrong but couldn't a  
spambot forge any header, create a valid signature for that header,  
and inject that message into the mail infrastructure?  It could even  
forge the From header and have a perfectly valid signature for that.

The reason From-forging may not be an effective strategy for the  
spambot though is because part of the point is to spoof the From  
header so that it looks like the spam is coming from someone you  
know.  OTOH, how many people would smell something fishy if this  
message had this header:

From: Barry Warsaw <[EMAIL PROTECTED]>

?

> If all it takes to get preferential treatment (FSVO preferential)  
> is adding
> any old third party signature, then we can pretty much guarantee that
> spammers will start doing that when it's in their interest. The draft
> specifically refers to "acceptable" in this case for that reason.  
> This is
> the achillies heel of third party signatures: it presupposes that  
> you --
> or much worse your mail infrastructure -- knows what constitutes
> "acceptable". In practice I know that we as an organization have no
> clue who is acceptable, and I also know that even if we did, there's
> no infrastructure use/maintain it. I doubt that we're especially  
> unique
> here.

Then I think we're in a catch-22.  We'd like the MLM to sign the  
message to verify that it is a valid resender.  We'd like to keep the  
original signature for forensic reasons at the very least.  Resigning  
is vulnerable to attack.  There is no standard (de-facto or  
otherwise) for a valid resender to indicate "I got this message from  
so-and-so, munged it a bit, and resent it".  We're stuck.

You suggest that we just let the original signature through saying,  
well, that works most of the time and if it doesn't work for you,  
tough luck!  But whatever choices we make will be deployed in the  
field for years and years and if the 800lb gorillas start to take a  
much harder line two years from now, our mailing lists will be  
screwed.  I have a hard time seeing how, given the above scenario and  
inclination against resigning, that removing the DKIM signature and  
just letting our messages go through normal spam processing is worse  
than allowing a broken signature to sneak through.

> I think the question is quite apt: there are lots of transforms  
> that might
> damage PGP signatures as well: why aren't you stripping them en masse
> like you are dkim signatures? Could it be that it's because in  
> reality they
> normally go through just fine?

No.  It's because that would require a deletive transformation on the  
contents of the body (at least for OpenPGP) and Mailman doesn't do  
that[*].  Under a very controlled set of conditions, Mailman will / 
add/ text to the body of the message, and it may perform character  
set transformations, but in general Mailman isn't going to go  
searching through the body of a message to find some PGP delimiters  
to strip.

Signatures that are embodied in MIME parts can and may very well be  
easily stripped.

[*] the one minor exception is removing things like Accepted: headers  
from the body of the message, but this is tightly limited to the  
first 5 or so non-blank lines of the body.  Even then it doesn't work  
in the face of multipart/alternatives.

> Something to note is that a *lot* of the difference between DK and  
> DKIM
> was our insistence that DKIM be far more robust through manglers than
> DK was. This was purposefully so that survival through mailing  
> lists was
> much more likely -- something that a lot of people frankly didn't  
> care about.

Mailing list use cases are very often overlooked in email related  
RFCs.  Funny because so many standards discussions are conducted on  
mailing lists.

> Which false positives? I don't remember seeing that, and I've  
> certainly not
> seen anything in our deployment that suggests that bad signatures  
> are causing
> FP's on other domains incoming mail. After a year of deployment  
> signing
> millions of messages a day, I'd expect that I'd have heard at least  
> *one*
> report of that. Heck Y! and Google signing billions of messages a  
> day with
> DK which is a lot more fragile and I've never heard from either of  
> them that
> they are having FP problems due to broken signatures.

What kind of reporting infrastructure is there for false positives?   
ISTM they'd be very hard for end users to spot and repo

Re: [Mailman-Developers] dkim-signature headers

[Joe Peterson]

Barry Warsaw wrote:
> What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an  
> mm_cfg.py variable that controls whether DKIM headers are stripped or  
> not.  I think Mark suggested that this should be a site-wide  
> variable, and I tend to agree.  The reasoning being that all the  
> outbound Mailman traffic will be ultimately delivered by an MTA under  
> the site admin's control.  Either they have a milter that refuses to  
> resign or they have a working milter.  If their milter doesn't  
> resign, then less harm is done by stripping the header.  If their  
> milter does resign, then less harm is done by allowing it to resign,  
> even if Mailman has broken the original signature.

Yes!  I think this is indeed the right solution.  I also tend to agree
with Bob that the default ought to be to strip DKIM headers, as
DKIM-aware admins would know what this variable is about, but admins who
know nothing about DKIM probably will not have re-signing implemented.

-Joe
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 11:49 AM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an
>> mm_cfg.py variable that controls whether DKIM headers are stripped or
>> not.  I think Mark suggested that this should be a site-wide
>> variable, and I tend to agree.
>
> I've expressed my reservations regarding list-specific issues like
> internationalization (especially random 7<->8 bit transformation), but
> on the one hand we don't have any practical experience showing it's
> needed, and on the other hand turning site-wide Mailman options into
> list-specific options is well-understood.  Ie, it's a YAGNI until
> proven otherwise.

Agreed.  I do think the effects of stripping vs. non-stripping may be  
felt on a per-list and per-user basis, but let's do the simplest  
thing possible now and see what happens.

> What about the default?  My strong inclination is don't strip, and
> word the docstring to discourage stripping.

Good question.  Let's take an informal poll.

Should we strip DKIM by default or not?
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoCV3EjvBPtnXfVAQIzyAP+MrDG7vgIr4fr/90Tz0xobxqvEJmqLAFB
vt7bzZqhr1SRlg/k8Y6eED5TbVivqWxLV5Ea27Uy0OYdb4X2QnMOHVoBBF8NDKu9
61Rg33vH/taAWzlND20Tvp6S0QPi9eiS70NGe7RuXbISK2PSnvig5hxKx47uxJ/L
hqpkyDPIgOQ=
=/OAo
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Michael Thomas]

Stephen J. Turnbull wrote:
> Michael Thomas writes:
>
>  > I'm afraid that there's not much consensus on how to deal with the
>  > mailing list issue; the people who say "resign" are guessing as there
>  > is little/no evidence that resigning is actually a viable strategy.
>
> From the point of view of the mailing lists, resigning is *clearly* a
> viable strategy; the draft mandates that signature processing SHOULD
> continue until a success or all signatures are exhausted.  (And it MAY
> continue after a success.)  Assuming conformant verifiers (and no
> corruption in the pipeline after the mailing list, of course),
> resigning by the mailing list guarantees successful verification.
>   

I'm not saying I think that resigning is a Bad Thing, I'm saying that it's
speculative whether it's a Good Thing. You seem to keep ignoring the
inherent attack involved with resigning:

From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Dkim-Signature: d=fooledyou.com; [...]

If all it takes to get preferential treatment (FSVO preferential) is adding
any old third party signature, then we can pretty much guarantee that
spammers will start doing that when it's in their interest. The draft
specifically refers to "acceptable" in this case for that reason. This is
the achillies heel of third party signatures: it presupposes that you --
or much worse your mail infrastructure -- knows what constitutes
"acceptable". In practice I know that we as an organization have no
clue who is acceptable, and I also know that even if we did, there's
no infrastructure use/maintain it. I doubt that we're especially unique
here.

>  > Do you remove PGP ascii armor just on the offhand chance that you might
>  > destroy a PGP signature with some  configurations of mailman?
>
> That's hardly fair.  Joe Petersen writes (in a response to your
> message):
>
> 2) The outgoing MTA (sendmail) milter seemed to only want to sign
> emails that did *not* already have a signature.  Therefore,
> Mailman enabled them to re-sign by removing the old (presumably
> invalid anyway) signature.
>   

That is just an implementation detail of the sendmail milter. Mine doesn't
have that restriction and neither do others that I've seen. This is new code
in a new area so getting all worked up about how a particular implementation
behaves is not fair.
> First, note that the admin has explicitly stated that the existing
> signature is presumed invalid.  He may be wrong, but this isn't an
> "offhand chance".
>   

I think the question is quite apt: there are lots of transforms that might
damage PGP signatures as well: why aren't you stripping them en masse
like you are dkim signatures? Could it be that it's because in reality they
normally go through just fine? Well, the same is true of dkim signatures;
that you've come to the opposite conclusion seems to be based off of
experience with exactly one implementation that doesn't produce
mailing list friendly signatures. But that implementation isn't inherent
in the spec.

Something to note is that a *lot* of the difference between DK and DKIM
was our insistence that DKIM be far more robust through manglers than
DK was. This was purposefully so that survival through mailing lists was
much more likely -- something that a lot of people frankly didn't care 
about.

> I'd like to see that last "should" in all uppercase.  
In RFC-speak, should and SHOULD are identical.

> Then
> (sorry, Barry!) IMO the burden is clearly on Mailman and other list
> manager projects to either implement signing themselves, or publish
> their own BCPs strongly recommending use in combination with an MTA
> that will do the signing.
>   
As I mentioned, part of the DKIM work is the SSP work as well. Being able
to say that "I sign everything" is a pretty powerful indication that you 
should
be more suspicious if you get a broken/unsigned piece of mail. So while I
think it would be great if mailman pushed signing too, I think that 
there are
other incentives for domains to bring mailing lists into the fold too.
>  > By removing signatures you go from having about a 99% success rate
>  > to a 0% success rate.
>
> That's false.  You go from a 99% success rate *on "loopback" messages*
> to 0%.  On other messages the ex ante success rate will be much lower
> because the trust relationship is on average much weaker.  However,
> the vast majority of *deliveries* are not "loopbacks", and those
> non-loopbacks are likely (see (1) below) to suffer from rejection on
> the basis that signatures fail.
>   

Huh? There's no difference between "loopback" and anything else: either
a signature verifies or it doesn't; we don't treat our own signatures 
any differently
than any other signatures. When using the l= option, almost all 
signatures will
verify. The only substantial difference between dkim and pgp signatures 
is when
a mailing list annotates the subject line of a new thread, but this too 
can be
worked around by intelligent use of z=. The only reaso

Re: [Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Barry Warsaw writes:

 > What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an  
 > mm_cfg.py variable that controls whether DKIM headers are stripped or  
 > not.  I think Mark suggested that this should be a site-wide  
 > variable, and I tend to agree.

I've expressed my reservations regarding list-specific issues like
internationalization (especially random 7<->8 bit transformation), but
on the one hand we don't have any practical experience showing it's
needed, and on the other hand turning site-wide Mailman options into
list-specific options is well-understood.  Ie, it's a YAGNI until
proven otherwise.

What about the default?  My strong inclination is don't strip, and
word the docstring to discourage stripping.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 11:40 AM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> Part of me agrees that this is what you'd like to see, but my gut
>> tells me that this will never work in practice.  First, no one but an
>> email geek will even understand the question, let alone know how to
>> answer it,
>
> Agreed.  It's a stalking horse for the BCP; for anybody who's not an
> email geek, I have this simple advice regarding the BCP:
>
>  Run away!  Run away!

LOL.

>> and second, I fear that most u/i's and policy engines will
>> boil this down to a very simple choice for the user:
>>
>>  This message is unverified
>>
>>  [Accept] [Discard]
>>  (o) Do the same for all similar messages
>
> Make sure no spam gets through your double opt-in list, and you're
> golden, no?

Ideally yeah.  But python.org does get reported occasionally since  
while I think we do a pretty good job of blocking most spam, some  
nasties gated from Usenet still get through.  Sigh.

(Today's rant: overly aggressive blackholes that block /all/ cable  
and DSL IPs that reverse to the ISP doman.  For FSM's sake, I have a  
static IP address already!)

> Similar is *not* going to reduce to "is unverified"; too many
> grandmothers will lose messages from the grandkids.

You might be right about that.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoAaXEjvBPtnXfVAQIxrwP/XpboY8mzsbw5LG9L+8Un/M4ogwgP4FgO
6JYNwgaMUAl4cWb1uXBgVuICUEP9LJMwj24SnqENV5HSxDWL5ui2jLj4psPS0h3U
9JXVT/gOjrW2Mr6XeGpVhDO5Zwe8I6obJU4zy/Iey7cqkB+uRyVK+00R5DGmvvo+
cKtcxXYv5HI=
=W+TD
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Part of me agrees that this is what you'd like to see, but my gut  
 > tells me that this will never work in practice.  First, no one but an  
 > email geek will even understand the question, let alone know how to  
 > answer it,

Agreed.  It's a stalking horse for the BCP; for anybody who's not an
email geek, I have this simple advice regarding the BCP:

 Run away!  Run away!

 > and second, I fear that most u/i's and policy engines will  
 > boil this down to a very simple choice for the user:
 > 
 >  This message is unverified
 > 
 >  [Accept] [Discard]
 >  (o) Do the same for all similar messages

Make sure no spam gets through your double opt-in list, and you're
golden, no?

Similar is *not* going to reduce to "is unverified"; too many
grandmothers will lose messages from the grandkids.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Michael Thomas]

Joe Peterson wrote:
> With DKIM, according to my understanding, you are supposed to treat a
> "bad" sig the same way you'd treat "no" sig.  So it would neither help
> nor hurt to have a bad signature; it would be like having none (or a
> missing sig).
>
> Personally, I think DKIM would be a whole lot more effective and
> powerful if we *could* treat bad sigs as bad.  Also, I think there is
> danger of people reacting to bad signatures negatively.  Personally, I'd
> eye a failed sig with a more suspicious eye than no sig.
>   

Until, of course, you rejected a piece of mail which had an x-million dollar
deal in it... one thing we found out is that while people hate false 
negatives,
mail admins *really* hate false positives. The truth of the matter is 
that shit
happens in the mail system and overreacting based on single factors is a
great recipe for generating lots of false positives. As an individual 
decision
you can set your own tolerance level, but you quickly become a lot
more conservative if you're doing it at a (large) group level.

   Mike
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Bob Puff]

> What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an  
> mm_cfg.py variable that controls whether DKIM headers are stripped 
> or  not.  

+1, with it defaulting to strip the DKIM.

Bob
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Michael Thomas]

Bob Puff wrote:
> I confess not having read up on Domain Keys.. I did get into SPF a little, but
> understand its flaws as well.
>
> If a bad DK isn't bad, then how is this supposed to help spam?  I mean, if the
> mere presence of some signature in the headers will increase the likelihood of
> an email being delivered (or at least help it NOT be tagged as spam), surely
> the spammers will pick up on this, and the whole benefit lost.
>   
DKIM isn't about "solving" spam per se. It's about accountability. If
you know about a source, you can treat it differently. DKIM allows you
to know the source. That goes for both good and bad sources of mail.

> Example:
>
> Spammer takes a legit message from a DK sender, replaces it with his spam, and
> blasts it out with the original DK headers.  The message has obviously been
> altered, and contains spam.  Would it not be right to reject this message,
> since it fails the DK check?
>   
It's no more right to reject based on a signature failure than any other
single test; how strong a weighting you give a signature failures depends
on a myriad of things -- if you want to prevent false positives. In fact,
I'd say that one of the DKIM provides is a better way to prevent false
positives rather than detecting spam per se. If you know and trust
a source, mail talking about v**gr* is more likely to be legit. Mail without
signatures or with broken signatures is just put through the normal unknown
source spam filter, so it's just neutral rather than spammy.

   Mike

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 4:31 AM, Stephen J. Turnbull wrote:

>> Let me float this though: how about a "signature friendly" knob that
>> configures the list to not do things that are known to be harmful to
>> signatures (including s/mime and pgp for that matter). I don't think
>> this needs to be _especially_ complicated, but it would probably need
>> to be fleshed out.
>
> [ Actually, for Mailman 3 it would be nice to have a general "theme"
>   engine that handles this kind of thing. ]

And I'm strongly in favor of having such a framework.

> I think as a practical matter it's only a matter of time before this
> becomes a FAQ in *both* directions (people who are having problems
> similar to Joe Petersen's as well as those similar to Cisco's).  So I
> agree here.

Yep.

> I would answer Barry that Mailman SHOULD preserve existing signatures
> because the spec will get language saying
>
>   o signers SHOULD NOT refuse to re-sign
>   o policy agents SHOULD report only successes by default
>   o policy agents MAY provide an option to acquire information about
> failures
>
> In particular, in section 6.1,
>
>   INFORMATIVE NOTE:  The rationale of this requirement is to  
> permit
>   messages that have invalid signatures but also a valid signature
>   to work.  For example, a mailing list exploder might opt to  
> leave
>   the original submitter signature in place even though the  
> exploder
>   knows that it is modifying the message in some way that will  
> break
>   that signature, and the exploder inserts its own signature.  In
>   this case the message should succeed even in the presence of the
>   known-broken signature.
>
> I'd like to see that last "should" in all uppercase.  Then
> (sorry, Barry!) IMO the burden is clearly on Mailman and other list
> manager projects to either implement signing themselves, or publish
> their own BCPs strongly recommending use in combination with an MTA
> that will do the signing.

I agree.

> What I really fear is that
>
> (1) everybody's intuition is that a failed verification is a
> positive indicator for spam (as compared to no signature, as
> well as compared to verified signature), and they want to
> apply policy filters based on that---we can expect that lots
> of people (and let's not forget AOL) will (ab)use the
> information that way, and
>
> (2) we've already seen list-hostile implementations in the wild---
> we can expect that there will be more.
>
> Both of these are evidently conformant to the current spec.

I echo Steve's fear.  I think without clarifying language, that's  
exactly what we'll see.  We'll probably see it anyway, but at least  
when Mailman gets screwed, we can at least point to the spec and say  
"you're being unfair to us!".

>> Destroying information -- especially when you're charged with
>> forensic exercises like spam filters are -- is *rarely* the right
>> thing to do.
>
> True, but this is a Pythonic bunch.  "Practicality beats purity." :-)

Indeed.

Let me bring this back around to the question of what Mailman should  
do.  Clearly we aren't going to implement DKIM verification and  
signatures in Mailman 2.1, although it would not be unreasonable to  
add such a handler modules as unsupported contributions.  Is anybody  
motivated enough to implement them?  I could see such handlers  
becoming officially supported in Mailman 2.2/3.0.

What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an  
mm_cfg.py variable that controls whether DKIM headers are stripped or  
not.  I think Mark suggested that this should be a site-wide  
variable, and I tend to agree.  The reasoning being that all the  
outbound Mailman traffic will be ultimately delivered by an MTA under  
the site admin's control.  Either they have a milter that refuses to  
resign or they have a working milter.  If their milter doesn't  
resign, then less harm is done by stripping the header.  If their  
milter does resign, then less harm is done by allowing it to resign,  
even if Mailman has broken the original signature.

I don't think there's any feasible way for MM2.1 to determine whether  
its transformations break the original signature or not, but that  
infrastructure could be built into Mailman 2.2/3.0.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcnxCnEjvBPtnXfVAQKr0QQAmXahpxy7V6fRXJJb3rFaruS529hWHKeS
QliPVV1CBdNFqCfsYGVkDKGMV/vdUvOdoOHgougIrWEjYZdlWp82LRzoWbjR4MS+
H0hMkUENuZA2oO/iBQ8K7hBlGoRLhHc2x8odyR0YhcMWBbDrq6I8ICSYrd3kMTu7
sFEOCGBTpFA=
=7tCs
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:

Re: [Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 7, 2007, at 1:39 AM, Stephen J. Turnbull wrote:

> Certainly.  What we really want is policy agents that are smart enough
> to say to the user
>
>   This message has a signature which verified successfully and one
>   which failed.  According to the Received trace and the List-Id
>   header, and correlated with the SENDER_IS_MAILMAN_BOUNCE heuristic,
>   the successful signature was added by the Mailman Users mailing
>   list.  The wooz.1april signature failed.
>
>   In similar cases in the future for this mailing list, should I
>
>   (o) Rely on the verified signature and silently accept the message
>   ( ) Ask how to treat the message
>   ( ) Silently discard the message
>
>   [[Accept this message]]  [Discard this message]

Part of me agrees that this is what you'd like to see, but my gut  
tells me that this will never work in practice.  First, no one but an  
email geek will even understand the question, let alone know how to  
answer it, and second, I fear that most u/i's and policy engines will  
boil this down to a very simple choice for the user:

 This message is unverified

 [Accept] [Discard]
 (o) Do the same for all similar messages

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcntrXEjvBPtnXfVAQKCHwP6A1hqINQZj+EFnC0Vr9i49/wdAx3lA3NW
+E3LpOALR9rfhmTxr3IM7tK3niPz7BFl4s7aPZhTReHt2HqVuED4ZOZzV7z0s7hc
x6UM/Cm05fiGAz0A3aTLtrJiq8zQfu0h8Vc4mBJxlUt4hOUB/In+gDsLAzVqyHOB
N2qgM7Wll0w=
=B1XG
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
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://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Michael Thomas writes:

 > I'm afraid that there's not much consensus on how to deal with the
 > mailing list issue; the people who say "resign" are guessing as there
 > is little/no evidence that resigning is actually a viable strategy.

>From the point of view of the mailing lists, resigning is *clearly* a
viable strategy; the draft mandates that signature processing SHOULD
continue until a success or all signatures are exhausted.  (And it MAY
continue after a success.)  Assuming conformant verifiers (and no
corruption in the pipeline after the mailing list, of course),
resigning by the mailing list guarantees successful verification.

Of course there's the issue that policy agents might choose to put
100% weight on the failure of the trusted domain's signature, and none
on the success of the mailing list's signature.  See my reply to Joe
Petersen for a scenario of how this could be avoided.  Whether it will
work well in practice depends on whether policy agents (milters and
MUAs, mostly, I should think) will offer such options.  While clearly
you can't make such handling a MUST, I would like to see the BCP
specify that policy agents SHOULD provide such a feature to facilitate
resigning by resenders.

Finally, with regard to "loopback" verification, that's your local
policy problem, really.  It's true that munging by a few mailing lists
is invalidating your outgoing signatures.  Whether that consideration
overrides the mailing lists' editorial policies is a question for
negotiation among you, your users, and the list admins on a case by
case basis.  Remember, you always have the option of S/MIME on
individual SignedData MIME body parts for this purpose, and your
argument for resenders passing things through verbatim would be much
stronger in that case.

 > Let me float this though: how about a "signature friendly" knob that
 > configures the list to not do things that are known to be harmful to
 > signatures (including s/mime and pgp for that matter). I don't think
 > this needs to be _especially_ complicated, but it would probably need
 > to be fleshed out.

[ Actually, for Mailman 3 it would be nice to have a general "theme"
  engine that handles this kind of thing. ]

I think as a practical matter it's only a matter of time before this
becomes a FAQ in *both* directions (people who are having problems
similar to Joe Petersen's as well as those similar to Cisco's).  So I
agree here.

> "bw" == Barry Warsaw writes:

 bw> I really want to see the spec address mailing list issues in a 
 bw> thorough way, with clear instructions on what such remailers must and 
 bw> should do.

 > I think it would actually work a lot better the other way: with real life
 > experience and real life running code we can make a much better case
 > for what constitutes a best common practice. Part of the problem right
 > now is that a lot of the speculation is just that.

I really really sympathize with Barry (especially since I don't really
have the resources to help with implementation of a verifier or signer
for Mailman), but I have to agree with you here.

 bw> We're removing signature that we know nothing about.  As I said, IWBNI 
 bw> we had code that could check DKIM signatures and sign messages.  So a 
 bw> question to ask, in the face of no available code to do the verifying 
 bw> or signing, is it better to possibly break signatures because of 
 bw> Mailman transformations or better to not have a signature at all.  And 
 bw> why?
 > 
 > Do you remove PGP ascii armor just on the offhand chance that you might
 > destroy a PGP signature with some  configurations of mailman?

That's hardly fair.  Joe Petersen writes (in a response to your
message):

2) The outgoing MTA (sendmail) milter seemed to only want to sign
emails that did *not* already have a signature.  Therefore,
Mailman enabled them to re-sign by removing the old (presumably
invalid anyway) signature.

First, note that the admin has explicitly stated that the existing
signature is presumed invalid.  He may be wrong, but this isn't an
"offhand chance".

Much more interestingly, note that the milter is broken with respect
to mailing lists.  IMO, Section 5.1 of dkim-base should get language
that says a signer SHOULD NOT refuse to sign a message merely because
there is an existing signature.  Without that, Barry's question is
very relevant.

I would answer Barry that Mailman SHOULD preserve existing signatures
because the spec will get language saying

  o signers SHOULD NOT refuse to re-sign
  o policy agents SHOULD report only successes by default
  o policy agents MAY provide an option to acquire information about
failures

In particular, in section 6.1,

  INFORMATIVE NOTE:  The rationale of this requirement is to permit
  messages that have invalid signatures but also a valid signature
  to work.  For example, a mailing list exploder might opt to leave
  the original submitter signature in place even though the exploder