I've been trying to get DomainKeys to work on my mail server. I know
this is not the DKIM newsgroup, but there's one issue I'd like to know
about before I dismiss it as the cause of the problem.

My mail server breaks up long headers with "\r\t" characters. Here's an
example of what I mean:

DomainKey-Signature: a=rsa-sha1; s=mail; d=nevis.columbia.edu; c=simple;
q=dns;
b=jXOJ3HiGQX+GP/t0eaAkXa0tHj4jZbs1jlI1xK9F4dhzHhHfNqa9PF7MvWf+kP0j K
xALUc16S1FBwbSehokU4w==

As you can see, the "b=" field (containing the DomainKey signature
information) has been broken into two lines.

When I've gotten my mailer to authenticate other folks' DKIM-signed
messages, their headers have had the keys on a single line; none of
their headers were "broken up" into separate lines.

I've googled around, and searched the Bat book, but I can't find any
parameter that controls whether a header is broken up, or how. I'm not
even sure whether it's sendmail, procmail, or something else that's
reformatting the header.

Does anyone have any insight into what portion of the mail process is
inserting the "/r/t" into the header, and how I might it turn it off, at
least for testing purposes?

Thanks.
-- Bill

Bill Seligman wrote:
> I've been trying to get DomainKeys to work on my mail server. I know
> this is not the DKIM newsgroup, but there's one issue I'd like to know
> about before I dismiss it as the cause of the problem.
>
> My mail server breaks up long headers with "\r\t" characters. Here's an
> example of what I mean:
>
> DomainKey-Signature: a=rsa-sha1; s=mail; d=nevis.columbia.edu; c=simple;
> q=dns;
> b=jXOJ3HiGQX+GP/t0eaAkXa0tHj4jZbs1jlI1xK9F4dhzHhHfNqa9PF7MvWf+kP0j K
> xALUc16S1FBwbSehokU4w==
>
> As you can see, the "b=" field (containing the DomainKey signature
> information) has been broken into two lines.

The format of mail headers (and the folding and unfolding of long
headers) is defined in rfc2822. Normaly can folding only be done
at a place in the header with existing whitespace.

But see the definition of the DomainKey-Signature header at
http://www.ietf.org/internet-drafts/...ys-base-06.txt

INTERNET DRAFT Mark Delany
Title: draft-delany-domainkeys-base-06.txt Yahoo! Inc
Expires: 24 January 2007 25 July 2006

Domain-based Email Authentication Using Public Keys
Advertised in the DNS (DomainKeys)

[...]

For extensibility, the "DomainKey-Signature:" header contains
tag=value pairs separated by semicolons, e.g.:

DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
q=dns; c=simple

The current valid tags are:

a = The algorithm used to generate the signature. The default is
"rsa-sha1", an RSA signed SHA1 digest. Signers and verifiers
MUST support "rsa-sha1".

b = The signature data, encoded as a Base64 string. This tag MUST
be present.

Whitespace is ignored in this value and MUST be removed when
re-assembling the original signature. This is another way of
saying that the signing process can safely insert folding
whitespace in this value to conform to line-length limits.

[...]



So there is nothing wrong with your header as far as I can see.

Kees.

--
Kees Theunissen.

In article <79907$4547c1ff$c02a7def$2145@news1.tudelft.nl> Kees
Theunissen <theuniss@rijnh.nl> writes:
>Bill Seligman wrote:
>> I've been trying to get DomainKeys to work on my mail server. I know
>> this is not the DKIM newsgroup, but there's one issue I'd like to know
>> about before I dismiss it as the cause of the problem.
>>
>> My mail server breaks up long headers with "\r\t" characters. Here's an
>> example of what I mean:
>>
>> DomainKey-Signature: a=rsa-sha1; s=mail; d=nevis.columbia.edu; c=simple;
>> q=dns;
>> b=jXOJ3HiGQX+GP/t0eaAkXa0tHj4jZbs1jlI1xK9F4dhzHhHfNqa9PF7MvWf+kP0j K
>> xALUc16S1FBwbSehokU4w==
>>
>> As you can see, the "b=" field (containing the DomainKey signature
>> information) has been broken into two lines.
>
>The format of mail headers (and the folding and unfolding of long
>headers) is defined in rfc2822. Normaly can folding only be done
>at a place in the header with existing whitespace.
>
>But see the definition of the DomainKey-Signature header at
>http://www.ietf.org/internet-drafts/...ys-base-06.txt
>
> INTERNET DRAFT Mark Delany
> Title: draft-delany-domainkeys-base-06.txt Yahoo! Inc
[snip]

>So there is nothing wrong with your header as far as I can see.

I would agree - but does the software doing the folding really "know"
that? Unless it's the one inserting the header (i.e. it is actually
folded to start with), this seems unlikely, in which case the folding
sofware is broken.

Anyway, sendmail doesn't fold headers (unless they would exceed the SMTP
line length limit of ~ 1000 chars) AFAIK - in particular not headers
that it doesn't even "process", and DomainKey-Signature would definitely
be in that category.

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

>>So there is nothing wrong with your header as far as I can see.
>
>
> I would agree - but does the software doing the folding really "know"
> that? Unless it's the one inserting the header (i.e. it is actually
> folded to start with), this seems unlikely, in which case the folding
> sofware is broken.

The OP quoted a correctly folded header, so apearently the software
that has been used for that knew how to do it.

And it's not important wether the header was folded later or right
from the beginning.
It doesn't matter which software did the folding (and there will often
not be an easy way to discover who did it) as long as the result
conforms to the (draft) standard. Even if a 'later' program does some
extra folding (or unfolding and a different folding for that matter)
as long as the result is correct I don't see any problem.

If another program has trouble interpreting a correctly folded header
and recontructing the encoded key from the header, then _that_ program
is broken.

>
> Anyway, sendmail doesn't fold headers (unless they would exceed the SMTP
> line length limit of ~ 1000 chars) AFAIK - in particular not headers
> that it doesn't even "process", and DomainKey-Signature would definitely
> be in that category.
>
> --Per Hedeland
> per@hedeland.org

--
Kees Theunissen.

Kees Theunissen wrote:
> Per Hedeland wrote:
>
>>> So there is nothing wrong with your header as far as I can see.
>>
>>
>>
>> I would agree - but does the software doing the folding really "know"
>> that? Unless it's the one inserting the header (i.e. it is actually
>> folded to start with), this seems unlikely, in which case the folding
>> sofware is broken.
>
>
> The OP quoted a correctly folded header, so apearently the software
> that has been used for that knew how to do it.

Per,

Reading your wording again; you might have a point if you mean that
it is a new specification and that older software probably doesn't
have any knowledge of the special handling of _this_ header.
If the header was folded in the middle of a string, by an other
program without knowledge of this specification, that certainly
would be against rfc2822 specifications.

But maybe you should say that the new protocol or specification
would be broken if it didn't anticipate on to be expected actions
of older solftware that isn't aware of the new specs.

And a robust implementation of a new specification shouldn't take
any risk and do the proper folding right from the beginning
as soon as the header is inserted.
So I think it's likely that the folding was done by the program
that inserted the header

Regards,

Kees.

In article <ac532$4547f596$c02a7def$8039@news2.tudelft.nl> Kees
Theunissen <theuniss@rijnh.nl> writes:
>Kees Theunissen wrote:
>> Per Hedeland wrote:
>>
>>>> So there is nothing wrong with your header as far as I can see.
>>>
>>>
>>>
>>> I would agree - but does the software doing the folding really "know"
>>> that? Unless it's the one inserting the header (i.e. it is actually
>>> folded to start with), this seems unlikely, in which case the folding
>>> sofware is broken.
>>
>>
>> The OP quoted a correctly folded header, so apearently the software
>> that has been used for that knew how to do it.
>
>Per,
>
>Reading your wording again; you might have a point if you mean that
>it is a new specification and that older software probably doesn't
>have any knowledge of the special handling of _this_ header.

Yes, that was more or less my point - though I wouldn't even add the
"older", it seems unlikely that any generic header-folding software
would have knowledge of specific headers that can tolerate folding
beyond what 2822 allows.

>If the header was folded in the middle of a string, by an other
>program without knowledge of this specification, that certainly
>would be against rfc2822 specifications.

And AFAIK 2822 specifications don't say "it's OK to fold some headers in
ways not described here, if it is known to not cause harm to those
headers". I.e. it would be against 2822 specifications period.

>But maybe you should say that the new protocol or specification
>would be broken if it didn't anticipate on to be expected actions
>of older solftware that isn't aware of the new specs.
>
>And a robust implementation of a new specification shouldn't take
>any risk and do the proper folding right from the beginning
>as soon as the header is inserted.

Or at least insert some whitespace, to allow folding per 2822. There are
probably some hints on this to be taken from the MIME spec for base64-
encoding of headers with non-ascii characters, I haven't checked
(i.e. it would be possible but unwise to encode the entire header as a
single =?...?B?...?= string).

--Per Hedeland
per@hedeland.org

Bill Seligman wrote:

> I've been trying to get DomainKeys to work on my mail server. I know
> this is not the DKIM newsgroup, but there's one issue I'd like to know
> about before I dismiss it as the cause of the problem.

I believe I have isolated my DomainKey issue, and as stated elsewhere (I
haven't bothered to quote the discussion), it does not appear to have
anything to do with header folding. But it still appears to have
something to do with sendmail, so again I ask for assistance.

The problem appears to be that in the message passed to the DKIM
software, a header reads:

To: sa-test@sendmail.net

But according to the sa-test reflector, the message they receive has:

To: sa-test@sendmail.net

In other words, something has removed an extra space after the "To:" in
the header, which breaks the DKIM signature. The "To:" header is
apparently the only header for which this happens.

Now I must ask what are probably the most inane questions posed to this
newsgroup: What portion of the sendmail process might control the
reformatting of the "To:" header to eliminate extra spaces? Or the
opposite question: what could put an extra space in the "To:" header in
the first place?

-- Bill

P.S.: An editorial: It's issues like this that convince me that
DomainKey is still not a robust enough signature method to deal with the
"real world" of e-mail.

Bill Seligman wrote:
> Bill Seligman wrote:
>
>> I've been trying to get DomainKeys to work on my mail server. I know
>> this is not the DKIM newsgroup, but there's one issue I'd like to know
>> about before I dismiss it as the cause of the problem.
>
> I believe I have isolated my DomainKey issue, and as stated elsewhere (I
> haven't bothered to quote the discussion), it does not appear to have
> anything to do with header folding. But it still appears to have
> something to do with sendmail, so again I ask for assistance.
>
> The problem appears to be that in the message passed to the DKIM
> software, a header reads:
>
> To: sa-test@sendmail.net
>
> But according to the sa-test reflector, the message they receive has:
>
> To: sa-test@sendmail.net
>
> In other words, something has removed an extra space after the "To:" in
> the header, which breaks the DKIM signature. The "To:" header is
> apparently the only header for which this happens.
>
> Now I must ask what are probably the most inane questions posed to this
> newsgroup: What portion of the sendmail process might control the
> reformatting of the "To:" header to eliminate extra spaces? Or the
> opposite question: what could put an extra space in the "To:" header in
> the first place?

I have a partial answer to my question above.

The extra space after the "To:" is being put there by my MUA, Mozilla's
Thunderbird. It only does this if I don't have some sort of identifier
before the name; e.g.,

To: "DKIM reflector" <dkim-test@altn.com>

works just fine, as do other MUA's such as Apple's Mail.

Argh! What a pain!

-- Bill

Bill Seligman wrote:
> Bill Seligman wrote:
>> Bill Seligman wrote:
>>
>>> I've been trying to get DomainKeys to work on my mail server. I know
>>> this is not the DKIM newsgroup, but there's one issue I'd like to know
>>> about before I dismiss it as the cause of the problem.

>> I believe I have isolated my DomainKey issue...
>>
>> The problem appears to be that in the message passed to the DKIM
>> software, a header reads:
>>
>> To: sa-test@sendmail.net
>>
>> But according to the sa-test reflector, the message they receive has:
>>
>> To: sa-test@sendmail.net

> The extra space after the "To:" is being put there by my MUA, Mozilla's
> Thunderbird.

I've hunted around, looked at my .cf file, gone over the section of the
Bat book on R configuration. The existing rules already trim any
leading whitespace from an address listed in a "rcpt to:"; I tested and
confirmed this with my mail server. The issue appears with the "To:"
lines included in the header.

Does anyone have any insight into how and where I'd implement something
like: "If a 'To:' line in the header has any whitespace following the
colon, replace it with a single space"?

- Bill

Bill Seligman wrote:
> Bill Seligman wrote:
>> Bill Seligman wrote:
>>> Bill Seligman wrote:
>>>
>>>> I've been trying to get DomainKeys to work on my mail server. I know
>>>> this is not the DKIM newsgroup, but there's one issue I'd like to know
>>>> about before I dismiss it as the cause of the problem.
>
>>> I believe I have isolated my DomainKey issue...
>>>
>>> The problem appears to be that in the message passed to the DKIM
>>> software, a header reads:
>>>
>>> To: sa-test@sendmail.net
>>>
>>> But according to the sa-test reflector, the message they receive has:
>>>
>>> To: sa-test@sendmail.net
>
>> The extra space after the "To:" is being put there by my MUA, Mozilla's
>> Thunderbird.

The solution turns out to be to pick "relaxed" canonicalization (for
DKIM) or "nofws" canonicalization (for DomainKeys). Then these extra
spaces don't matter anymore.

-- Bill