12 Oct
2011
12 Oct
'11
4:58 a.m.
Oct 9 12:29:12 jdc postfix/cleanup[3374]: 50CC118074A6F: milter-reject: END-OF-MESSAGE
from lists2.luv.asn.au[202.158.218.239]: 5.7.1 rejected due to DKIM ADSP evaluation;
from=<luv-main-bounces(a)lists.luv.asn.au> to=<jason(a)jasonjgw.net> proto=ESMTP
helo=<tainted.luv.asn.au>
Oct 11 10:23:02 jdc postfix/cleanup[19312]: 23E771805C2E5: milter-reject: END-OF-MESSAGE
from lists2.luv.asn.au[202.158.218.239]: 5.7.1 rejected due to DKIM ADSP evaluation;
from=<luv-talk-bounces(a)lists.luv.asn.au> to=<jason(a)jasonjgw.net> proto=ESMTP
helo=<tainted.luv.asn.au>
Oct 11 11:23:10 jdc postfix/cleanup[20280]: 49D9118046E51: milter-reject: END-OF-MESSAGE
from lists2.luv.asn.au[202.158.218.239]: 5.7.1 rejected due to DKIM ADSP evaluation;
from=<luv-talk-bounces(a)lists.luv.asn.au> to=<jason(a)jasonjgw.net> proto=ESMTP
helo=<tainted.luv.asn.au>
Oct 12 14:20:49 jdc postfix/cleanup[9322]: 96D1B180C50B5: milter-reject: END-OF-MESSAGE
from lists2.luv.asn.au[202.158.218.239]: 5.7.1 rejected due to DKIM ADSP evaluation;
from=<luv-talk-bounces(a)lists.luv.asn.au> to=<jason(a)jasonjgw.net> proto=ESMTP
helo=<tainted.luv.asn.au>
The only other error in the logs in these instances is "rejected per sender
domain policy".
I'm running OpenDKIM here and I haven't touched the configuration of OpenDKIM,
Postfix, Bind (or anything else).
The problem appears to be gone now anyway. It resulted in temporary suspension
from luv-talk.
2 Nov
2 Nov
7:14 a.m.
I hope and expect it is now on the agenda of our hard-working Luv list
administrators to reconfigure mailman not to break DKIM signatures.
Just a question for others on the list: what are the correct configuration
options for mailman to ensure that headers typically signed by DKIM are not
modified?
Not munging the subject line is the obvious starting point that has been
discussed here. Are there other divergences from the default configuration
which are also necessary?
I know people involved in administering Mailman lists who would probably be
interested in replicating a working configuration.
7:42 a.m.
Quoting Jason White (jason(a)jasonjgw.net):
I hope and expect it is now on the agenda of our
hard-working Luv list
administrators to reconfigure mailman not to break DKIM signatures.
Just a question for others on the list: what are the correct configuration
options for mailman to ensure that headers typically signed by DKIM are not
modified?
Even though I do quite a bit of Mailman administration, I'd not pondered
this issue before. Mailman's wiki has this coverage, which looks
comprehensive: http://wiki.list.org/exportword?pageId=826
7:53 a.m.
Rick Moen <rick(a)linuxmafia.com> wrote:
Even though I do quite a bit of Mailman
administration, I'd not pondered
this issue before. Mailman's wiki has this coverage, which looks
comprehensive: http://wiki.list.org/exportword?pageId=826
It's a helpful document. what it lacks, though, is advice concerning which
options to set to turn off modifications that will likely break signatures.
I've searched the Web but without finding good and reliable guidance. What I
have found suggests that one should:
1. turn off munging of the subject line.
2. turn off changes to the message body, e.g., text appended to the message by
the mailing list.
Is there anything else?
Note that the old Luv list server (Sympa) didn't tend to break signatures. Nor
did it modify the subject field or the body.
3 Nov
3 Nov
7:30 a.m.
Jason White <jason(a)jasonjgw.net> wrote:
It's a helpful document. what it lacks, though, is
advice concerning which
options to set to turn off modifications that will likely break signatures.
I've searched the Web but without finding good and reliable guidance. What I
have found suggests that one should:
1. turn off munging of the subject line.
2. turn off changes to the message body, e.g., text appended to the message by
the mailing list.
I just created a mailman list (wanted for other purposes) and tested it.
the following changes enabled me to send a message to the list which was
posted via the list without breaking the DKIM signature.
subject_prefix = ''
msg_footer = ''
Other relevant options were left as per Mailman defaults, e.g., msg_header
= ''.
11:34 a.m.
On Thu, 3 Nov 2011, Jeremy Visser <jeremy(a)visser.name> wrote:
On 03/11/2011, at 18:30, Jason White wrote:
No it may not.
Legalistic sigs are meaningless. The LUV sig is not legalistic, it's merely
informative.
It's not necessary to turn off the sig when the DKIM signature has the l=
flag, but as gmail (the main source of DKIM signed messages) doesn't appear to
use l= it's probably best to turn it off.
Finally the list server needs to not delete the DKIM header from the mail as
it goes through.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
msg_footer = ''
Omitting that may have legal requirements, may it not? 
11:37 a.m.
On 03/11/2011, at 22:34, Russell Coker wrote:
Legalistic sigs are meaningless. The LUV sig is not
legalistic, it's merely
informative.
I was thinking from an unsubscribing perspective. How else will the user figure out how to
unsubscribe?
And no, I don't think the courts would look too favourably upon a lone
List-Unsubscribe SMTP header that most mail clients won't have a GUI for automating
(only one I can think of is Gmail).
11:58 a.m.
On Thu, 3 Nov 2011, Jeremy Visser <jeremy(a)visser.name> wrote:
On 03/11/2011, at 22:34, Russell Coker wrote:
Every message to the list has six headers that provide various information
about the list. With many MUAs you can just press "v" when in message viewing
mode to see the headers.
Then there's the option that you can just know which lists you subscribed to,
that requires keeping a record of subscription or reading the monthly
informational message. It requires some organisation.
There's also the option of just sending mail to addresses such as $LIST-
unsubscribe, postmaster, or listmaster at the domain which hosts the mailing
list.
It's not difficult.
Legalistic sigs are meaningless. The LUV sig is
not legalistic, it's
merely informative.
I was thinking from an unsubscribing perspective. How else will the user
figure out how to unsubscribe? And no, I don't think the courts would look too
favourably upon a lone
List-Unsubscribe SMTP header that most mail clients won't have a GUI for
automating (only one I can think of is Gmail).
Please cite an example of legal action being taken about list subscription
options being taken to court. If you can't provide a citation then stop this
foolishness.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
4:41 p.m.
Quoting Jeremy Visser (jeremy(a)visser.name):
I was thinking from an unsubscribing perspective. How
else will the
user figure out how to unsubscribe?
1. By Web-searching 'mailman unsubscribe'.
2. By consulting the welcome message he/she was advised to keep for
this exact purpose when he/she joined.
3. By bothering to look at the headers.
And no, I don't think the courts would look too
favourably upon a lone
List-Unsubscribe SMTP header that most mail clients won't have a GUI
for automating (only one I can think of is Gmail).
Clipboard copy and paste isn't broken.
5:01 p.m.
I wrote:
Quoting Jeremy Visser (jeremy(a)visser.name):
4. By Web-searching 'luv unsubscribe'. (As with item #1, above, the
first search hit gives a comprehensive answer.)
I was thinking from an unsubscribing perspective.
How else will the
user figure out how to unsubscribe?
1. By Web-searching 'mailman unsubscribe'.
2. By consulting the welcome message he/she was advised to keep for
this exact purpose when he/she joined.
3. By bothering to look at the headers. 
8:26 p.m.
On 04/11/2011, at 4:01, Rick Moen <rick(a)linuxmafia.com> wrote:
I wrote:
there's still the monthly reminder emails with info on how to unsubscribe, which
serves here same purpose
Quoting Jeremy Visser (jeremy(a)visser.name):
4. By Web-searching 'luv unsubscribe'. (As with item #1, above, the
first search hit gives a comprehensive answer.) I was thinking from an unsubscribing perspective.
How else will the
user figure out how to unsubscribe?
1. By Web-searching 'mailman unsubscribe'.
2. By consulting the welcome message he/she was advised to keep for
this exact purpose when he/she joined.
3. By bothering to look at the headers.
3896
days inactive
3918
days old
11 comments
5 participants
participants (5)
-
hannah commodore -
Jason White -
Jeremy Visser -
Rick Moen -
Russell Coker