The breaking up of a large TXT record in a zone file would look like this:
mail._domainkey IN TXT "foo" "bar baz" "blivit"
...which would be treated by libdkim as "foobar bazblivit" (i.e. the
substrings are simply concatenated). However, libdkim does expect every
TXT reply to be a complete record. To wit, the nameserver is free to
return those TXT records in any order, and libdkim has no idea how to
reassemble them in that case. The words in quotes in that example can't
each exceed 255 characters, but the record as a whole can by having more
than one of those strings in it.
Unfortunately it sounds like AT&T's software provides a pretty serious
limitation. Fortunately smaller keys (e.g. 512 bits) do fit inside a
single TXT character string; you're just limited to those smaller keys
until they either remove the limitation or you delegate your _domainkey
subdomain to a nameserver over which you have more direct access.
Were you able to get any evidence of a crash of the filter?

Good morning,
Thanks for the reply. Let me handle the issues one at a time. First the
"*", thats my paranoia, I know that it is a public key that is put out
there for all to read, but when paranoia takes hold you just go with the
flow. More importantly, you are exactly right that the key is broken up
into 4 lines. AT&T, our ISP has a 255 character length text field. Our
key text to publish was just over 300 characters and would truncate and
therefore fail when I used the AT&T text record tool to publish it. I
asked AT&T support to publish it for me, which they did and then they
promptly removed it because according to them it caused problems with
their server. I then found an internet posting (url lost in the mists
of time) on setting up DKIM which mentioned that if the public key was
too long it could be broken into smaller chunks enclosed in double
quotes and would be reconstructed when it was read. This was what I was
attempting and getting the results back which you have seen. Should I
remake the keys ( no reason for them to be any shorter). Any other
ideas? Obviously if I can't publish a key the server side issues won't
matter. As before I am your humble servant so any info you need please ask.
Thanks for the help,
Jim
Murray S. Kucherawy wrote:
> Jim Maloney wrote:
>
>> I have set up DKIM-filter to work with sendmail and have obviously
>> missed something because my mail is not being signed. [...]
>>
>
>
>> mail._domainkey.clubshop.com. IN TXT
>> ( "k=rsa; t=y;"
>> "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Kz+5d4CuaGKRJAKg6vmaBKFJhs6I60c70yIQOj3NwHi"
>>
>> "FIhlu0f/GJGGxSf21JY+VcHNjGcevXkSrpsnTeENF8CkcIyjduDhDsElkFprKTDqeIA50u9BCKkKla4cvzjET"
>>
>> "XRw+6Ijc7bqtKxxOmE2l29K21NwZ********************" )
>>
> What's with all the "*"s?
>
>
>> mail._domainkey. TXT
>> "XRw+6Ijc7bqtKxxOmE2l29K21Nw******************** )" DELETE UPDATE
>> mail._domainkey. TXT "( k=rsa; t=y;" DELETE UPDATE
>> mail._domainkey. TXT
>> "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Kz+5d4CuaGKRJAKg6vmaBKFJhs6I60c70yIQOj3NwHi"
>>
>>
> It looks like you've taken something that should be in one single TXT
> record and spread it across four TXT records. You need to merge them
> all into one record and reload your nameserver with the corrected data.
> The verifying agent will not do that for you as the protocol specifies
> that the reply should be all in one piece.
>
>
>> Tests:
>>
>> sudo /usr/bin/dkim-testkey -d clubshop.com -k /var/db/dkim/mail.key.pem
>> -s mail
>> dkim-testkey: multiple DNS replies for `mail._domainkey.clubshop.com'
>>
>
> That confirms the error.
>
>
>> /var/log/maillog after mailing to sa-test@...
>> Jul 29 11:14:12 outbound2 sendmail[5379]: m6TFEAij005379:
>> from=j.maloney, size=44, class=0, nrcpts=1,
>> msgid=<200807291514.m6TFEAij005379@...>,
>> relay=j.maloney@...
>> Jul 29 11:14:18 outbound2 sendmail[5380]: m6TFECvJ005380:
>> from=<j.maloney@...>, size=356, class=0, nrcpts=1,
>> msgid=<200807291514.m6TFEAij005379@...>, proto=ESMTP,
>> daemon=MTA, relay=outbound2.clubshop.com [127.0.0.1]
>> Jul 29 11:14:28 outbound2 sendmail[5380]: m6TFECvJ005380: Milter
>> (dkim-filter): timeout before data read, where=body
>>
> This is odd; it suggests your filter was either hung or crashed. Do you
> have any core dumps or other evidence that it died and restarted?
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>

Jim Maloney wrote:
> I have set up DKIM-filter to work with sendmail and have obviously
> missed something because my mail is not being signed. [...]
> mail._domainkey.clubshop.com. IN TXT
> ( "k=rsa; t=y;"
> "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Kz+5d4CuaGKRJAKg6vmaBKFJhs6I60c70yIQOj3NwHi"
>
> "FIhlu0f/GJGGxSf21JY+VcHNjGcevXkSrpsnTeENF8CkcIyjduDhDsElkFprKTDqeIA50u9BCKkKla4cvzjET"
>
> "XRw+6Ijc7bqtKxxOmE2l29K21NwZ********************" )
What's with all the "*"s?
> mail._domainkey. TXT
> "XRw+6Ijc7bqtKxxOmE2l29K21Nw******************** )" DELETE UPDATE
> mail._domainkey. TXT "( k=rsa; t=y;" DELETE UPDATE
> mail._domainkey. TXT
> "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Kz+5d4CuaGKRJAKg6vmaBKFJhs6I60c70yIQOj3NwHi"
>
It looks like you've taken something that should be in one single TXT
record and spread it across four TXT records. You need to merge them
all into one record and reload your nameserver with the corrected data.
The verifying agent will not do that for you as the protocol specifies
that the reply should be all in one piece.
>
> Tests:
>
> sudo /usr/bin/dkim-testkey -d clubshop.com -k /var/db/dkim/mail.key.pem
> -s mail
> dkim-testkey: multiple DNS replies for `mail._domainkey.clubshop.com'
That confirms the error.
>
> /var/log/maillog after mailing to sa-test@...
> Jul 29 11:14:12 outbound2 sendmail[5379]: m6TFEAij005379:
> from=j.maloney, size=44, class=0, nrcpts=1,
> msgid=<200807291514.m6TFEAij005379@...>,
> relay=j.maloney@...
> Jul 29 11:14:18 outbound2 sendmail[5380]: m6TFECvJ005380:
> from=<j.maloney@...>, size=356, class=0, nrcpts=1,
> msgid=<200807291514.m6TFEAij005379@...>, proto=ESMTP,
> daemon=MTA, relay=outbound2.clubshop.com [127.0.0.1]
> Jul 29 11:14:28 outbound2 sendmail[5380]: m6TFECvJ005380: Milter
> (dkim-filter): timeout before data read, where=body
This is odd; it suggests your filter was either hung or crashed. Do you
have any core dumps or other evidence that it died and restarted?

On Wed, Jul 30, 2008 at 09:36:42PM -0500, Jim Hermann - UUN Hostmaster <hostmaster@...> wrote:
> Are these _domainkey records correctly formated? My DKIM installation can't
> seem to decipher them.
>
>
> _domainkey.mcsv16.net. 85699 IN TXT "t=y\; o-~\;"
That's a DomainKeys policy record. The DKIM spec doesn't support
DomainKeys policy, and neither does the dkim-milter.
> [the next one has spaces in the middle of the public key, between the cKF
> and 6M9, and between the Bgm and E2Q]
>
> _domainkey.xxxxxx.org. 12597 IN TXT "k=rsa\;
> p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALJZAMpBC6ilsZwTDs3LOvfflc/dw1ojod91u9D9yr
> BcKF 6M92uqm1rO7gTKGjzjCwhDDn7DH/BjWdOoFF4tefI
> G3IrnXJC6Ksr4cJBKQa6BlbfSFcXSAOTZqBgm E2QIDAQAB\;"
>
> [this one has one space in the public key, between the vnY and x8n]
>
> _domainkey.xxxxxx.org. 14027 IN TXT "k=rsa\;
> p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOFWhREX4p485tiNcoT1CcF7aDSvnY
> x8nOfblHKpiIE/Kqnbj6p4V1luSAAvZ3PDixxYwR5UaUK8HpIw8hli1DuMSGM22aLuSVLaqiOpR6
> 7BbwGHaPin1WtnN6p0oMhnQIDAQAB\;"
>
> [more public keys with spaces]
>
> _domainkey.bstock.com. 14400 IN TXT "k=rsa\;
> p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOfIFkk2xLlxqnr8vMCLfMSsTh/aNNUz/Sk1yecLJx
> ETWNrlD99uyg k5cVQTcfcAY
> vYHUWumONgzA1059NyAqxAVR0HvfW0b1TlLOT1Wy3IiymNC2GzHpVIg7NewAOrQIDAQAB\;"
Aside from the spaces in the key (which would certainly break it), all
of these are incorrect by virtue of being at _domainkey.<domain>. Each
key must have a selector name attached, and that selector should be the
first part of the DNS label. For example, I'm currently using the
selector "mail", so my DKIM key is in DNS as such:
mail._domainkey.markley.org IN TXT "v=DKIM1\; k=rsa\; t=y\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDY8qM22+BZVHexjzQUufK/E1TIZbJgRt98MeMiK8CI0W01mJ/C71Ysh2EyK8CHw2wWKqij9ewHIj/Oj/+diW0SIc0B4rfBPw1rAYaXvqX725/NSVVbKOhjujLk4cDec5NclR0D8t0dwwrk9rbfIIjPrlpfXGPgTbfaDP0tvR9XPwIDAQAB"
Regarding your other questions for the list: The first issue looks like
an OpenSSL error, possibly caused by a broken key being published; you
should check and see if the messages causing those errors are coming
from a consistent sending domain or small set of sending domains. Also,
2.7.0 is the current stable release of dkim-milter. There was a beta
release of it previously available, which may be the source of your
confusion. I believe that was labelled as such in the version number.
--
Mike Markley <mike@...>

Are these _domainkey records correctly formated? My DKIM installation can't
seem to decipher them.
_domainkey.mcsv16.net. 85699 IN TXT "t=y\; o-~\;"
[the next one has spaces in the middle of the public key, between the cKF
and 6M9, and between the Bgm and E2Q]
_domainkey.xxxxxx.org. 12597 IN TXT "k=rsa\;
p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALJZAMpBC6ilsZwTDs3LOvfflc/dw1ojod91u9D9yr
BcKF 6M92uqm1rO7gTKGjzjCwhDDn7DH/BjWdOoFF4tefI
G3IrnXJC6Ksr4cJBKQa6BlbfSFcXSAOTZqBgm E2QIDAQAB\;"
[this one has one space in the public key, between the vnY and x8n]
_domainkey.xxxxxx.org. 14027 IN TXT "k=rsa\;
p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOFWhREX4p485tiNcoT1CcF7aDSvnY
x8nOfblHKpiIE/Kqnbj6p4V1luSAAvZ3PDixxYwR5UaUK8HpIw8hli1DuMSGM22aLuSVLaqiOpR6
7BbwGHaPin1WtnN6p0oMhnQIDAQAB\;"
[more public keys with spaces]
_domainkey.bstock.com. 14400 IN TXT "k=rsa\;
p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOfIFkk2xLlxqnr8vMCLfMSsTh/aNNUz/Sk1yecLJx
ETWNrlD99uyg k5cVQTcfcAY
vYHUWumONgzA1059NyAqxAVR0HvfW0b1TlLOT1Wy3IiymNC2GzHpVIg7NewAOrQIDAQAB\;"
Jim
-----
Jim Hermann <hostmaster@...>
UUism Networks <http://www.UUism.net&gt;
Ministering to the Needs of Online UUs
Web Hosting, Email Services, Mailing Lists
-----

Hi Murray,
Thanks for your quick response.
To give some background to the folks on the list: I'm developing an
application that can wrap an LDA to provide DKIM verification. The
purpose of this is to catch the edge case where e-mail is sent to an
account on the same server. Currently, the MTA will invoke dkim-milter in
signing mode and sign the e-mail and the LDA will deliver it locally.
Since the e-mail doesn't pass back through the MTA, there's no way to use
dkim-milter in verify mode to verify these e-mails. I believe my
application may be useful for mailing list applications as well (e.g.
majordomo, etc.).
My intention is to follow the verification code in dkim-filter.c as a
model. I guess I will want to follow this code very closely to provide
the same level of verification that dkim-filter does. In particular, the
function dkimf_authorsigok() implements a checking algorithm that I'll
definitely need for the "dkim-asp=" part of the header. Let me know if
I'm on the right track here.
Does it make sense to abstract the verification/header generation process
a bit? Maybe applications like mine aren't common enough, but it might be
nice if some code could be shared since this code could theoretically be
shared between dkim-filter and my application.
Another question I have is regarding the MUA. Do you know if MUAs in the
future will interpret the Authentication-Results headers and give the user
a pass/fail indication? I was thinking that it might be nice if this
information could be taken into account by MUAs that provide junk mail
filtering (such as Thunderbird). I know that DKIM is fairly new (and
possibly not widely deployed -- yet), but it seems that MUA support for
the headers would help users see a value for DKIM (and, for that matter,
SPF).
Thanks again.
Regards,
Erik.
On Tue, 29 Jul 2008, Murray S. Kucherawy wrote:
> Erik Lotspeich wrote:
>> I am wondering about dkim_getsiglist(). Can a message contain multiple
>> valid signatures? How does this function differ from dkim_getsignature()?
>> When should I use each one?
>>
> It depends on how much control you want over signature processing.
>
> dkim_getsignature() is used late in the process (i.e.after
> end-of-message) to return the first signature that validated or, if none
> did, the first syntactically valid signature. This is useful for an
> application with very simple policies.
>
> dkim_getsiglist() returns all signatures that were minimally
> syntactically valid, and this information is available much earlier in
> message processing (i.e. at end-of-headers). You can use the signature
> array you get back to inspect each one and mark specific ones to be
> ignored by the library. You can request the signature list late in the
> process too if you want to inspect all valid signatures to see which
> one(s) you want to report.
>
> Yes, a message can contain multiple valid signatures, if for example two
> different agents (maybe the sender and his/her ISP) signed it. This is
> why dkim_getsiglist() was added to the API.
>> I also have a question about dkim_sig_getbh(). The comments refer to a
>> "bh" test state. What is the "bh" test state?
>>
>>
> The "bh" tag on a signature is a cryptographic hash of the message
> body. The "bh" flag inside a signature handle is an indication of
> whether or not the body hash in the DKIM signature matched the message
> body the library was given.
>
> This is an important step of DKIM verification. The actual cryptography
> in a DKIM signature only covers the headers and the signature itself
> (which in turn includes the body hash), meaning signature validation
> only proves the headers and signature were unchanged in transit. You
> have to take the extra step of checking that the body hash in the
> signature also matched the body you got, otherwise someone could send an
> altered body and you'd still approve it.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>

Erik Lotspeich wrote:
> I am wondering about dkim_getsiglist(). Can a message contain multiple
> valid signatures? How does this function differ from dkim_getsignature()?
> When should I use each one?
>
It depends on how much control you want over signature processing.
dkim_getsignature() is used late in the process (i.e.after
end-of-message) to return the first signature that validated or, if none
did, the first syntactically valid signature. This is useful for an
application with very simple policies.
dkim_getsiglist() returns all signatures that were minimally
syntactically valid, and this information is available much earlier in
message processing (i.e. at end-of-headers). You can use the signature
array you get back to inspect each one and mark specific ones to be
ignored by the library. You can request the signature list late in the
process too if you want to inspect all valid signatures to see which
one(s) you want to report.
Yes, a message can contain multiple valid signatures, if for example two
different agents (maybe the sender and his/her ISP) signed it. This is
why dkim_getsiglist() was added to the API.
> I also have a question about dkim_sig_getbh(). The comments refer to a
> "bh" test state. What is the "bh" test state?
>
>
The "bh" tag on a signature is a cryptographic hash of the message
body. The "bh" flag inside a signature handle is an indication of
whether or not the body hash in the DKIM signature matched the message
body the library was given.
This is an important step of DKIM verification. The actual cryptography
in a DKIM signature only covers the headers and the signature itself
(which in turn includes the body hash), meaning signature validation
only proves the headers and signature were unchanged in transit. You
have to take the extra step of checking that the body hash in the
signature also matched the body you got, otherwise someone could send an
altered body and you'd still approve it.

Hi,
I have a couple of quick questions about the libdkim API.
I am wondering about dkim_getsiglist(). Can a message contain multiple
valid signatures? How does this function differ from dkim_getsignature()?
When should I use each one?
I also have a question about dkim_sig_getbh(). The comments refer to a
"bh" test state. What is the "bh" test state?
I appreciate any insight you can provide.
Thanks again,
Erik

Murray S. Kucherawy --> dkim-milter-discuss (2008-07-08 16:16:10 -0700):
> The only thing I can think of asking for now is a truss/strace/ktrace of
> the process around the time of the error to see if we can spot the errant
> close() call. Unfortunately if it can take hours or days or weeks for the
> problem to appear, such a log could be enormous.
>
> ...but if you have a way to get one, it might prove valuable.
OK, I'll try to get a trace of the milter process ASAP. But as you
said, this could easily take some weeks...
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~

Murray S. Kucherawy --> dkim-milter-discuss (2008-07-08 16:03:28 -0700):
> On Fri, 23 May 2008, Jukka Salmi wrote:
> > Sure, thanks. With this patch applied, I see mi_wr_cmd() fail with
> > EBADF. Log is [1]available.
> >
> > Regards, Jukka
> >
> > [1] http://salmi.ch/~jukka/dkim-milter/maillog_20080522
>
> Yep, this confirms the previous findings. Everything is fine with the I/O
> between postfix and the filter until:
>
> - postfix sends SMFIC_BODYEOM (end-of-message) to the filter and waits for
> a reply
>
> - postfix immediately decides the wait for the reply has failed (though
> the "why" remains a mystery), shuts down its connection to the filter and
> temp-fails the message
>
> - dkim-filter still thinks the connection is there, so it tries to send an
> SMFIR_INSHEADER (insert header) request, which fails because the socket is
> actually no longer open
>
> - since the insert header request fails, it replies with SMFIR_TEMPFAIL to
> try to get the message to temp-fail, but this also fails since the socket
> is no longer open
>
> We know the second write returns with EBADF, meaning the descriptor has
> been closed from the filter side. If it were the postfix side closing the
> connection, we'd be seeing EPIPE instead of EBADF.
>
> It looks a lot like fd 8 in the dkim-filter process has suddenly become
> invalid for no apparent reason. There's no path that I can see in
> libmilter's source code to having that descriptor closed and yet
> continuing to try to use it. dkim-filter doesn't have access to the
> milter context structure in order to get access to that descriptor number,
> so for it to be the problem it would have to call close() someplace on the
> wrong descriptor number. However, neither libdkim nor dkim-filter ever
> close() anything in normal operation because there's no need to do so.
> libdkim only creates (and later closes, via libcrypto) temporary files for
> certain special circumstances, and your configuration doesn't appear to be
> using any of those.
>
> So, for the moment, I'm stumped. My best guesses now are a bug in the
> underlying socket handling code (i.e. libc or the kernel) or something in
> libcrypto which is causing BIO_free() to close the wrong descriptor from
> time to time.
The systems in question will get an OS upgrade in the next weeks /
months. Let's see if the milter problem disappears with that upgrade...
> Someone said this doesn't happen if you change from UNIX domain sockets to
> TCP sockets. Has this also been tried?
Yes; I was originally using UNIX domain sockets when I first saw the
problem but switched to TCP sockets then to be able to capture the
packets. I haven't switched back since...
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~

On Fri, 18 Jul 2008, Rickard Bondesson wrote:
> Yeah, that is is correct. And also point out that a message, with a
> sender address from our domain, will be signed even if it is delivered
> from an external host.
That's coverred in the OPERATION section of the dkim-filter(8) man page.

Yeah, that is is correct. And also point out that a message, with a
sender address from our domain, will be signed even if it is delivered
from an external host.
On Thu, Jul 17, 2008 at 8:16 PM, Murray S. Kucherawy <msk@...> wrote:
> It sounds like simply changing the description of the default will
> suffice, i.e. change it from "There is no default" to "The default is to
> ignore the MTA name when making the signing decision".
>
> Is that correct?
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>

It sounds like simply changing the description of the default will
suffice, i.e. change it from "There is no default" to "The default is to
ignore the MTA name when making the signing decision".
Is that correct?

"Unfortunately", it hasn't crashed again since I recompiled with the
debugging options.
-John
"Murray S. Kucherawy" <msk@...>
07/16/2008 09:52 PM
To
johnh@...
cc
Subject
Re: [dkim-milter-discuss] dkim-filter dies periodically
Any luck capturing a stack trace or core dump?
--
This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee, or
agent responsible for delivering the message to the intended recipient,
is strictly prohibited. All contents are the copyright property of the
sender. If you are not the intended recipient, you are nevertheless
bound to respect the sender's worldwide legal rights. We require that
unintended recipients delete the e-mail and destroy all electronic
copies in their system, retaining no copies in any media. If you have
received this e-mail in error, please immediately notify us by calling
our Help Desk at (603) 433-1143, or e-mail to it@...
We appreciate your cooperation.

The MTA option does not need to be a domain name, just used it in this
example, could be eg. "sendmail".
My point was that it should be more clear in the manual of when to use
it. So that John Doe does not use it in the wrong context. (From a
usability point of view)
When I first started to use dkim-filter, I thought that you should use
this option in all cases or else the filter would not work. Like if it
was a way for DKIM to know who it was "working" for.
// Rickard
On Thu, Jul 17, 2008 at 12:07 PM, SM <sm@...> wrote:
> At 02:02 17-07-2008, Rickard Bondesson wrote:
>>You can with the MTA option specify which MTA it should sign messages
>>for. The manual for dkim-filter says:
>>
>>"-m mta[,...]
>>A comma-separated list of MTA names (a la the sendmail(8) Dae-
>>monPortOptions Name parameter) whose mail should be signed by
>>this filter. There is no default."
>>
>>Just by reading this will tell John Doe that he should put this option
>>in his configuration file if he wants to be enabled to sign his
>>messages.
>>
>>Eg.
>>MTA exempel2.tset.se
>
> The MTA is not a domain name. It is the name assigned to that "MTA"
> definition.
>
>>If:
>>DAEMON_OPTIONS(`Name=exempel2.tset.se, Addr=mta.exempel2.tset.se, Port=smtp')
>>
>>Everything is fine except that this will enable signing of messages
>>that are delivered from an external part according to the following
>>scenario.
>>
>>The external part sends a message with the spoofed sender
>>admin@... to user@...
>>
>>exempel2.tset.se receives and signs this message since it "apparently"
>>is from our domain and we have activated the MTA option. The MTA
>>option will override the rule below, :
>>"external host gw.iis.se attempted to send as exempel2.tset.se"
>>, since it will sign everything that comes through the server and has
>>it "origin" within its own domain.
>
> According to the above, a message going through mta.exempel2.tset.se
> on port 25 will be signed.
>
>>We have now successfully authenticated us as the "admin", by letting
>>the server do the job for us. What is the point of using the MTA
>>option? It should be clearer what this option will do to the behaviour
>>of the system.
>
> If you are doing SMTP AUTH, then let dkim-filter use that information
> for determining whether the message should be signed.
>
> If you are using sendmail, you can define a MTA name for the
> submission port. All messages submitted through that port gets
> signed if you specify it with -m or in your dkim-filter configuration file.
>
> The MTA option is one of the many ways you have to tell dkim-filter
> which messages should be signed.
>
> Regards,
> -sm
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>

At 02:02 17-07-2008, Rickard Bondesson wrote:
>You can with the MTA option specify which MTA it should sign messages
>for. The manual for dkim-filter says:
>
>"-m mta[,...]
>A comma-separated list of MTA names (a la the sendmail(8) Dae-
>monPortOptions Name parameter) whose mail should be signed by
>this filter. There is no default."
>
>Just by reading this will tell John Doe that he should put this option
>in his configuration file if he wants to be enabled to sign his
>messages.
>
>Eg.
>MTA exempel2.tset.se
The MTA is not a domain name. It is the name assigned to that "MTA"
definition.
>If:
>DAEMON_OPTIONS(`Name=exempel2.tset.se, Addr=mta.exempel2.tset.se, Port=smtp')
>
>Everything is fine except that this will enable signing of messages
>that are delivered from an external part according to the following
>scenario.
>
>The external part sends a message with the spoofed sender
>admin@... to user@...
>
>exempel2.tset.se receives and signs this message since it "apparently"
>is from our domain and we have activated the MTA option. The MTA
>option will override the rule below, :
>"external host gw.iis.se attempted to send as exempel2.tset.se"
>, since it will sign everything that comes through the server and has
>it "origin" within its own domain.
According to the above, a message going through mta.exempel2.tset.se
on port 25 will be signed.
>We have now successfully authenticated us as the "admin", by letting
>the server do the job for us. What is the point of using the MTA
>option? It should be clearer what this option will do to the behaviour
>of the system.
If you are doing SMTP AUTH, then let dkim-filter use that information
for determining whether the message should be signed.
If you are using sendmail, you can define a MTA name for the
submission port. All messages submitted through that port gets
signed if you specify it with -m or in your dkim-filter configuration file.
The MTA option is one of the many ways you have to tell dkim-filter
which messages should be signed.
Regards,
-sm

You can with the MTA option specify which MTA it should sign messages
for. The manual for dkim-filter says:
"-m mta[,...]
A comma-separated list of MTA names (a la the sendmail(8) Dae-
monPortOptions Name parameter) whose mail should be signed by
this filter. There is no default."
Just by reading this will tell John Doe that he should put this option
in his configuration file if he wants to be enabled to sign his
messages.
Eg.
MTA exempel2.tset.se
If:
DAEMON_OPTIONS(`Name=exempel2.tset.se, Addr=mta.exempel2.tset.se, Port=smtp')
Everything is fine except that this will enable signing of messages
that are delivered from an external part according to the following
scenario.
The external part sends a message with the spoofed sender
admin@... to user@...
exempel2.tset.se receives and signs this message since it "apparently"
is from our domain and we have activated the MTA option. The MTA
option will override the rule below, :
"external host gw.iis.se attempted to send as exempel2.tset.se"
, since it will sign everything that comes through the server and has
it "origin" within its own domain.
We have now successfully authenticated us as the "admin", by letting
the server do the job for us. What is the point of using the MTA
option? It should be clearer what this option will do to the behaviour
of the system.
// Rickard Bondesson

hi there,
Murray S. Kucherawy:
> If I get some diagnostic information about the crashing that was reported
> recently, I'll see about getting a patch included in the released version.
Dear Murray - since setting
# milter version for postfix
milter_protocol = 6
in my main.cf I have had no problem for a couple of days which probably
means the issue of DKIM restarting itself is solved just by adding this
setting.
--
Zbigniew Szalbot
http://www.LCWords.com

The first beta release of 2.7.0 is now available via SourceForge for
download and testing.
The usual request applies:
Please restrict discussion of comments on or issues with the Beta to the
dkim-milter-beta list. Don't use this list or the trackers on
SourceForge.
I'm hoping to do the formal release in about a week's time.
The beta contains an update to the new SSP draft (now called "ADSP", or
"Author Domain Signing Practises"), fixes a DNS processing bug, and
services two feature requests.
If I get some diagnostic information about the crashing that was reported
recently, I'll see about getting a patch included in the released version.
I have received a patch to add support for DNSSEC but it's a little too
involved to include in this release. Look forward to that in a near
future release.
Enjoy!
-MSK

Hello
The SSL Error seems to be gone since I reinstalled my system and
cleaned out any remains of old OpenSSL libraries.
Also upgraded from:
Bind 9.4.2
OpenSSL 0.9.8g
to:
Bind 9.5.0
OpenSSL 0.9.8h
// Rickard
On Wed, Jul 9, 2008 at 7:00 PM, Murray S. Kucherawy <msk@...> wrote:
> On Wed, 9 Jul 2008, Rickard Bondesson wrote:
>> This time I did not need to restart Bind. Just waited like 20 minutes
>> and then restarted dkim-filter. The problem remained during these 20
>> minutes. Is there some cache in dkim-filter that would keep bad data and
>> ruin future validations?
>
> If you compiled with QUERY_CACHE, it will maintain old keys in an internal
> cache for up to the TTL of the record it retrieved. Without that it
> re-queries the key from DNS each time, relying on the nameserver's cache
> instead.
>
> Other than that, all data are discarded between verify operations.
>
>> I have activated the Syslog option, but is there a way to have dkim
>> log more events?
>
> Not at present. What additional data would you like to see?
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>