![](https://secure.gravatar.com/avatar/cfae3f2a3745c3323d4d418e01c7ed35.jpg?s=120&d=mm&r=g)
I've recently been testing DomainKeys (http://antispam.yahoo.com/domainkeys) and DKIM (which is supposedly a merging of DomainKeys with Cisco's scheme. I am using dk-milter and dkim-milter with sendmail. What this does is add two header lines to outgoing email that allow the receiver to determine the authenticity of the sender...
Anyway, since I run a Mailman system too, I figured this might be a problem. Indeed it is, since the header lines get passed through, and when the check is done, it indicates a failure. DomainKeys recommends mail lists regenerate the keys rather than pass them through.
What I tried was pretty simple: Mailman doesn't have to deal with these things itself, but if it strips the old keys from the header, the keys will be regenerated on the way out by the MTA, thereby making the whole process clean. So the receiver of the email can at least verify that the mail came from the host hosting Mailman. I suppose Mailman could also check email on the way in for valid keys if it wanted, but that's another subject...
I patched Handlers/Cleanse.py as follows:
49a50,55
# JGP: Remove all "DomainKeys" type header lines, since we want these # to be regenerated by the MTA when this message is sent out. We need # to let new such keys be generated because Mailman alters the
message,
# and the old keys would be seen as invalid by the receiver. del msg['domainkey-signature'] del msg['dkim-signature']
I wanted to pass this by the developers here and see if:
This is a reasonable thing to do (or maybe have an option, or even a way to strip selected headers in the config?)
If this is the right place to do it.
-Thanks, Joe
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
On Sat, 2005-09-10 at 15:03, Joe Peterson wrote:
Anyway, since I run a Mailman system too, I figured this might be a problem. Indeed it is, since the header lines get passed through, and when the check is done, it indicates a failure. DomainKeys recommends mail lists regenerate the keys rather than pass them through.
What I tried was pretty simple: Mailman doesn't have to deal with these things itself, but if it strips the old keys from the header, the keys will be regenerated on the way out by the MTA, thereby making the whole process clean.
This is a reasonable thing to do (or maybe have an option, or even a way to strip selected headers in the config?)
If this is the right place to do it.
Cleanse.py is the right place to add this. I'd rather add it unconditionally than add Yet Another Configuration Option to control it though. Is there any reason why you would /not/ want to remove these headers?
-Barry
![](https://secure.gravatar.com/avatar/cfae3f2a3745c3323d4d418e01c7ed35.jpg?s=120&d=mm&r=g)
Barry, I agree. I don't see any reason these headers should be kept, since the alterations Mailman makes to the header and body make the header lines useless and misleading. I made a unified diff from the CVS tree and sibmitted a patch through Sourceforge. I put "2.1" as the version, as I was not sure if this applied to 2.1 or 2.2 alpha.
-Thanks, Joe
Barry Warsaw wrote:
On Sat, 2005-09-10 at 15:03, Joe Peterson wrote:
Anyway, since I run a Mailman system too, I figured this might be a problem. Indeed it is, since the header lines get passed through, and when the check is done, it indicates a failure. DomainKeys recommends mail lists regenerate the keys rather than pass them through.
What I tried was pretty simple: Mailman doesn't have to deal with these things itself, but if it strips the old keys from the header, the keys will be regenerated on the way out by the MTA, thereby making the whole process clean.
This is a reasonable thing to do (or maybe have an option, or even a way to strip selected headers in the config?)
If this is the right place to do it.
Cleanse.py is the right place to add this. I'd rather add it unconditionally than add Yet Another Configuration Option to control it though. Is there any reason why you would /not/ want to remove these headers?
-Barry
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 10 September 2005 13:03:29 -0600 Joe Peterson <joe@skyrush.com> wrote: ...
What I tried was pretty simple: Mailman doesn't have to deal with these things itself, but if it strips the old keys from the header, the keys will be regenerated on the way out by the MTA, thereby making the whole process clean. So the receiver of the email can at least verify that the mail came from the host hosting Mailman. I suppose Mailman could also check email on the way in for valid keys if it wanted, but that's another subject...
No, the MTA should check the keys. That is; if you ever want to reject mail on the basis of them. Mailman can't reject mail without generating collateral SPAM. What would be nice would be a way that Mailman *could* refuse to accept mail from the MTA.
You could also configure your MTA to remove the keys. I presume it will want to do that when forwarding mail for any reason.
-- Ian Eiloart Servers Team Sussex University ITS
![](https://secure.gravatar.com/avatar/cfae3f2a3745c3323d4d418e01c7ed35.jpg?s=120&d=mm&r=g)
Ian Eiloart wrote:
No, the MTA should check the keys. That is; if you ever want to reject mail on the basis of them. Mailman can't reject mail without generating collateral SPAM. What would be nice would be a way that Mailman *could* refuse to accept mail from the MTA.
Yes, the MTA does check the keys when receiving mail. It then puts additional header lines in that tell the result of the check, so Mailman, if it wanted to do a spam check, could check those. But right, Mailman would not want to check the keys directly.
You could also configure your MTA to remove the keys. I presume it will want to do that when forwarding mail for any reason.
Well, with regular (not mail list) forwarding, the keys just get passed through anyway, and this works for DomainKeys (unlike SPF).
For mail list resending (like Mailman does), the keys become invalid due to changes in the header/body, and the milter used by the MTA does not add new keys if it sees keys already there (it thinks the keys can be used to validate the message). Since only Mailman knows it did the mods, it needs to remove the old keys; the message is now really a "new message" to be re distributed. The milter/MTA will then will add new keys before it's sent.
-Joe
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 12 September 2005 08:11:22 -0600 Joe Peterson <joe@skyrush.com> wrote:
Ian Eiloart wrote:
No, the MTA should check the keys. That is; if you ever want to reject mail on the basis of them. Mailman can't reject mail without generating collateral SPAM. What would be nice would be a way that Mailman *could* refuse to accept mail from the MTA.
Yes, the MTA does check the keys when receiving mail. It then puts additional header lines in that tell the result of the check, so Mailman, if it wanted to do a spam check, could check those. But right, Mailman would not want to check the keys directly.
You could also configure your MTA to remove the keys. I presume it will want to do that when forwarding mail for any reason.
Well, with regular (not mail list) forwarding, the keys just get passed through anyway, and this works for DomainKeys (unlike SPF).
For mail list resending (like Mailman does), the keys become invalid due to changes in the header/body, and the milter used by the MTA does not add new keys if it sees keys already there (it thinks the keys can be used to validate the message). Since only Mailman knows it did the mods, it needs to remove the old keys; the message is now really a "new message" to be re distributed. The milter/MTA will then will add new keys before it's sent.
-Joe
Ah, so you're thinking of Sendmail, or something similar. I'm thinking of Exim, which can easily remove the specific headers for an email that it's delivering to Mailman. So, Exim doesn't know that Mailman is going to change the headers, but it can be told!
-- Ian Eiloart Servers Team Sussex University ITS
![](https://secure.gravatar.com/avatar/cfae3f2a3745c3323d4d418e01c7ed35.jpg?s=120&d=mm&r=g)
Yep, sendmail. I'm curous, though: how does Exim know that the mail it is about to deliver is going to Mailman? Does it key off of the fact that it's about to deliver to the mailman program? Well, in any case, if it's done in Cleanse.py in Mailman, the mailer doesn't have to be tweaked, and there's no reason, as Barry said, for Mailman to preserve DomainKeys type headers...
-Joe
Ian Eiloart wrote:
Ah, so you're thinking of Sendmail, or something similar. I'm thinking of Exim, which can easily remove the specific headers for an email that it's delivering to Mailman. So, Exim doesn't know that Mailman is going to change the headers, but it can be told!
![](https://secure.gravatar.com/avatar/6271f25d487757bb93d9f02708448338.jpg?s=120&d=mm&r=g)
--On 12 September 2005 08:48:45 -0600 Joe Peterson <joe@skyrush.com> wrote:
Yep, sendmail. I'm curous, though: how does Exim know that the mail it is about to deliver is going to Mailman? Does it key off of the fact that it's about to deliver to the mailman program?
Yes, that's exactly it. In fact, it checks the presence of the list configuration file.
Well, in any case, if it's done in Cleanse.py in Mailman, the mailer doesn't have to be tweaked, and there's no reason, as Barry said, for Mailman to preserve DomainKeys type headers...
No, that's fair enough.
-Joe
Ian Eiloart wrote:
Ah, so you're thinking of Sendmail, or something similar. I'm thinking of Exim, which can easily remove the specific headers for an email that it's delivering to Mailman. So, Exim doesn't know that Mailman is going to change the headers, but it can be told!
-- Ian Eiloart Servers Team Sussex University ITS
participants (3)
-
Barry Warsaw
-
Ian Eiloart
-
Joe Peterson