[Mailman-Developers] dkim and email list software - potential solution

[Daniel Black]

Folks,

Please excuse the massive cross post and reply to the dkim-dev list if 
possible and it is of collective interest to many email list software 
implementers.

I've put together a paper on DKIM that I've just put out for review. It is 
available here[1] if anyone would like to review it. Feedback can still be 
incorporated.

As you may know ([2] and others), DKIM has an incompatibility with email list 
software message modification and ADSP verification (RFC5617).

The incompatibility is as follows:
1. An author emails to a mailing list. 
2. The author's email infrastructure DKIM signs the email message and 
publishes a ADSP dkim record saying 'I sign all messages for this domain'
3. The message is received by the email list
4. the email list software removes the DKIM-signature or, though message 
modification, invalidates the signature
5. the email list subscriber receivers the email and attempts a DKIM-signature  
 
validation. If the signature did not exist it will validate ok.
6. the email list subscriber attempts to validated the DKIM-ADSP. The author 
domain, taken from the From: address, has a DKIM-ADSP record saying "all" 
(meaning I sign all messages) or "discard" (discard if the author domain 
signature is invalid or missing).
7. email gets dropped due to ADSP

The ways email list software can deal with this is (from [2]):
1. ignore the problem - not really friendly given social demand for 
antispoofing
2. Parse DKIM-Signature and don't do transforms that break this - will end up 
lots of exception handling code and an inconstant emails to the subscriber 
that may not meet the list owner's policy.
3. remove DKIM-Signature conditionally - fails ADSP really badly
4. sign list-ID headers and ask verifiers to check for list-id tags in a 
spamyness way - complicates verification, provides spoofing loophole as DKIM is 
antispoofing more that anitspam
5. remove DKIM-Signature always - fails ADSP really badly

As we can see none of these are ideal.

What I propose as a solution is:

1. rewrite the From: address of the email to include the domain of the email 
address.
and one or both of:
2. make "sender" or "reply-to" email headers contain the original sender
3. make the mail list contain a delivery from the rewitten address in#1 to the 
original sender.

Rational:
For #1:
Rewriting the From address immediately makes the Author domain the email list. 
As such the ADSP verification by the receiver immediately looks to the email 
list domain for signatures.

The original DKIM-signature is there and should not be removed despite being 
invalid (as recommended in one of the RFC), however as it is no longer the 
Author Domain Signature its criticality is not as important.

Having a From domain here makes it easy for DKIM signing software to sign all 
email for the for email list. Some signing software says sign only "From:. 
*...@mydomain.com".

I discarded the idea of adding a From address as sender-id verification will 
fail if two (or more) from addresses though earlier versions do and DKIM 
supports it.

For #2:
Having a reply-to and sender (RFC5322 3.6.2) gives the MUA the hint as to 
where to send the reply now that we have altered the from address.

I acknowledge that email lists already mundge this sometimes hence option #3.

For #3:
Taking care of those cases where the MUA or user just copies the from address 
or where option #2 is not considered, it would be just polite to deliver the 
munged email address of the email list domain back to the author.

Careful consideration here needs to take care of the transformation. Relaying 
through a mail server should require some checks and here it is particular 
important. Mutilating an address to sympa-dev+daniel_cacert@cru.fr without 
checks would just encourage spammers to send email to sympa-
dev+(arbitaryemailaddress)@cru.fr and the email list would become effectively 
an open relay. Some kind of check to make sure the arbitaryemailaddress is a 
subscriber of the list would be a primary check though other encrypted/signed  
addresses are also possible here.

I see this as the solution that requires the least amount of code changes, 
preserves most existing behaviour, and becomes it becomes DKIM friendly. I'm 
keen to know if you agree or think otherwise. I don't know how IETF authors 
feel about this but I'll also find out fairly soon :-)

The referenced paper[1] contains some guidelines for DKIM signing list 
messages too. Feedback on that also welcome.

[1] https://community.cacert.org/dkim/ - dkim paper talking about email lists
[2] http://wiki.list.org/display/DEV/DKIM

Cheers,
-- 
Daniel Black
Infrastructure Administrator
CAcert


signature.asc
Description: This is a digitally signed message part.
___
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.ma

[Mailman-Developers] dkim and email list software - potential solution

[Daniel Black]

I proposed some ideas around DKIM compatibility with mail lists and tried to 
send here too. Obviously the anti-cross-post feature on mailman-
develop...@python.org is working well (which on some levels I appreciate).

As leading maillist product I'm keep to know your opinion. This has obviously 
been mentioned before never quite got momentum[1]. Now that ADSP (RFC 5617) is 
out it seems that validating domains with a ADSP policy of dkim=all seems 
rather weak as anything other than a temporary spam bias (until spammers catch 
on).

My nice controversial idea is to mangle the from: address in mailing lists in 
general so that the list domain becomes the author (for ADSP purposes) and 
those DKIM validating emails are given the ability to do more with ADSP than 
spam biasing.

Original post here http://mipassoc.org/pipermail/dkim-dev/2009-
September/000202.html

Other ideas welcome.

[1] http://wiki.list.org/display/DEV/DKIM

-- 
Daniel Black
Infrastructure Administrator
CAcert


signature.asc
Description: This is a digitally signed message part.
___
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] [dkim-dev] dkim and email list software - potential solution

[Dave CROCKER]

wow.  more than 16 hours and no one has posted anything.


Daniel Black wrote:
2. The author's email infrastructure DKIM signs the email message and 
publishes a ADSP dkim record saying 'I sign all messages for this domain'

3. The message is received by the email list


I'm going to respond without getting into any of the ADSP emotional debate. 
ADSP is what it is.  DKIM is what it is.  You are asking a legitimate question 
about a potential scenario that seems likely to occur.


If someone registers an ADSP record that says that any failed or absent 
signatures should cause the message to be dropped, they are responsible for 
making the assertion and for its consequences.


The presumption behind this bit of mechanism is that the ADSP registrant knows 
enough, and can control enough, to produce the desired outcome.


The scenario you are exploring demonstrates a case in which they were wrong.

I think it a mistake to ask intermediaries to fix the effects of their own 
legitimate actions, really caused by inappropriate policy choices of an 
organization earlier in the handling sequence.


The core problem, here, is that the signing organization asserted a generality 
that was incorrect.  It's not your job to hack your system or the messages you 
process to try to fix their mistaken generality.


d/

ps. There are cases of SPF -a being set incorrectly, and it didn't even take a 
mailing list to create undelivered mail.  The solution is to change the -a 
setting, rather than try to hack around it.


--

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

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

[Mailman-Developers] Script to change a member's password

[Marc Juul]

Hello.

I'm running mailman 2.1.11 and i wrote a script to change a user's
password, but it doesn't change anything and i can't seem to find the
problem. My other "withlist" scripts work fine.

I'm using:

  mlist.setMemberPassword(member, password)

and then

  mlist.Save()

called using "withlist -l -r"

I have attached my script.

Thanks in advance.

Marc Juul
#! /usr/bin/python
#

"""
This script is intended to be run as a bin/withlist script, i.e.

% bin/withlist -l -r set_member_password listname --email member_email --password password

"""

import sys
import getopt

import paths
from Mailman import Utils
from Mailman.i18n import _


try:
True, False
except NameError:
True = 1
False = 0

^L
def usage(code, msg=''):
if code:
fd = sys.stderr
else:
fd = sys.stdout
print >> fd, _(__doc__.replace('%', '%%'))
if msg:
print >> fd, msg
sys.exit(code)


^L
def set_member_password(mlist, *args):
try:
opts, args = getopt.getopt(args, '', ['email=', 'password='])
except getopt.error, msg:
usage(1, msg)

email = False
password = False

for opt, arg in opts:
if opt == '--email':
email = arg
elif opt == '--password':
password = arg

if (not email) or (not password):
print "Error: missing email address and/or password"
return False

listname = mlist.internal_name()

print _('Setting password for email %(email)s for list: %(listname)s')


found = False

for member in mlist.getMembers():
if mlist.getMemberKey(member) == email:
mlist.setMemberPassword(member, password)
found = True

if not found:
print "Error: email not subscribed to list"
return False


print "Success!"

mlist.Save()

return True

^L
if __name__ == '__main__':
usage(0)
___
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] [dkim-dev] dkim and email list software - potential solution

[Douglas Otis]

On 9/29/09 12:10 PM, Dave CROCKER wrote:

wow.  more than 16 hours and no one has posted anything.


There are no good solutions.  This feature was intended to cause 
messages with their signatures damaged or missing to not end up in 
someone's mailbox.  Any domain making an ADSP discard assertion should 
expect the domain will become usable on mailing lists.  Such domains 
should be limited to handling transactional emails.


Unfortunately, this view might lead to more phishing exploits whenever 
alternative domains are then used by the same organization.  When there 
is nothing good to be said, perhaps the better choice is to say nothing. 
 Perhaps there should be a standardization for transactional 
sub-domains and stringent requirements where ADSP transactions then 
become superfluous. Where subdomains like secure, or 
signed.somedomain.com versus somedomain.com might be used as a way to 
establish a visual convention.


-Doug
___
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] dkim and email list software - potential solution

[Ian Eiloart]

As far as I recall, Mailman removes DKIM signatures, and re-signs messages. 
You're saying that with ADSP, that's not adequate unless Mailman first 
rewrites the "From:" address. Some lists are configured to do this already, 
the question is what to do about those that don't.


Dave Crocker suggests that it's not the business of the list to fix this. 
That's true, but it is sensible to discuss how list managers could address 
the problem, and it's certainly useful to be aware of the problem - even if 
we conclude that list managers should not attempt to resolve it.


It seems to me that it's sensible for the list software to test the DKIM 
signature before and after any changes it makes to the message. And apply 
these policies:


Good before, good after: deliver the message as normal.

Bad before (broken DKIM sig, or missing a sig that ADSP says should be 
there), reject the message at SMTP time, but that's the MTA's job.


Good before, "discardable" after: If the DKIM signature is good, and the 
return-path is is signed, we can comfortably generate a bounce message. 
Otherwise, I guess we should reject at SMTP time, or bounce to the From 
address, perhaps? Effectively, you're saying to the sender "you've asked 
the recipient to discard the message that I'm about to send on your behalf, 
I'm going to save them the trouble". The RFC warns that use of 
"discardable" means that you're unlikely to get the message through a 
mailing list, but I think it's better to alert the sender. Rejection at 
SMTP time might be more practicable because a significant proportion of 
such email is from addresses that don't accept bounce messages!


The MTA would need to know whether the list was going to rewrite the From: 
header, I suppose.


Bad before, bad after: (DKIM or ADSP fail), reject the message at SMTP time 
if possible. That's the job of the border MTA, though.


Bad before, good after: presumably this is a list that rewrites From 
headers, but I don't think we want this message, so we should reject at 
SMTP time. Alternatively, if the ADSP policy is "discardable", we can 
discard it without guilt. Again, this is probably the job of the border MTA.


If the ADSP policy is "all", then I don't see a problem. The recipient 
should not reject a message from a mailing list just because it doesn't 
carry a matching signature. This is expected behaviour: we know the message 
was sent with a signature, we know the message came from a mailing list, we 
know the list was going to break or remove the signature. We should, 
however, look for a signature from the mailing list, and we should apply 
initial reputation tests (and modifications) to the list, not the original 
sender. If the list has good reputation, we should assume that it tested 
ADSP, and found a good DKIM signature on the original message. We can, 
therefore continue and check (and modify) the reputation of the original 
sender.


That last paragraph makes the job of reputation assignment harder where 
mailing lists are concerned - but that's to be expected. The whole point of 
DKIM, as far as I'm concerned, is to allow more sophisticated assessment 
and assignment of reputation scores.


--On 1 October 2009 18:57:27 +1000 Daniel Black  wrote:



I proposed some ideas around DKIM compatibility with mail lists and tried
to  send here too. Obviously the anti-cross-post feature on mailman-
develop...@python.org is working well (which on some levels I appreciate).

As leading maillist product I'm keep to know your opinion. This has
obviously  been mentioned before never quite got momentum[1]. Now that
ADSP (RFC 5617) is  out it seems that validating domains with a ADSP
policy of dkim=all seems  rather weak as anything other than a temporary
spam bias (until spammers catch  on).

My nice controversial idea is to mangle the from: address in mailing
lists in  general so that the list domain becomes the author (for ADSP
purposes) and  those DKIM validating emails are given the ability to do
more with ADSP than  spam biasing.

Original post here http://mipassoc.org/pipermail/dkim-dev/2009-
September/000202.html

Other ideas welcome.

[1] http://wiki.list.org/display/DEV/DKIM




--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
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] dkim and email list software - potential solution

[Ian Eiloart]

--On 8 October 2009 00:21:08 +1100 Daniel Black  wrote:




You're saying that with ADSP, that's not adequate unless Mailman first
rewrites the "From:" address.

yes, as its easiest place in the whole signing verification scenario to
make a  change that benefits the most people without adversely effecting
anyone  significantly.


Some lists are configured to do this already,

I didn't know this. Anyone know who these are and if they incur any
problems  as result of this rewrite?



In Mailman, it's the "anonymous_list" setting, described thus: 
"anonymous_list (general): Hide the sender of a message, replacing it with 
the list address (Removes From, Sender and Reply-To fields)"


Probably mostly used for announcement only lists.


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
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] dkim and email list software - potential solution

[Ian Eiloart]

--On 8 October 2009 00:21:08 +1100 Daniel Black  wrote:


It seems to me that it's sensible for the list software to test the DKIM
signature before and after any changes it makes to the message.

You can tell from the mailing list settings if it will break without
revalidating it. Same policies apply though.


Doesn't that depend on what's signed, as well as what the list is going to 
alter? Agreed, though, this is an implementation detail.



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
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] dkim and email list software - potential solution

[Ian Eiloart]

--On 8 October 2009 00:21:08 +1100 Daniel Black  wrote:




we know the message came from a mailing list,

this actually is the hard bit. Options for the recipient verifier are:
1. has a List-ID (or other signature) - must be a mailist. This allows
email  spoofers just to add List-ID tags or a simple email characteristic
to bypass  checking.
2. manage a whitelist of maillists that have subscribers in the domain,
that  can't be easily spoofed. Pretty easy for small domains but many
thousand user  bases requires more admin time or run the risk of a user
whitelisting a  spoofer IP address.
3. originator specified third party signatures - discussion (re)-starting
on  IETF WG list on this. Bit labour intensive on the sender part.
(http://mipassoc.org/pipermail/ietf-dkim/2009q4/thread.html)


Well, my reputation assessment scheme says you should check the DKIM 
signature added by the list's domain, if there is one. You only trust the 
list if you have reason to.



--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
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] dkim and email list software - potential solution

[Ian Eiloart]

--On 8 October 2009 00:21:08 +1100 Daniel Black  wrote:




That last paragraph makes the job of reputation assignment harder where
mailing lists are concerned - but that's to be expected. The whole point
of DKIM, as far as I'm concerned, is to allow more sophisticated
assessment and assignment of reputation scores.

Though it can contribute to reputation scores this is taking a strong
cryptographic signature method and contributing it towards a spam score.
This  only goes so far defeating some forms of phishing.


DKIM helps you determine whether an email really was sent by the purported 
sending domain. If it wasn't, that's bad. If it was, that doesn't mean it's 
good, but it does allow you to check the sending domain (or sender) against 
your reputation database, and to modify your view of the sender's 
reputation based on the current email.


Currently, all we really have that's useful for reputation assignment are 
content (too complex) and IP source (too often shared between good and bad 
senders). I'm not saying they're not useful, and there are even some sender 
addresses that you can blacklist.


Without DKIM and SPF, you can't really build a reputation infrastructure 
for sender addresses, because for most spam you're checking or modifying 
the reputation of an innocent third party.


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
___
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] Script to change a member's password

[Mark Sapiro]

Marc Juul wrote:
>
>I'm running mailman 2.1.11 and i wrote a script to change a user's
>password, but it doesn't change anything and i can't seem to find the
>problem. My other "withlist" scripts work fine.
>
>I'm using:
>
>  mlist.setMemberPassword(member, password)
>
>and then
>
>  mlist.Save()


Those are the appropriate methods.


>called using "withlist -l -r"
>
>I have attached my script.


Which didn't make it through this list's contentent filtering. Try
again, renaming it with a .txt extension so it gets a mime content
type of text/plain


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

[Mailman-Developers] a patch: init script cleanup for LSB compliance

[Daniel Novotny]

hello,

There's an effort in Fedora to improve all our init scripts
for better LSB compliance. Because I'm responsible for mailman
package here, I made following changes in the mailman init scripts:

* when mailman is unconfigured, `service mailman start' should exit with code
6, not 1.

* `try-restart' was't implemented. This is an addition to condrestart and
should have the same effect.

* stopping mailman when already stopped doesn't print scary error
  message now, prints "mailman already stopped" instead

* when /var/lock/subsys/mailman exists but mailman isn't running, and `service
mailman status' was executed, the script just printed 'mailman is stopped' and
exited with code 3. In this case, it should say that it's dead but its subsys is
locked, and exit with code 2.

* when no known parameter is passed to the init script, it should exit with
code 2, not 3.

patch attached, references:

http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html
(Linux Standard Base init scripts specification)

https://bugzilla.redhat.com/show_bug.cgi?id=524016
(Red Hat bugzilla entry addressing mailman init scripts)

best regards,

Daniel Novotny, Red Hat inc.diff -up mailman-2.1.12/misc/mailman.in.initcleanup mailman-2.1.12/misc/mailman.in
--- mailman-2.1.12/misc/mailman.in.initcleanup	2009-10-05 09:09:35.0 -0400
+++ mailman-2.1.12/misc/mailman.in	2009-10-05 17:53:56.0 -0400
@@ -91,6 +91,8 @@ function start()
 then
 	touch /var/lock/subsys/$prog
 	InstallCron
+else
+RETVAL=6	
 fi
 echo
 return $RETVAL
@@ -98,6 +100,8 @@ function start()
 
 function stop()
 {
+if [ -f /var/lock/subsys/$prog ]
+then
 echo -n $"Shutting down $prog: "
 mailman-update-cfg
 daemon $MAILMANCTL -q stop
@@ -108,6 +112,10 @@ function stop()
 	RemoveCron
 fi
 echo
+else
+echo $"$prog already stopped."
+RETVAL=0
+fi
 return $RETVAL
 }
 
@@ -135,7 +143,7 @@ case "$1" in
 RETVAL=$?
 ;;
 
-'condrestart')
+'condrestart'|'try-restart')
 $MAILMANCTL -q -u status
 retval=$?
 if [ $retval -eq 0 ]
@@ -146,13 +154,20 @@ case "$1" in
 ;;
 
 'status')
-$MAILMANCTL -u status
+output=$($MAILMANCTL -u status)
 RETVAL=$?
+if [ $RETVAL -eq 3 -a -f /var/lock/subsys/$prog ]
+then
+echo $"$prog dead but subsys locked"
+RETVAL=2
+else
+echo $output
+fi
 ;;
 
 *)
-echo $"Usage: $prog {start|stop|restart|force-reload|condrestart|status}"
-RETVAL=3
+echo $"Usage: $prog {start|stop|restart|force-reload|condrestart|try-restart|status}"
+RETVAL=2
 ;;
 
 esac
___
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] dkim and email list software - potential solution

[Daniel Black]

On Wednesday 07 October 2009 21:00:52 Ian Eiloart wrote:
> As far as I recall, Mailman removes DKIM signatures,
yes
> and re-signs messages.
not that I recall though the MTA is free to sign it on the way out and I 
encourage all list owners to do so.

> You're saying that with ADSP, that's not adequate unless Mailman first
> rewrites the "From:" address.
yes, as its easiest place in the whole signing verification scenario to make a 
change that benefits the most people without adversely effecting anyone 
significantly.

> Some lists are configured to do this already,
I didn't know this. Anyone know who these are and if they incur any problems 
as result of this rewrite?

> the question is what to do about those that don't.
> 
> [not mailing list obligation to fix problem]..., but it is sensible to 
discuss how list managers could address the problem,
thank you

> It seems to me that it's sensible for the list software to test the DKIM
> signature before and after any changes it makes to the message.
You can tell from the mailing list settings if it will break without 
revalidating it. Same policies apply though.
> And apply these policies:
> 
> Good before, good after: deliver the message as normal.
> 
> Bad before (broken DKIM sig, or missing a sig that ADSP says should be
> there), reject the message at SMTP time, but that's the MTA's job.
yes. very easy to do. including dropping broken sigs etc where dkim=all?
> 
> Good before, "discardable" after: (cut) Rejection at
> SMTP time
> The MTA would need to know whether the list was going to rewrite the From:
> header, I suppose.
yes - requested feature just added for this:
https://sourceforge.net/tracker/?func=detail&aid=2874043&group_id=269812&atid=1147704

> Bad before, bad after: (DKIM or ADSP fail), reject the message at SMTP time
> if possible. That's the job of the border MTA, though.
yes
> 
> Bad before, good after: presumably this is a list that rewrites From
> headers, but I don't think we want this message, so we should reject at
> SMTP time.
agree
 
> If the ADSP policy is "all", then I don't see a problem. The recipient
> should not reject a message from a mailing list just because it doesn't
> carry a matching signature. This is expected behaviour: we know the message
> was sent with a signature,

> we know the message came from a mailing list,
this actually is the hard bit. Options for the recipient verifier are:
1. has a List-ID (or other signature) - must be a mailist. This allows email 
spoofers just to add List-ID tags or a simple email characteristic to bypass 
checking.
2. manage a whitelist of maillists that have subscribers in the domain, that 
can't be easily spoofed. Pretty easy for small domains but many thousand user 
bases requires more admin time or run the risk of a user whitelisting a 
spoofer IP address.
3. originator specified third party signatures - discussion (re)-starting on 
IETF WG list on this. Bit labour intensive on the sender part.
(http://mipassoc.org/pipermail/ietf-dkim/2009q4/thread.html)

> we
> know the list was going to break or remove the signature. We should,
> however, look for a signature from the mailing list,
yes good. this falls nicely into #2 above, A strong signature of the email 
list to whitelist. More fully mailing lists should DKIM sign emails (after 
dropping invalid signatures).

> and we should apply initial reputation tests (and modifications) to the 
list, not the original sender. If the list has good reputation, we should 
assume that it tested ADSP, and found a good DKIM signature on the original 
message. We can, therefore continue and check (and modify) the reputation of 
the original sender.

If you have a method of determining if it a list in 1-3 above then this works 
as mailing list domains should gain good reputation quickly (though varying 
list policy between lists or large list servers like sourceforge.net could 
hide bad in the reputation of the majority).

If you are blindly assessing an email without knowledge that is a mailing list 
what do you see? You can check the reputation of the domain on a third party 
DKIM signature and treat this like a mail list above. What would it mean for a 
new list domain/third party sender? My assumption, based on not much 
experience with reputation services, is neutral reputation will allows the 
email though.

Scenario 1:
Putting names on this. Phisher Mallory buys a domain friendly.org sets up DKIM 
on it. Mallory sends email to Bob saying that Bob needs to validate his 
credentials with Bank of Alice. The author of the email looks like Bank of 
Alice (who says has an ADSP policy of dkim=all). Bob's university who filters 
his email doesn't know about friendly.org, so checks it reputation:
(pick an ending)
a) it has a neutral reputation, so lets it though and Bob gets scammed.
b) it has a negative reputation. and gets blocked after Mallory got detected 
sending lots of phishing email and gaining lots of money out of the Bank of 
Ali

Re: [Mailman-Developers] a patch: init script cleanup for LSB compliance

[Mark Sapiro]

Daniel Novotny wrote:
>
>There's an effort in Fedora to improve all our init scripts
>for better LSB compliance. Because I'm responsible for mailman
>package here, I made following changes in the mailman init scripts:


The patch you included is against RedHat's already heavily modified
mailman-2.1.12/misc/mailman.in. See

for the current upstream version.

Also see

for an issue that may or may not affect this.

I am happy to consider incorporating these changes upstream, but I need
the whole file or a patch against my base. I also need the RedHat
changes to bin/mailmanctl that support the 'status' and perhaps other
RedHat extensions.

-- 
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] dkim and email list software - potential solution

[Stephen J. Turnbull]

Daniel Black writes:

 > > You're saying that with ADSP, that's not adequate unless Mailman
 > > first rewrites the "From:" address.

 > yes

In that case it is very often a violation of RFC 733 (most familiarly
known as RFC 822, also STD 11, whose most recent incarnation is RFC
5322).  Surely you already know that!  That's a *lot* of history of
best practice that you are dismissing, it's not going to be acceptable
to a lot of folks,

and in general sucks for users of discussion lists.  Personally, I'd
much rather have my posts dropped.  "Oh yes, your ISP regularly drops
mail because they use broken spam-fighting practices.  It's not just
us, it's every list that conforms to one of the oldest Internet
standards.  If you want to receive your list mail, either subscribe
with an address hosted at a decent ISP, or get your current one to fix
their spam filters."  Most of my users are well-informed, and quite
sympathetic to that argument because they've seen it happen any number
of times.  I really would not appreciate it if "worst practices" were
to become widespread because they cater to the unwashed who just don't
want to receive spam and don't care who pays the cost (as long as it's
not them).


Wouldn't it be more straightforward (not to mention that it would work
for many more lists) to have an LDSP RFC, whose first draft simply
takes the ADSP RFC and substitutes "mailing list" for "author"
everywhere, and "RFC 2369 and RFC 2919 headers" for "From"?  (The
point of multiple headers is that "active" headers like List-Subscribe
could contain bogus URLs.)  A second draft might add "If the list's
host implements ADSP itself, it could also sign the author headers
relevant to ADSP."  Perhaps if it is known that the DKIM signature of
the author's host is going to remain valid, you *don't* sign it,
allowing the recipient to authenticate both the author and the list.

The only real problem with this is getting the big ISPs to implement,
but that's nothing new.  In fact if it's as easy as adding routines to
process the RFC 2369 + RFC 2919 set of headers "just like" ADSP
handles "From:", I bet most would be happy to sign on.

 > > Some lists are configured to [rewrite From:] already,

 > I didn't know this. Anyone know who these are and if they incur any
 > problems as result of this rewrite?

Announce lists are special-purpose lists, ironically mostly used for
something very similar to spamming (except of course, legitimate
"announce" lists are willingly subscribed to).  These are quite
common; they also already fit into the ADSP framework quite well, so
are basically irrelevant to your proposal.

Anonymous discussion lists are special-purpose lists used by folks
like victims of domestic violence.  These are a very good thing IMO,
but again they are not a model for other lists.

 > If you are blindly assessing an email without knowledge that is a
 > mailing list what do you see?

If the list doesn't implement any of RFC 2369 (published 1998) or RFC
2919 (published 2001), the joke is on it.  Otherwise you shouldn't be
blind.  I think it is reasonable to assume that mailing lists are
easily identifiable by the presence of those headers.  For that
precise reason, I propose that they be used instead of "From:" for
ADSP-like authentication of mailing lists.

This is so obvious that I suspect there's some "good" reason why it
won't work, but as long as a harmful alternative is being suggested,
may as well give it a try.

___
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