pix workaround broken?
Ralf Hildebrandt
I'm seeing quite a few mails in my queue with:
2BB2F167059 5847 Fri Jul 20 12:12:46 sen...@charite.de
(conversation with gate.mlk-berlin.de[194.25.33.188] timed out while
sending end of data -- message may be sent more than once)
reci...@mlk-berlin.de
1515C165F9B 3001 Fri Jul 20 15:52:59 sen...@charite.de
(conversation with mail.3k.gov.hu[195.70.41.194] timed out while
sending end of data -- message may be sent more than once)
reci...@3k.gov.hu
C901F166150 1200372 Fri Jul 20 13:17:09 sen...@charite.de
(conversation with mail.fnk.de[212.202.236.74] timed out while sending
message body)
reci...@fnk.de
If I check these, I get:
# telnet gate.mlk-berlin.de 25
Trying 194.25.33.188...
Connected to gate.mlk-berlin.de.
Escape character is '^]'.
220 *******************************
QUIT
221 gate.mlk-berlin.de closing connection
Connection closed by foreign host.
# telnet mail.3k.gov.hu 25
Trying 195.70.41.194...
Connected to mail.3k.gov.hu.
Escape character is '^]'.
220 ***************************************
QUIT
221 Bye
Connection closed by foreign host.
# telnet mail.fnk.de 25
Trying 212.202.236.74...
Connected to mail.fnk.de.
Escape character is '^]'.
220 ****************************************************************
QUIT
221 - eS...@kwd.intern Service closing transmission channel
Connection closed by foreign host.
So I wonder if the pix workaround may be broken in some way...
The log duly reports:
Jul 23 11:13:30 mail postfix/smtp[25814]: C901F166150: enabling PIX workarounds: disable_esmtp delay_dotcrlf for mail.fnk.de[212.202.236.74]:25
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
A UNIX saleslady, Lenore Likes work, but likes the beach more.
She found a clever way To mix work with play...
She sells C shells by the seashore.
Robert Schetterer
Hash: SHA1
Ralf Hildebrandt schrieb:
Hi Ralf,
last time i had some equal errors Wietse
analyzed them as some broken firewall,in between ,with ethereal,
which cant be debugged from sender site anyway
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGpITZfGH2AvR16oERAplxAJ9411PJCJvu7xOZF5eGVaalhPgDPQCeKS3l
610W25mScxDU05KKwe3eMMU=
=s9KO
-----END PGP SIGNATURE-----
Ralf Hildebrandt
> Hi Ralf,
> last time i had some equal errors Wietse
> analyzed them as some broken firewall,in between ,with ethereal,
> which cant be debugged from sender site anyway
Then I guess it will most likely be the same problem here.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
The secret of flying is simple: Throw yourself at the ground and miss.
Mark Martinec
> I'm seeing quite a few mails in my queue with:
>
> 2BB2F167059 5847 Fri Jul 20 12:12:46 sen...@charite.de
> (conversation with gate.mlk-berlin.de[194.25.33.188] timed out while
> sending end of data -- message may be sent more than once)
> reci...@mlk-berlin.de
> reci...@3k.gov.hu
> reci...@fnk.de
> 220 ****************************************************************
> So I wonder if the pix workaround may be broken in some way...
>
> The log duly reports:
> Jul 23 11:13:30 mail postfix/smtp[25814]: C901F166150: enabling PIX
> workarounds: disable_esmtp delay_dotcrlf for mail.fnk.de[212.202.236.74]:25
More likely than not you are stumbling across some other PIX "esmtp fixup"
issue, where the Postfix workaround does not help. Here is one that
is 'promising':
CSCsg52277
Certain SMTP messages cannot be sent through ASA with 'inspect esmtp' on
http://www.cisco.com/en/US/docs/security/pix/pix72/release/notes/pixrn722.html
(btw, does anyone have more information on this one?)
If you can establish a communication with the administrator on the receiving
side, it would be most helpful to see what their firewall log shows.
I had a case with just these symptoms a few months ago. Because the remote
side had a backup MX relay at their provider's site (before the PIX),
it could be demonstrated that their PIX tears down the TCP session
(without a FIN or ICMP or any other indication), regardless of whether
out mail was being delivered to them directly from us, or indirectly
from their MX relay. It suggests the reason for a disconnect may lie
purely in the mail contents (RFC 2822) and not in the SMTP protocol;
perhaps a long mail header field.
At that time about a dozen of messages were in our mail queue, failing
with every retry. These messages had both the DomainKeys and well as a DKIM
signature (which span a couple of lines each). When I removed a DomainKeys
header field (but kept a DKIM signature) and resent them, all but two of
these messages delivered cleanly right away, but not the remaining two.
When I took the DKIM signature out too, these two stubborn messages
were delivered at last.
I was able to persuade the remote site to turn off the 'esmtp fixup'
in their PIX, and I re-sent the original mesages a second time - they
went through cleanly. Unfortunately I was not able to get into a direct
contant with their firewall administrator, so it remains unknown what
was the exact reason for disconnects - my wild guess is: long folded
header fields. It might be interesting to know if they are able to
receive mail from gmail.com (which is also DKM signed).
Mark
Ralf Hildebrandt
> More likely than not you are stumbling across some other PIX "esmtp fixup"
> issue, where the Postfix workaround does not help. Here is one that
> is 'promising':
>
> CSCsg52277
> Certain SMTP messages cannot be sent through ASA with 'inspect esmtp' on
>
> http://www.cisco.com/en/US/docs/security/pix/pix72/release/notes/pixrn722.html
> (btw, does anyone have more information on this one?)
Indeed, I've been sniffing the content and the "other side" doesn't
even accept anything beyon the first few header line.
> If you can establish a communication with the administrator on the receiving
> side, it would be most helpful to see what their firewall log shows.
Yes, I'll try that.
> I had a case with just these symptoms a few months ago. Because the remote
> side had a backup MX relay at their provider's site (before the PIX),
> it could be demonstrated that their PIX tears down the TCP session
> (without a FIN or ICMP or any other indication), regardless of whether
> out mail was being delivered to them directly from us, or indirectly
> from their MX relay. It suggests the reason for a disconnect may lie
> purely in the mail contents (RFC 2822) and not in the SMTP protocol;
> perhaps a long mail header field.
I haven't postcat'ed our mails (yet).
> At that time about a dozen of messages were in our mail queue, failing
> with every retry.
Same here.
> These messages had both the DomainKeys and well as a DKIM
> signature (which span a couple of lines each).
AH! That could be a reason.
> When I removed a DomainKeys
> header field (but kept a DKIM signature) and resent them, all but two of
> these messages delivered cleanly right away, but not the remaining two.
> When I took the DKIM signature out too, these two stubborn messages
> were delivered at last.
I'll have a look at that as well.
> I was able to persuade the remote site to turn off the 'esmtp fixup'
> in their PIX, and I re-sent the original mesages a second time - they
> went through cleanly. Unfortunately I was not able to get into a direct
> contant with their firewall administrator, so it remains unknown what
> was the exact reason for disconnects - my wild guess is: long folded
> header fields.
Probably. My observations corellate with my introduction of the DKIM
milter.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Windows is the answer, but only if the question was 'what is the
intellectual equivalent of being a galley slave?'
Robert Schetterer
Hash: SHA1
Ralf Hildebrandt schrieb:
If dkim is involved, is there a chance to use some map/list with milter
postfix not to include the sig outgoing to special ips/servers ?
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGpRM2fGH2AvR16oERAnvEAJ4mwWms0yBa0IbMdPF5x4TBd4XSygCdGTk6
vmoVLS1ErwGBft7JA68oa3s=
=K7Pj
-----END PGP SIGNATURE-----
Noel Jones
> >
> > Probably. My observations corellate with my introduction of the DKIM
> > milter.
> >
>If dkim is involved, is there a chance to use some map/list with milter
>postfix not to include the sig outgoing to special ips/servers ?
It's unlikely this can be fixed in the dkim-filter program. In the
case of multi-recipient mail, it would be impossible for the milter
to choose a correct answer.
The only "automatic" solution I can think of is a special postfix
instance that strips out DKIM/DomainKeys headers when sending to
known bad sites. This adds a lot of complexity.
Fortunately, not many sites seem to be affected by this particular
(likely cisco pix) bug.
(I have one site we occasionally send mail to that also cannot accept
DKIM signed mail. DomainKeys are apparently OK. Haven't gotten
anywhere with the remote sysadmin yet even though I personally know
their IT director... grrr.)
--
Noel Jones
Robert Schetterer
Hash: SHA1
Noel Jones schrieb:
Hi Noel , i am trying this just now
dkim-filter -a peerlist .....
## PeerList filename
##
## Contains a list of IP addresses, CIDR blocks, hostnames or domain names
## whos mail should be neither signed nor verified by this filter.
seems that this helped, but i only just had only one mail to such buggy
firewall domain so i could only test it with one mail, it worked
but to verify i have to do some more tests
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGpR1EfGH2AvR16oERAigSAJ42bPGo8KcADtITXoifL1UyGzCmKQCfU0fQ
RdNxhMKlBkbfiY6VCNBkYcc=
=JICT
-----END PGP SIGNATURE-----
Noel Jones
>Hi Noel , i am trying this just now
>dkim-filter -a peerlist .....
>
>## PeerList filename
>##
>## Contains a list of IP addresses, CIDR blocks, hostnames or domain names
>## whos mail should be neither signed nor verified by this filter.
So what's that do with multi-recipient mail?
--
Noel Jones
Robert Schetterer
Hash: SHA1
Noel Jones schrieb:
Hi Noel , i didnt said i have a solution, its just a test,
you and wietse are right this must not solute anything,
one test with one small test mail worked to that buggy domain,
( wietse analysed this domain as firewall broken a few weeks ago )
i cant send more testmails there cause these are customers and i cant
bug them around with test mails in this case,
Perhaps Ralf Hildebrandt could give it a try ( -a peerlist) with his
bugged domains
from starting this thread
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGpSU6fGH2AvR16oERAjJ9AKCHvFLCdB03FtoTWQJOPLczCqwR1QCdEgL2
zVBfHtqROJN6f+oss0Uzxgg=
=JYv8
-----END PGP SIGNATURE-----
Robert Schetterer
Hash: SHA1
Robert Schetterer schrieb:
> Noel Jones schrieb:
>> At 04:27 PM 7/23/2007, Robert Schetterer wrote:
>
>>> Hi Noel , i am trying this just now
>>> dkim-filter -a peerlist .....
>>>
>>> ## PeerList filename
>>> ##
>>> ## Contains a list of IP addresses, CIDR blocks, hostnames or domain
>>> names
>>> ## whos mail should be neither signed nor verified by this filter.
>> So what's that do with multi-recipient mail?
>
>
> Hi Noel , i didnt said i have a solution, its just a test,
> you and wietse are right this must not solute anything,
> one test with one small test mail worked to that buggy domain,
> ( wietse analysed this domain as firewall broken a few weeks ago )
>
> i cant send more testmails there cause these are customers and i cant
> bug them around with test mails in this case,
>
> Perhaps Ralf Hildebrandt could give it a try ( -a peerlist) with his
> bugged domains
> from starting this thread
>
Ok , wietse was right , i tested it with HOLD
some mails with dkim-filter -a peerlist
mails were signed , so this dont works for debugging
such firewall problems
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGpSm7fGH2AvR16oERAsVgAJoCNYWuIOOPrA7AMiXFu7b2qbaWXgCffxQj
o8vYd5R1gjV8SXHd3iFPEfs=
=4JNZ
-----END PGP SIGNATURE-----
Ralf Hildebrandt
> - Update the smtp_header_out() routine to insert a null terminator
> into lines that exceed some pre-defined length (255?). The
> "context" is a pointer to the SMTP_STATE structure with the bit
> flags.
But where IS the limit? Or should it be configurable as well?
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
The only secure Microsoft software is what's still shrink-wrapped in the
warehouse.
Mark Martinec
> > - Update the smtp_header_out() routine to insert a null terminator
> > into lines that exceed some pre-defined length (255?). The
> > "context" is a pointer to the SMTP_STATE structure with the bit
> > flags.
>
> But where IS the limit? Or should it be configurable as well?
It would be really nice if someone with a good Cisco relationship
or at least an effective support contract covering PIX would
find out what exactly is the problem. I heard rumors that
DKIM signatures can indeed cause PIX to disconnect, but I don't
know what aspect of the header field is problematic, and which
versions of PIX are brooken.
Finding what a CSCsg52277 bug is exactly, could be a good start.
It is ironic that Cisco is one of the main supporters of DKIM :)
Mark
Ralf Hildebrandt
> With the proposed workaround we could find out if it is length or
> content related or both.
I could provide LOTS of test-cases :((
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Sysadmins don't go to hell; we're already doing our time in purgatory.
Rod Dorman
> ...
> Finding what a CSCsg52277 bug is exactly, could be a good start.
CSCsg52277 Bug Details:
Certain SMTP messages cannot be sent through ASA with 'inspect esmtp' on
Symptom:
Certain e-mail messages cannot be sent via SMTP across the firewall. The
SMTP session times out on the e-mail client.
Conditions:
ESMTP inspection is enabled within the policy map that covers the traffic.
The e-mail body must contain a period followed by a newline or end of line
character in a certain position. The SMTP payload must be larger than the TCP
Maximum Segment Size (MSS) for the session, so the message body is split into
more than one TCP datagram.
Workaround:
Disable ESMTP Inspection under the respective class within the policy map.
Further Problem Description:
The issue occurs due to the fact that the ESMTP inspection engine treats SMTP
payload starting with .\r\n\ sequence as the end-of-message signal, even when
it was not preceded with \r\n in the previous datagram. So, if the message body
is carried within multiple TCP packets and the split occurs right before .\r\n\
sequence, the SMTP session cannot continue past that point.
--
ro...@polylogics.com "The avalanche has already started, it is too
Rod Dorman late for the pebbles to vote." - Ambassador Kosh
Mark Martinec
> > Finding what a CSCsg52277 bug is exactly, could be a good start.
>
> CSCsg52277 Bug Details: [...]
> Further Problem Description:
> The issue occurs due to the fact that the ESMTP inspection engine treats
> SMTP payload starting with .\r\n\ sequence as the end-of-message signal,
> even when it was not preceded with \r\n in the previous datagram. So, if
> the message body is carried within multiple TCP packets and the split
> occurs right before .\r\n\ sequence, the SMTP session cannot continue past
> that point.
Thanks, that was most kind. Unfortunately it shows it was a false lead,
it is a PIX bug already covered by a Postfix PIX workaround. So it must
be something else. I hope Ralf will be able to dig up new evidence...
Mark
Mark Martinec
> > it is a PIX bug already covered by a Postfix PIX workaround.
>
No, It looked familiar so I thought it was the same thing.
> Postfix's "pause before sending dotcrlf" feature works around a
> different problem: the PIX did not recognize ".\r\n" that spans
> a packet boundary, and therefore Postfix forced a boundary right
> before ".\r\n".
I see.
Nevertheless, it probably does not explain Ralf's problem.
Mark
Ralf Hildebrandt
I had a look at the headers, they don't show a solitary
".\r\n"
Which tcpdump invocation should I use, I'll just create a few tcpdumps
for your amusement...
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Wenn Unternehmen Lehrstühle spenden, dann frage ich mich, ob die nicht
zu wenig Steuern zahlen, denn früher hätte der Staat davon den
Lehrstuhl gestellt.
Victor Duchovni
> * Mark Martinec <Mark.Marti...@ijs.si>:
> > > > Thanks, that was most kind. Unfortunately it shows it was a false lead,
> > > > it is a PIX bug already covered by a Postfix PIX workaround.
> > >
> > > Are you sure?
> >
> > No, It looked familiar so I thought it was the same thing.
> >
> > > Postfix's "pause before sending dotcrlf" feature works around a
> > > different problem: the PIX did not recognize ".\r\n" that spans
> > > a packet boundary, and therefore Postfix forced a boundary right
> > > before ".\r\n".
> >
> > I see.
> >
> > Nevertheless, it probably does not explain Ralf's problem.
>
> I had a look at the headers, they don't show a solitary
> ".\r\n"
>
> Which tcpdump invocation should I use, I'll just create a few tcpdumps
> for your amusement...
# ip=192.0.2.1
# tcpdump -w /some/file -s0 tcp host $ip
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
ghe
On Jul 24, 2007, at 10:18 AM, Rod Dorman wrote:
> Further Problem Description:
> The issue occurs due to the fact that the ESMTP inspection engine
> treats SMTP
> payload starting with .\r\n\ sequence as the end-of-message signal,
> even when
> it was not preceded with \r\n in the previous datagram. So, if the
> message body
> is carried within multiple TCP packets and the split occurs right
> before .\r\n\
> sequence, the SMTP session cannot continue past that point.
Surely Cisco has fixed this -- haven't they? And if so, in which
versions of ASA can SMTE fixup be used?
--
Glenn English
g...@slsware.com
Mark Martinec
The:
tcpdump -s 0 -w /file/name host xx
might be better (in the absence of other heavy traffic to
the named host), so an eventual ICMP packet can be captured too.
On host with multiple interfaces, an -i xxx option may be
needed too.
Mark
Ralf Hildebrandt
> > Which tcpdump invocation should I use, I'll just create a few tcpdumps
> > for your amusement...
>
> # ip=192.0.2.1
> # tcpdump -w /some/file -s0 tcp host $ip
Find the result of my efforts here:
http://www.arschkrebs.de/dumps.tar.gz
three dumps from mail-ausfall.charite.de sending to three pixifixcated
systems:
* gateway.bsd-be.ch
* mail.gracemfg.com
* mail.lfg-berlin.de
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
arbeit! geissel der menschheit! / verflucht seist du bis ans ende
aller tage / du, die du uns elend bringst und not / uns zu krueppeln
machst und zu idioten / uns schlechte laune schaffst und unnuetz
zwietracht saest / uns den tag raubst und die nacht / verflucht seist
du / verflucht / in ewigkeit / amen
Rod Dorman
> ...
> Surely Cisco has fixed this -- haven't they?
Yes, Version 7.2(2) Cisco PIX & Cisco ASA 5500
Ralf Hildebrandt
> Find the result of my efforts here:
> http://www.arschkrebs.de/dumps.tar.gz
> three dumps from mail-ausfall.charite.de sending to three pixifixcated
> systems:
>
> * gateway.bsd-be.ch
> * mail.gracemfg.com
> * mail.lfg-berlin.de
I would have expected Mark to download the file as well... :)
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
A Microsoft Certified Systems Engineer is to computing what a
McDonalds Certified Food Specialist is to fine cuisine
Victor Duchovni
> > Find the result of my efforts here:
> > http://www.arschkrebs.de/dumps.tar.gz
> > three dumps from mail-ausfall.charite.de sending to three pixifixcated
> > systems:
> >
> > * gateway.bsd-be.ch
> > * mail.gracemfg.com
> > * mail.lfg-berlin.de
>
> I would have expected Mark to download the file as well... :)
You watch your logs too closely...
I see no evidence of ".CRLF" on packet boundaries... Just a long
DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=charite.de; s=default;
t=1185283586; bh=z7A+glllCfu6ReMXFJJwpVlXFgU=; h=Received:Received:
X-MimeOLE:Content-class:MIME-Version:Content-Type:
Disposition-Notification-To:Subject:Date:Message-ID:
X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:
From:To:X-OriginalArrivalTime; b=2dSQwuXLGZ4FogtrsqU+JA0azrSZ7gzRk
ewqnz3t427fCr1/vlGN41eWcF2kEpBt5yGM8MzQ+a4s3fGchzyCcY8opR2KxsRZgrDd
OZwush03vNxnpgQrqbirFALZ6+7niQU+a9+8CC4eqxw8L/KOfg+NWxAoIdm6sakKw0S
+xEg=
and a packet boundary in the middle of the Message-Id:
...
Message-ID: <7
the packet that follows ends with:
Gesendet: Montag, 23. Juli
Neither contain "." at beginning of any line, or at the start of a packet,
the issue seems to be the large number of signed headers. The Outlook
headers:
X-MimeOLE:
Content-Class:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic:
Thread-Index:
X-OriginalArrivalTime:
and the optional:
Disposition-Notification-To:
add ~140 bytes to the DKIM-Signature length, pushing it over 512 bytes.
It is also possible that some of the header names inside the "h=" list
are being parsed as (malformed) headers in their own right...
Mark Martinec
> Yes, we all suspect the excessive length. Can I dumb down the
> dkim-milter? I fail to see why it should sign every header...
You could save about 43 characters by choosing a 768-bit signing
key instead of the 1024-bit key.
Mark
Ralf Hildebrandt
> > I would have expected Mark to download the file as well... :)
>
> You watch your logs too closely...
Yup.
> Neither contain "." at beginning of any line, or at the start of a packet,
> the issue seems to be the large number of signed headers. The Outlook
> headers:
>
> X-MimeOLE:
> Content-Class:
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic:
> Thread-Index:
> X-OriginalArrivalTime:
>
> and the optional:
>
> Disposition-Notification-To:
>
> add ~140 bytes to the DKIM-Signature length, pushing it over 512 bytes.
Yes, we all suspect the excessive length. Can I dumb down the
dkim-milter? I fail to see why it should sign every header...
OmitHeaders (string)
Specifies a list of headers which should be omitted when generating signatures. The string should be a colon-
separated list of header names. If an entry in the list names any header which is mandated by the DKIM speci-
fication, the entry is ignored.
Hmm, I wonder why the default isn't sane...
I filled the header you mentioned into OmitHeaders, let's see what
happens.
> It is also possible that some of the header names inside the "h=" list
> are being parsed as (malformed) headers in their own right...
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
First Law of System Requirements:
"Anything is possible if you don't know what you're talking about..."
Victor Duchovni
> > X-MimeOLE:
> > Content-Class:
> > X-MS-Has-Attach:
> > X-MS-TNEF-Correlator:
> > Thread-Topic:
> > Thread-Index:
> > X-OriginalArrivalTime:
> >
> > and the optional:
> >
> > Disposition-Notification-To:
> >
> > add ~140 bytes to the DKIM-Signature length, pushing it over 512 bytes.
>
> Yes, we all suspect the excessive length. Can I dumb down the
> dkim-milter? I fail to see why it should sign every header...
In theory it is sensible to sign most headers, as some of them may be used
for something important downstream. In practice the PIX issues may lead
you to omit some headers.
> OmitHeaders (string)
> Specifies a list of headers which should be omitted when generating signatures. The string should be a colon-
> separated list of header names. If an entry in the list names any header which is mandated by the DKIM speci-
> fication, the entry is ignored.
>
> Hmm, I wonder why the default isn't sane...
> I filled the header you mentioned into OmitHeaders, let's see what
> happens.
For testing, by all means. I am not saying these should not be signed, but
there are not usually present in non-Outlook/Exchange email, and so smaller
signatures result if you leave out these and perhaps also "Received:".