From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 13:27:06
|
Hello Murray, After a very long pause with dk/dkim-milter, I finally put it into service here and I'm adding support to it into my filter. I have some small suggestions : * be able to configure a different syslog facility. * add sendmail message ID to the Authentication-Results header, the same way it's added to X-DKIM header * a commented sample of dkim-filter.conf - the same kind of example provided for site.config.m4 If any of these points are good for you, I can work on a patch. Regards, Jose-Marcio |
From: Tony E. <to...@he...> - 2008-01-17 17:19:56
|
Jose-Marcio Martins da Cruz skrev, on 17-01-2008 14:26: > After a very long pause with dk/dkim-milter, I finally put it into > service here and I'm adding support to it into my filter. > > I have some small suggestions : > > * be able to configure a different syslog facility. At my RHL5/FC sites all syslog logging is done by syslog-ng, which gives you whatever logging you want (i.e. it's up to you to learn syslog-ng syntax and extract details from standard log facility logs; After you've learned that it's a breeze). > * add sendmail message ID to the Authentication-Results header, the > same way it's added to X-DKIM header My sites are all Postfix. > * a commented sample of dkim-filter.conf - the same kind of example > provided for site.config.m4 > > If any of these points are good for you, I can work on a patch. I already do this in my RHEL5/FC6 rpm/srpm, available to anyone who wants it (not many). Actually, all this latter stuff should be available long after the midwife has delivered, never before (danger of strangling the infant). Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 17:41:34
|
Tony Earnshaw wrote: > Jose-Marcio Martins da Cruz skrev, on 17-01-2008 14:26: > > At my RHL5/FC sites all syslog logging is done by syslog-ng, which gives > you whatever logging you want (i.e. it's up to you to learn syslog-ng > syntax and extract details from standard log facility logs; After you've > learned that it's a breeze). Maybe, but you can't impose everybody wanting to run dkim-filter to replace syslog program by syslog-ng. Sure, I can patch dkim to do what I want each time I upgrade it. >> * add sendmail message ID to the Authentication-Results header, the >> same way it's added to X-DKIM header > > My sites are all Postfix. All my sites are sendmail. You can't impose everybody wanting dkim-filter to migrate to postfix... If the information is available, dkim-filter adds it to the header. That's what I'm asking for. > > I already do this in my RHEL5/FC6 rpm/srpm, available to anyone who > wants it (not many). > > Actually, all this latter stuff should be available long after the > midwife has delivered, never before (danger of strangling the infant). Why not integrate it into original dkim-filter ? None of our servers runs under Linux. Best, Jose-Marcio -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2008-01-17 19:27:13
|
On Thu, 17 Jan 2008, Tony Earnshaw wrote: >> * add sendmail message ID to the Authentication-Results header, the >> same way it's added to X-DKIM header > > My sites are all Postfix. postfix still generates a job ID which could be included in the header, if appropriate. >> * a commented sample of dkim-filter.conf - the same kind of example >> provided for site.config.m4 >> >> If any of these points are good for you, I can work on a patch. > > I already do this in my RHEL5/FC6 rpm/srpm, available to anyone who > wants it (not many). Is it different than the one our package already includes? Maybe we should look at merging them, if so. -MSK |
From: SM <sm...@re...> - 2008-01-17 19:05:50
|
At 05:26 17-01-2008, Jose-Marcio Martins da Cruz wrote: >After a very long pause with dk/dkim-milter, I finally put it into >service here and I'm adding support to it into my filter. > >I have some small suggestions : > >* be able to configure a different syslog facility. I suggest making it an optional setting. >* add sendmail message ID to the Authentication-Results header, the > same way it's added to X-DKIM header I gather you mean queue-id. I don't think the Authentication-Results draft provides for that. >* a commented sample of dkim-filter.conf - the same kind of example > provided for site.config.m4 There is a dkim-filter/dkim-filter.conf.sample file already. Regards, -sm |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 19:24:05
|
Hi SM, SM wrote: >> * be able to configure a different syslog facility. > > I suggest making it an optional setting. Yes ! Good for me ! > >> * add sendmail message ID to the Authentication-Results header, the >> same way it's added to X-DKIM header > > I gather you mean queue-id. I don't think the Authentication-Results > draft provides for that. Yes ! But does the draft forbid it ? What's the draft number ? I'm asking that as I'd like to be able, inside my milter running just after verifying dkim-filter, to be sure the header I'm seeing was added by dkim-milter running in the same server, and not added by someone other than the dkim-filter running in the same server. > >> * a commented sample of dkim-filter.conf - the same kind of example >> provided for site.config.m4 > > There is a dkim-filter/dkim-filter.conf.sample file already. Sorry, I missed it - maybe somewhere inside INSTALL file, you should mention its presence inside dkim-filter directory. Regards Jose-Marcio -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2008-01-17 19:30:40
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > Yes ! But does the draft forbid it ? What's the draft number ? The draft allows it as a comment but there's no field for it in general. The latest version is included at the top directory of the source package, as "draft-kucherawy-sender-auth-header-10.txt". > I'm asking that as I'd like to be able, inside my milter running just > after verifying dkim-filter, to be sure the header I'm seeing was added > by dkim-milter running in the same server, and not added by someone > other than the dkim-filter running in the same server. The first field of the Authentication-Results: header is the hostname of the host adding the header. Can you check that to verify? > Sorry, I missed it - maybe somewhere inside INSTALL file, you should > mention its presence inside dkim-filter directory. Not a bad idea. -MSK |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 20:05:36
|
Murray S. Kucherawy wrote: > > The first field of the Authentication-Results: header is the hostname of > the host adding the header. Can you check that to verify? It works OK, but... I was thinking about two low probabilities situations. If I was a spammer, I'd add a faked "Authentification-Results" header. This trick can work if : * for some reason, dkim-filter unluckly dies friday night, and stay dead during all week-end. In this case, forged Authentication-Results will be passed to my filter who will consider it's OK. * for some reason, dkim-filter is running but it doesn't remove previous authentication headers. Is this possible without a misconfiguration issue ? Am I wrong ? -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2008-01-17 20:50:02
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > If I was a spammer, I'd add a faked "Authentification-Results" header. This > trick can work if : > * for some reason, dkim-filter unluckly dies friday night, and stay dead > during all week-end. In this case, forged Authentication-Results > will be passed to my filter who will consider it's OK. If that's enough of a concern for your site, you should probably tell the MTA to temp-fail messages when dkim-filter is offline. Adding the job ID as a comment is allowed in the current A-R draft so it would be possible to add. For that matter anything you want could go into a comment, such as a fixed shared secret your other filters all know. That way they can tell that the header was added by an upstream filter you trust and there's no change to the rest of the available information or format. On another note, the first field of the A-R header is supposed to be the hostname, but it doesn't have to be (see sections 2.2 and 2.3 of the draft). You can make it the job ID or any other shared secret if that suits your needs. However, if you do this, other downstream filters which implement the A-R header field removal code won't be able to remove forged headers reliably because they won't know which values in that location are yours and which aren't. I'd take this last idea as an FFR adding a configuration option with the default being to use the hostname as it is now. The documentation will have to reflect the limitation it imposes to some sites. > * for some reason, dkim-filter is running but it doesn't remove previous > authentication headers. Is this possible without a misconfiguration > issue ? Sure, there could be a bug. :-) But assuming no bugs and proper configuration, forged headers should be properly stripped when detected. -MSK |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 21:21:22
|
Murray S. Kucherawy wrote: > On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > If that's enough of a concern for your site, you should probably tell the > MTA to temp-fail messages when dkim-filter is offline. I'd like to avoid tempfail messages during too long. That means delaying many dozens of thousands messages a day. I can't do that. > > Adding the job ID as a comment is allowed in the current A-R draft so it > would be possible to add. For that matter anything you want could go into > a comment, such as a fixed shared secret your other filters all know. > That way they can tell that the header was added by an upstream filter you > trust and there's no change to the rest of the available information or > format. > > On another note, the first field of the A-R header is supposed to be the > hostname, but it doesn't have to be (see sections 2.2 and 2.3 of the > draft). You can make it the job ID or any other shared secret if that > suits your needs. However, if you do this, other downstream filters which > implement the A-R header field removal code won't be able to remove forged > headers reliably because they won't know which values in that location are > yours and which aren't. > > I'd take this last idea as an FFR adding a configuration option with the > default being to use the hostname as it is now. The documentation will > have to reflect the limitation it imposes to some sites. In a normal configuration, there should be, in this order : dkim-filter verifying signature another filter using dkim-filter auth result Options are : * a fixed shared secret between my filter and dkim-filter. But fixed means fixed during a very long time (days, months, years...). If the secret lasts long enough, an attacker can get access to it and use it. Either way, there should be some way to share a secret between dkim-filter and some other filter * the couple (hostname,msgid) is, IMHO, an easy way to share a not fixed secret. I don't agree with SM, as this IS couple is a unique ID. If the message ID is inside a comment, it's good enough for me, as it allows me to ensure better checks, and allows current behaviour of removing old AR. But OK, do what you think it's the best way... -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2008-01-17 21:36:58
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > * the couple (hostname,msgid) is, IMHO, an easy way to share a not fixed > secret. I don't agree with SM, as this IS couple is a unique ID. > > If the message ID is inside a comment, it's good enough for me, as it > allows me to ensure better checks, and allows current behaviour of > removing old AR. But OK, do what you think it's the best way... I'm fine with either the comment method or prepending the job ID (plus a delimiter like "/") to the authserv-id so that the existing header removal code will still work. |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-18 13:49:29
|
Murray S. Kucherawy wrote: > On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: >> * the couple (hostname,msgid) is, IMHO, an easy way to share a not fixed >> secret. I don't agree with SM, as this IS couple is a unique ID. >> >> If the message ID is inside a comment, it's good enough for me, as it >> allows me to ensure better checks, and allows current behaviour of >> removing old AR. But OK, do what you think it's the best way... > > I'm fine with either the comment method or prepending the job ID (plus a > delimiter like "/") to the authserv-id so that the existing header removal > code will still work. Well. Let's agree with some points... * Shall there be a boolean configuration option to tell dkim-milter to add the jobid (if available) to the authserv-id field. I think yes. If you agree, what shall be the name of this option ? * I shall add code to add the jobid value to authserv-id field of the header. This seems easy. When removing AR headers, I shall compare them. It seems to me that it's enough to, allways, split the authserv-id into two fields (before and after the '/' charactere), and use the second part (if the first one isn't empty) with current comparisons (code around line 3131 or dkim-filter.c). Or use the first one, if there isn't a '/' character in the authserv-id. This logic works if the character '/' can't be used in this field for any purpose other than this. Can I assume that ? -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: SM <sm...@re...> - 2008-01-17 21:45:29
|
At 13:21 17-01-2008, Jose-Marcio Martins da Cruz wrote: >* the couple (hostname,msgid) is, IMHO, an easy way to share a not fixed > secret. I don't agree with SM, as this IS couple is a unique ID. That's unique. My comment was about the queue-id only. Regards, -sm |
From: SM <sm...@re...> - 2008-01-17 20:59:46
|
Hi Jose-Marcio, At 12:05 17-01-2008, Jose-Marcio Martins da Cruz wrote: >I was thinking about two low probabilities situations. > >If I was a spammer, I'd add a faked "Authentification-Results" header. >This trick can work if : >* for some reason, dkim-filter unluckly dies friday night, and stay dead > during all week-end. In this case, forged Authentication-Results > will be passed to my filter who will consider it's OK. That would be a problem in such a situation as your filter automatically trusts the A-R header it is getting. I would make sure that the message doesn't get through (tempfail) if dkim-filter dies. That may not be an acceptable "fix" in some environments as mail won't be coming in over the weekend. Using the queue-id would only lower the probability further. >* for some reason, dkim-filter is running but it doesn't remove previous > authentication headers. Is this possible without a misconfiguration > issue ? This situation would arise only if there is a bug in dkim-filter. These situations have been discussed on the Authentication-Results mailing list. Murray posted another proposal (draft-kucherawy-sender-auth-esmtp-00) which conveys the information through an SMTP extension instead of a mail header. That should reduce the scope for forgeries. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2008-01-17 19:24:37
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > * be able to configure a different syslog facility. You should open this as a feature request in SourceForge. > * add sendmail message ID to the Authentication-Results header, the > same way it's added to X-DKIM header What's the purpose of this? And is it sufficient to include it in a RFC2822-style comment? Otherwise I'd also have to update the Authentication-Results: specification to include someplace to store such data. > * a commented sample of dkim-filter.conf - the same kind of example > provided for site.config.m4 There's already one in dkim-filter/dkim-filter.conf.sample. > If any of these points are good for you, I can work on a patch. A patch is certainly welcome for the first two suggestions, but we'd need to flesh out the second before I can determine an appropriate path to take. |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-18 10:42:07
Attachments:
dkim-filter.syslog.patch
|
Murray S. Kucherawy wrote: > On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: >> * be able to configure a different syslog facility. > > You should open this as a feature request in SourceForge. >> If any of these points are good for you, I can work on a patch. > > A patch is certainly welcome for the first two suggestions, but we'd Here is it... 8-) I haven't added it as a FFR as it's a really trivial patch, without side effects. Sorry, but my really old sourceforge login doesn't allow me to open a request feature. (Error - Choose a group - No group_id choosen). Not enough time to debug this. Friendly Jose-Marcio > need to flesh out the second before I can determine an appropriate path > to take. > -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: SM <sm...@re...> - 2008-01-17 20:38:38
|
Hi Jose-Marcio, At 11:24 17-01-2008, Jose-Marcio Martins da Cruz wrote: >Yes ! But does the draft forbid it ? What's the draft number ? It's draft-kucherawy-sender-auth-header-10. There's a copy in the tarball. >I'm asking that as I'd like to be able, inside my milter running just >after verifying dkim-filter, to be sure the header I'm seeing was added >by dkim-milter running in the same server, and not added by someone >other than the dkim-filter running in the same server. If I understood correctly, you want to ensure that the Authentication-Results (A-R) header was added by you server and not before that. The draft uses the authentication identifier field (authserv-id) for that. It's generally the FQDN of the server but you can change that (Section 2.3). However, queue-id may not be a valid authserv-id as you cannot guarantee uniqueness for it from a global perspective. It also leaves room for abuse. Dkim-milter will remove an A-R header with your FQDN as the authserv-id if it's part of the existing headers. See RemoveARFrom in the dkim-filter.conf manual. Regards, -sm |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-17 20:49:53
|
Hi again. SM wrote: > Hi Jose-Marcio, > At 11:24 17-01-2008, Jose-Marcio Martins da Cruz wrote: >> Yes ! But does the draft forbid it ? What's the draft number ? > > It's draft-kucherawy-sender-auth-header-10. There's a copy in the tarball. Thanks. I looked for docs at dkim.org site. Ther's no mention to these drafts there. 8-( Well, I'll take the time to read all these drafts inside the tarball. > (authserv-id) for that. It's generally the FQDN of the server but you > can change that (Section 2.3). However, queue-id may not be a valid > authserv-id as you cannot guarantee uniqueness for it from a global > perspective. It also leaves room for abuse. Well, authserv-id + msgid -> really hard to forge. > > Dkim-milter will remove an A-R header with your FQDN as the authserv-id > if it's part of the existing headers. See RemoveARFrom in the > dkim-filter.conf manual. See my previous message -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr Ecole des Mines de Paris 60, bd Saint Michel 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2008-01-17 20:53:05
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: >> At 11:24 17-01-2008, Jose-Marcio Martins da Cruz wrote: >>> Yes ! But does the draft forbid it ? What's the draft number ? >> >> It's draft-kucherawy-sender-auth-header-10. There's a copy in the tarball. > > Thanks. I looked for docs at dkim.org site. Ther's no mention to these > drafts there. 8-( That draft isn't part of the DKIM working group, which is why you don't see it listed there. |
From: Murray S. K. <ms...@se...> - 2008-01-17 21:10:48
|
On Thu, 17 Jan 2008, Jose-Marcio Martins da Cruz wrote: > Well, authserv-id + msgid -> really hard to forge. Or better yet, "jobID/authserv-id", because the existing A-R stripping code could match that by domain name. (See dkim-filter.conf(5)'s description of RemoveARFrom.) |
From: Jose-Marcio M. da C. <Jos...@en...> - 2008-01-19 22:36:30
Attachments:
dkim-milter-2.4.3.patch
|
Hello, Murray S. Kucherawy wrote: > > I'm fine with either the comment method or prepending the job ID (plus a > delimiter like "/") to the authserv-id so that the existing header removal > code will still work. > Here is a patch for dkim-milter 2.4.3, with both changes : * being able to select any syslog facility other than LOG_MAIL Enable this with "SyslogFacility", configuration option. * prepending the job ID plus a "/". Enable this with "AuthservIDWithJobID" configuration option. This change is protected by a _FFR_AUTHSERV_JOBID compile time option. Please, let me know if this is OK for you. Regards, José-Marcio |
From: Murray S. K. <ms...@se...> - 2008-01-22 01:11:45
|
I've attached these to separate entries in the Feature Requests tracker on SourceForge. They're slated for v2.5.0. It's worth noting that I now have 10 items slated for inclusion in the 2.5.0 release, but no schedule for it. However the workload should be quite manageable because six of those already have patches available from either my own free time or contributors like you. Thanks to all for your contributions! -MSK |