You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
It is not an issue but dlucredativ wanted to let you
Know of my findings
Here is the topic: https://gitlab.com/amavis/amavis/-/issues/123
Initially I thought it is amavis bug so that is why I started conversation there.
In general what is all about:
Postfix by default with milter protocol v6 eats a single white space after “:” in all mail headers if the white space is there
postfix-3.9.0/src/milter/milter8.c - line 2373
if (*cp != ':')
msg_panic("%s: header label not followed by ':'", myname); cp++ = 0; - //Preparing packet (Header Name) eating ":' and terminating name with null char
/ XXX Sendmail by default eats one space (not tab) after the colon. */
if ((milter->ev_mask & SMFIP_HDR_LEADSPC) == 0 && *cp == ' ')
cp++;
//NOTE if there is a space after : it is always eaten:)
Amavisd-milter restores the received header like that:
amavisd-milter/mlfi.c arround line 834
Note: this is from my deb-src package
I just Checked it is same in your git repo
sfsistat
mlfi_header(SMFICTX *ctx, char *headerf, char headerv)
....
/ Write the header to the message file */
(void) fprintf(mlfi->mlfi_fp, "%s: %s\n", headerf, headerv);
adding the white space always
When there is no whitespace eaten from postfix (empty mail header received) extra white space is added by amavisd-milter.
So when DKIM mail header canonicalization Is “simple” this breaks hash. Happened to me with a multi line Subject Header many times. It can happen with any header after all and if it is used in hash with simple canonicalization dkim will fail
What i did was to recompile both postfix - commenting out white space removal in milter8.c and removing the extra white space added by amavisd-milter
and everything works like charm. No more “guessing” i know that i have headers exactly as received from postfix.
Amavis DKIM verification works super with such mails and there are no side effects as far as i can tell. I am not using other milters of course.
Once agin here are the details of our conversation if you are interested:
Hello,
It is not an issue but dlucredativ wanted to let you
Know of my findings
Here is the topic:
https://gitlab.com/amavis/amavis/-/issues/123
Initially I thought it is amavis bug so that is why I started conversation there.
In general what is all about:
postfix-3.9.0/src/milter/milter8.c - line 2373
if (*cp != ':')
msg_panic("%s: header label not followed by ':'", myname);
cp++ = 0; - //Preparing packet (Header Name) eating ":' and terminating name with null char
/ XXX Sendmail by default eats one space (not tab) after the colon. */
if ((milter->ev_mask & SMFIP_HDR_LEADSPC) == 0 && *cp == ' ')
cp++;
//NOTE if there is a space after : it is always eaten:)
amavisd-milter/mlfi.c arround line 834
Note: this is from my deb-src package
I just Checked it is same in your git repo
sfsistat
mlfi_header(SMFICTX *ctx, char *headerf, char headerv)
....
/ Write the header to the message file */
(void) fprintf(mlfi->mlfi_fp, "%s: %s\n", headerf, headerv);
adding the white space always
So when DKIM mail header canonicalization Is “simple” this breaks hash. Happened to me with a multi line Subject Header many times. It can happen with any header after all and if it is used in hash with simple canonicalization dkim will fail
What i did was to recompile both postfix - commenting out white space removal in milter8.c and removing the extra white space added by amavisd-milter
and everything works like charm. No more “guessing” i know that i have headers exactly as received from postfix.
Amavis DKIM verification works super with such mails and there are no side effects as far as i can tell. I am not using other milters of course.
Once agin here are the details of our conversation if you are interested:
https://gitlab.com/amavis/amavis/-/issues/123
Finally all v6 milters + postfix which do verify DKIM will fail with such mails because of postfix whitespace “eating”
beset
Hristo
The text was updated successfully, but these errors were encountered: