OT: Fail2ban linux
Hi People! Anyone has a good rule for postfix smtpd whit fail2ban? Sorry for the OT:)) []'s -- - _Engº Julio Cesar Covolato 0v0 ju...@psi.com.br /(_)\ F: 55-11-3129-3366 ^ ^ PSI INTERNET -
Re: OT: Fail2ban linux
On Sun, 12 Oct 2014 03:27:41 -0300 Julio Cesar Covolato ju...@psi.com.br wrote: Anyone has a good rule for postfix smtpd whit fail2ban? Google is not enough for you? http://www.fail2ban.org/wiki/index.php/Postfix
Re: Thank you, Wietse
I just wanted to second that as well. Thx Sent from my BlackBerry device on the Rogers Wireless Network -Original Message- From: Venkat mvenkat...@gmail.com Sender: owner-postfix-us...@postfix.org Date: Sat, 11 Oct 2014 21:08:14 Cc: Postfix userspostfix-users@postfix.org Subject: Re: Thank you, Wietse On Sat, Oct 11, 2014 at 7:12 PM, LuKreme krem...@kreme.com wrote: On 10 Oct 2014, at 18:49 , Stephen Satchell l...@satchell.net wrote: Sometimes we just need to say this. Probably every day, but then the list would get kinda spammy and boring. But yes, thanks. -- Cecil is made of blood and unfinished leather Every day and more. Wietse (and Viktor) are some of the nicest guys I have found in the tech community and I really appreciate their taking the time to answer directly a multitude of questions on this mailing list. Thank you Wietse and Viktor and everyone who contributes to Postfix! It is awesome!
many domains fail dkim sig check
i wrote to the relevant dkim/dmarc lists but still i find the following errors from opendkim/opendmarc consistently with every message could somebody please suggest which settings, if there are any within postfix, that may alleviate these failures ? overall, on the other hand, i see many successful verifications as well but id like to know why some still fail surely it can't be that all gmail.com and google.com messages are modified in transit, somehow ie. opendkim[3561]: : mail-wi0-f202.google.com [209.85.212.202] not internal opendkim[3561]: : not authenticated opendkim[3561]: : signature=lnkRpgLM domain=google.com selector=20120113 result=signature verification failed opendkim[3561]: : s=20120113 d=google.com SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[3561]: : bad signature data opendmarc[3526]: : google.com fail opendkim[4560]: : n13-vm7.bullet.mail.ne1.yahoo.com [98.138.121.231] not internal opendkim[4560]: : not authenticated opendkim[4560]: : signature=B+PrvMlb domain=yahoo.com selector=s2048 result=signature verification failed opendkim[4560]: : s=s2048 d=yahoo.com SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[4560]: : bad signature data opendmarc[26995]: : dmarc.yahoo.com none opendkim[8288]: : snip1.dnsops.gov [129.6.100.200] not internal opendkim[8288]: : not authenticated opendkim[8288]: : signature=PrBejfsW domain=had-pilot.biz selector=mailkey result=signature verification failed opendkim[8288]: : s=mailkey d=had-pilot.biz SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[8288]: : bad signature data opendmarc[26995]: : had-pilot.biz none the operator of had-pilot believes and is is confident their dkim sigs are correct
Lost Connections on a Grand Scale - is it DoS and should I report it?
Hi, I often get a spate of lost connections from servers chancing to access my email via SMTP AUTH (which I do not offer), and I usually ignore them. I may get a session with up to 1,000+ connections usually from a whole list of servers and none trying more than a dozen times. Yesterday, however, I got 10,000+ lost connections from one IP address (178.150.135.178) in a continuous assault lasting several hours. I limit connections from the wan on port 25 to 1/s so I can only imagine the number of attempts I might have got if I did not. Is this just a mad bot or a DoS attack that failed cos of my connection limit? Should I report it to my ISP or just ignore it like the others? Also, I have been looking to set up Postscreen (now that I realise it is not something that screens emails after/post arrival!) I put it off while I hardened my server - did not want to change postfix at the same time in case hardening all went wrong - but perhaps it is worth configuring if only to stop my logs filling with Lost Connection reports? Thanks in anticipation of any helpful comments, Robert Sharp
Re: Compiling new postfix same as the old postfix
LuKreme: On 10 Oct 2014, at 18:42 , Wietse Venema wie...@porcupine.org wrote: A few minutes ago I updated the makedefs script so that it documents the make makefiles options in a comment at the beginning of the file makedefs.out which is usually installed in $config_directory. Is this something that will help me reconstruct the make flags I used when I compiled 2.10 or just a useful feature for the future? Look for the EXPORT line. This has AUXLIBS and CCARGS, which you would use as $ make makefiles CCARGS='stuff' AUXLIBS='stuff' Wietse
Re: Compiling new postfix same as the old postfix
Wietse Venema: LuKreme: On 10 Oct 2014, at 18:42 , Wietse Venema wie...@porcupine.org wrote: A few minutes ago I updated the makedefs script so that it documents the make makefiles options in a comment at the beginning of the file makedefs.out which is usually installed in $config_directory. Is this something that will help me reconstruct the make flags I used when I compiled 2.10 or just a useful feature for the future? Look for the EXPORT line. This has AUXLIBS and CCARGS, which you would use as $ make makefiles CCARGS='stuff' AUXLIBS='stuff' For example, this Postfix 2.10 makedefs.out file contains (lines broken for readability): EXPORT = \ AUXLIBS='-lssl -lcrypto -L/usr/local/lib -lsasl2 -L/usr/local/lib -lcdb -L/usr/local/lib -R/usr/local/lib -lldap -L/usr/local/lib -R/usr/local/lib -llber -L/usr/local/lib -llmdb -L/usr/local/lib -lpq -L/usr/local/lib -lsqlite3 -L/usr/local/lib -Wl,-R/usr/local/lib -lpcre' \ CCARGS='-I. -I../../include -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/local/include/sasl -DHAS_CDB -I/usr/local/include -DHAS_SQLITE -DHAS_LMDB -DHAS_LDAP -DHAS_PGSQL -I/usr/local/include/pgsql -DHAS_MYSQL -I/usr/local/include/mysql -DHAS_PCRE -I/usr/local/include' \ OPT='' \ DEBUG='-g' The pcre-related parts were generated when make makefiles ran, but there is no need to remove them before using CCARGS and AUXLIBS in $ make makefiles CCARGS='stuff' AUXLIBS='stuff' OPT=xx DEBUG=yy. The OPT='' and DEBUG='-g' are typical of a development environment. Your needs may differ. Wietse
Re: many domains fail dkim sig check
Am 12.10.2014 um 12:19 schrieb shm...@riseup.net: i wrote to the relevant dkim/dmarc lists but still i find the following errors from opendkim/opendmarc consistently with every message could somebody please suggest which settings, if there are any within postfix, that may alleviate these failures ? overall, on the other hand, i see many successful verifications as well but id like to know why some still fail surely it can't be that all gmail.com and google.com messages are modified in transit, somehow ie. opendkim[3561]: : mail-wi0-f202.google.com [209.85.212.202] not internal opendkim[3561]: : not authenticated opendkim[3561]: : signature=lnkRpgLM domain=google.com selector=20120113 result=signature verification failed opendkim[3561]: : s=20120113 d=google.com SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[3561]: : bad signature data opendmarc[3526]: : google.com fail opendkim[4560]: : n13-vm7.bullet.mail.ne1.yahoo.com [98.138.121.231] not internal opendkim[4560]: : not authenticated opendkim[4560]: : signature=B+PrvMlb domain=yahoo.com selector=s2048 result=signature verification failed opendkim[4560]: : s=s2048 d=yahoo.com SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[4560]: : bad signature data opendmarc[26995]: : dmarc.yahoo.com none opendkim[8288]: : snip1.dnsops.gov [129.6.100.200] not internal opendkim[8288]: : not authenticated opendkim[8288]: : signature=PrBejfsW domain=had-pilot.biz selector=mailkey result=signature verification failed opendkim[8288]: : s=mailkey d=had-pilot.biz SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature opendkim[8288]: : bad signature data opendmarc[26995]: : had-pilot.biz none the operator of had-pilot believes and is is confident their dkim sigs are correct double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way ( which might brake dkim ) Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: many domains fail dkim sig check
Am 12.10.2014 um 15:12 schrieb Robert Schetterer: the operator of had-pilot believes and is is confident their dkim sigs are correct double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way (which might brake dkim) DKIM seems to have a problem on many sites currently Spamassassin even degraded the rule to testing looks like this time you can say give some positive score if it is valid, but don't trust a invaid result what is exactly SA does cat maillog | grep T_DKIM_INVALID | wc -l 1162 my guess is that people signing messages using way too much fragile parts of messages for it
Re: many domains fail dkim sig check
Robert Schetterer: double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way ( which might brake dkim ) I agree that changing a message breaks its DKIM signature, but I why this is tricky with Postfix. If you are referring to the the header position counter, what does that have to do with DKIM signatures? Wietse
Re: many domains fail dkim sig check
Robert Schetterer wrote: double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way ( which might brake dkim ) Best Regards MfG Robert Schetterer could you please provide some examples from your experience ?
postfix-2.12 BC-warnings: confusing linenumbers
Hello Wietse, I just installed 2.12-20140911 and got multiple BC warnings. The linenumbers are confusing... $ head -n 3 /etc/postfix/master.cf relay unix - - - - - smtp -o smtp_fallback_relay= # line with comment flush unix n - y 1000? 0 flush on reload I get warnings about line 3 and 4 in this example. Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 3: using backwards-compatible default setting chroot=y Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 4: using backwards-compatible default setting chroot=y Most users would expect a warning about line 1 and 4 because line 3 is obviously a comment ( same happen if line 3 is empty ) Andreas
Re: postfix-2.12 BC-warnings: confusing linenumbers
Am 12.10.2014 um 20:43 schrieb A. Schulze: I just installed 2.12-20140911 and got multiple BC warnings. The linenumbers are confusing... $ head -n 3 /etc/postfix/master.cf relay unix - - - - - smtp -o smtp_fallback_relay= # line with comment flush unix n - y 1000? 0 flush on reload I get warnings about line 3 and 4 in this example. Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 3: using backwards-compatible default setting chroot=y Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 4: using backwards-compatible default setting chroot=y Most users would expect a warning about line 1 and 4 because line 3 is obviously a comment ( same happen if line 3 is empty ) how many comment or empty lines are before? it's not uncommon to skip them just because they are never read
postconf question
Hi all, while reading the COMPATIBILITY_README I asked me wasn't the command to edit the main.cf 'postconf -e mumble=foo' ? is '-e' a default action to edit main.cf? did I missed an update? postconf mumble display the value postconf mumble=foo set the variable and is exactly the same as postconf -e mumble=foo is that right? Thanks Andreas
Re: postfix-2.12 BC-warnings: confusing linenumbers
A. Schulze: Hello Wietse, I just installed 2.12-20140911 and got multiple BC warnings. The linenumbers are confusing... $ head -n 3 /etc/postfix/master.cf relay unix - - - - - smtp -o smtp_fallback_relay= # line with comment flush unix n - y 1000? 0 flush on reload I get warnings about line 3 and 4 in this example. Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 3: using backwards-compatible default setting chroot=y Oct 12 20:28:45 mail postfix/master[3612]: /etc/postfix/master.cf: line 4: using backwards-compatible default setting chroot=y Most users would expect a warning about line 1 and 4 because line 3 is obviously a comment ( same happen if line 3 is empty ) How would Postfix know that relay ends at line 2? Comments may appear IN THE MIDDLE of a master.cf entry. Wietse
Re: postfix-2.12 BC-warnings: confusing linenumbers
On Sun, Oct 12, 2014 at 03:09:30PM -0400, Wietse Venema wrote: I just installed 2.12-20140911 and got multiple BC warnings. The linenumbers are confusing... Most users would expect a warning about line 1 and 4 because line 3 is obviously a comment ( same happen if line 3 is empty ) How would Postfix know that relay ends at line 2? Comments may appear IN THE MIDDLE of a master.cf entry. It knows where the entry started, aka where the first non-commented line was. Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown
Re: postfix-2.12 BC-warnings: confusing linenumbers
wietse: $ head -n 3 /etc/postfix/master.cf relay unix - - - - - smtp -o smtp_fallback_relay= # line with comment flush unix n - y 1000? 0 flush How would Postfix know that relay ends at line 2? Comments may appear IN THE MIDDLE of a master.cf entry. technical correct. I read line 3 but should read the entry starting somewhere and end in line 3 I expect higher support volume. Many people will ask again and again I get warnings about empty or comment lines That's what I like to say. Andreas
Re: postfix-2.12 BC-warnings: confusing linenumbers
On Sun, Oct 12, 2014 at 09:20:41PM +0200, A. Schulze wrote:
How would Postfix know that relay ends at line 2? Comments may
appear IN THE MIDDLE of a master.cf entry.
Technically correct.
I read line 3 but should read the entry starting somewhere and end in
line 3
It is perhaps sufficient to report the line number of the entry
start. Try the patch below:
diff --git a/src/master/master_ent.c b/src/master/master_ent.c
index 3235996..55ffaf6 100644
--- a/src/master/master_ent.c
+++ b/src/master/master_ent.c
@@ -105,7 +105,8 @@
static char *master_path; /* config file name */
static VSTREAM *master_fp; /* config file pointer */
-static int master_line;/* config file line number */
+static int master_line;/* entry start line number */
+static int master_line_last; /* last read line number */
static ARGV *master_disable; /* disabled service patterns */
static char master_blanks[] = \t\r\n;/* field delimiters */
@@ -135,7 +136,7 @@ voidset_master_ent()
msg_panic(%s: no configuration file specified, myname);
if ((master_fp = vstream_fopen(master_path, O_RDONLY, 0)) == 0)
msg_fatal(open %s: %m, master_path);
-master_line = 0;
+master_line = master_line_last = 0;
if (master_disable != 0)
msg_panic(%s: service disable list still exists, myname);
if (inet_proto_info()-ai_family_list[0] == 0) {
@@ -288,7 +289,8 @@ MASTER_SERV *get_master_ent()
* Skip blank lines and comment lines.
*/
for (;;) {
- if (readlline(buf, master_fp, master_line) == 0) {
+ master_line = master_line_last + 1;
+ if (readlline(buf, master_fp, master_line_last) == 0) {
vstring_free(buf);
vstring_free(junk);
return (0);
--
Viktor.
Re: many domains fail dkim sig check
Am 12.10.2014 um 15:23 schrieb Wietse Venema: Robert Schetterer: double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way ( which might brake dkim ) I agree that changing a message breaks its DKIM signature, but I why this is tricky with Postfix. not dkim, dmarc ! http://mail-archives.engardelinux.org/modules/index/list_archives.cgi?list=postfix-userspage=0457.htmlmonth=2014-04 For bizarre Sendmail compatibility reasons, Milters don't see the first header in the message. Changing that would cost me at least a day to ensure that it breaks nothing with add header, delete header, etc. requests. http://www.trusteddomain.org/pipermail/opendmarc-users/2014-September/000404.html ... I solved it like this: As a first action I always add a pseudo headerline in smtpd_data_restrictions. So the headerline for SPF will became the second one and postfix passes it to the milters. Config in main.cf is: ... smtpd_data_restrictions = check_sender_access regexp:/etc/postfix/add_header_to_all.regexp, check_policy_service unix:private/policyd-spf ... The file /etc/postfix/add_header_to_all.regexp contains only the following line: ... /.\@./ PREPEND X-MY: Auth-Res ... Milters came with smtp_milter = DKIM-MILTER,DMAR-MILTER,etc. a few more links can be found here https://sys4.de/de/blog/2014/09/20/fallstricke-mit-opendmarc-und-postfix/ so there are a lot of stuff which can be misconfigured, or bug related problems with the dmarc milter itself ... If you are referring to the the header position counter, what does that have to do with DKIM signatures? Wietse Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: many domains fail dkim sig check
On Sun, Oct 12, 2014 at 09:46:15PM +0200, Robert Schetterer wrote: For bizarre Sendmail compatibility reasons, Milters don't see the first header in the message. Changing that would cost me at least a day to ensure that it breaks nothing with add header, delete header, etc. requests. Milters are supposed to see the original message content exactly as received over the wire. For consistency, Postfix could at some point be enhanced to ensure this is the case regardless of the number of header lines prepended via access checks. The current behaviour that assumes a single prepended Received header is arguably incorrect. That said, I think you should not mix content inspection models. When using milters, don't prepend headers via Postfix access rules. Do that in a milter. Presumably milter chaining allows a second milter to see headers added by a previous milter. And of course there are now milter multiplexors that look like a single milter to Postfix. Perhaps backwards compatibility considerations preclude fixing the current header offset logic, but I think it is unwise to rely on creative work-arounds. -- Viktor.
Re: many domains fail dkim sig check
Robert Schetterer: [ Charset windows-1252 converted... ] Am 12.10.2014 um 15:23 schrieb Wietse Venema: Robert Schetterer: double check your dmarc milter setup, it s very tricky with postfix, make sure mail is not altered on its way ( which might brake dkim ) I agree that changing a message breaks its DKIM signature, but I why this is tricky with Postfix. not dkim, dmarc ! http://mail-archives.engardelinux.org/modules/index/list_archives.cgi?list=postfix-userspage=0457.htmlmonth=2014-04 Do you want to have the PREPEND headers AFTER the Received: header? Wietse *** ./smtpd.c- 2014-10-08 17:46:49.0 -0400 --- ./smtpd.c 2014-10-12 15:54:23.0 -0400 *** *** 3115,3127 } /* - * PREPEND message headers. - */ - if (state-prepend) - for (cpp = state-prepend-argv; *cpp; cpp++) - out_fprintf(out_stream, REC_TYPE_NORM, %s, *cpp); - - /* * Suppress our own Received: header in the unlikely case that we are an * intermediate proxy. */ --- 3115,3120 *** *** 3210,3215 --- 3203,3216 \t(envelope-from %s), STR(state-buffer)); #endif } + + /* + * PREPEND message headers. + */ + if (state-prepend) + for (cpp = state-prepend-argv; *cpp; cpp++) + out_fprintf(out_stream, REC_TYPE_NORM, %s, *cpp); + smtpd_chat_reply(state, 354 End data with CRLF.CRLF); state-where = SMTPD_AFTER_DATA;
Re: many domains fail dkim sig check
On Sun, Oct 12, 2014 at 03:55:21PM -0400, Wietse Venema wrote: Do you want to have the PREPEND headers AFTER the Received: header? It is certainly more consistent with any downstream milter processing. Otherwise we'd have to count the number of prepended headers, communicate it to cleanup(8) and hide them all from milters in addition to hiding the top-most Received header. -- Viktor.
Re: many domains fail dkim sig check
On Sun, Oct 12, 2014 at 07:58:23PM +, Viktor Dukhovni wrote: On Sun, Oct 12, 2014 at 03:55:21PM -0400, Wietse Venema wrote: Do you want to have the PREPEND headers AFTER the Received: header? It is certainly more consistent with any downstream milter processing. Otherwise we'd have to count the number of prepended headers, communicate it to cleanup(8) and hide them all from milters in addition to hiding the top-most Received header. The downside is that one can no longer reliably tell who added a given header. Placing local modifications above Received makes it easier to understand the message history. -- Viktor.
Re: many domains fail dkim sig check
Viktor Dukhovni: On Sun, Oct 12, 2014 at 03:55:21PM -0400, Wietse Venema wrote: Do you want to have the PREPEND headers AFTER the Received: header? It is certainly more consistent with any downstream milter processing. Otherwise we'd have to count the number of prepended headers, communicate it to cleanup(8) and hide them all from milters in addition to hiding the top-most Received header. Looks like compatibility_level=3 (together with not suppressing the Received: header before an smtpd_proxy_filter). Wietse
Re: postfix-2.12 BC-warnings: confusing linenumbers
Viktor Dukhovni: Try the patch below: works with one exception. my master.cf start with comment lines 1: # 2: # documentation 3: relay unix - - - - - smtp 4: -o smtp_fallback_relay= 5: 6: flush unix n - - 1000? 0 flush 7: # foo 8: trace unix - - - - 0 bounce Your patch produce warnings about lines 1, 6 and 8 Andreas
Re: many domains fail dkim sig check
Am 12.10.2014 um 22:01 schrieb Wietse Venema: Viktor Dukhovni: On Sun, Oct 12, 2014 at 03:55:21PM -0400, Wietse Venema wrote: Do you want to have the PREPEND headers AFTER the Received: header? It is certainly more consistent with any downstream milter processing. Otherwise we'd have to count the number of prepended headers, communicate it to cleanup(8) and hide them all from milters in addition to hiding the top-most Received header. Looks like compatibility_level=3 (together with not suppressing the Received: header before an smtpd_proxy_filter) sorry if i did not get the context completly, that's why i ask reading that milters don't see the first header multiple times on the list let me repeatly think about spamass-milter and RBL's which are based on the received headers to determine the incoming IP as far as i can see the results are clean in context what implications would such a change have here and das somebody know if spamass-milter works around the current behavior in some way?
Re: many domains fail dkim sig check
Viktor Dukhovni: On Sun, Oct 12, 2014 at 07:58:23PM +, Viktor Dukhovni wrote: On Sun, Oct 12, 2014 at 03:55:21PM -0400, Wietse Venema wrote: Do you want to have the PREPEND headers AFTER the Received: header? It is certainly more consistent with any downstream milter processing. Otherwise we'd have to count the number of prepended headers, communicate it to cleanup(8) and hide them all from milters in addition to hiding the top-most Received header. The downside is that one can no longer reliably tell who added a given header. Placing local modifications above Received makes it easier to understand the message history. You mean: Received: by MTA-NAME Other headers added by the MTA named above. Versus: Other headers added by the MTA named below. Received: by MTA-NAME Postfix already appends From/Date/Message-ID under its own Received: header. Placing Postfix's PREPEND headers under its own Received: header is not inconsistent with that. Wietse
Re: postfix-2.12 BC-warnings: confusing linenumbers
A. Schulze: Viktor Dukhovni: Try the patch below: works with one exception. my master.cf start with comment lines 1: # 2: # documentation 3: relay unix - - - - - smtp 4: -o smtp_fallback_relay= 5: 6: flush unix n - - 1000? 0 flush 7: # foo 8: trace unix - - - - 0 bounce Your patch produce warnings about lines 1, 6 and 8 That's why I am implementint line RANGES to shut up people like you. Wietse
Re: postfix-2.12 BC-warnings: confusing linenumbers
wietse: That's why I am implementint line RANGES to shut up people like you. honestly, I only try to help ...
Re: many domains fail dkim sig check
You mean: Received: by MTA-NAME Other headers added by the MTA named above. Versus: Other headers added by the MTA named below. Received: by MTA-NAME Yes. Postfix already appends From/Date/Message-ID under its own Received: header. Placing Postfix's PREPEND headers under its own Received: header is not inconsistent with that. Yes, but those are single-instance headers that pertain to the message as a whole, unlike trace information that pertains to a particular hop. Things like X-Envelope-From and various other prepends are typically hop-specific information, can be prepended multiple times, and their origin becomes ambiguous when placed below Received by some MTAs and above by others. The milter compatibility logic is a shame, it would have been far better had milters always expected a local Received header and optionally ignored everything starting with the top-most Received header up, if/when verbatim remote content is desired. As it is, we're workoing around a milter interface design error. -- Viktor.
Re: many domains fail dkim sig check
Viktor Dukhovni: You mean: Received: by MTA-NAME Other headers added by the MTA named above. Versus: Other headers added by the MTA named below. Received: by MTA-NAME Yes. Postfix already appends From/Date/Message-ID under its own Received: header. Placing Postfix's PREPEND headers under its own Received: header is not inconsistent with that. Yes, but those are single-instance headers that pertain to the message as a whole, unlike trace information that pertains to a particular hop. Things like X-Envelope-From and various other prepends are typically hop-specific information, can be prepended multiple times, and their origin becomes ambiguous when placed below Received by some MTAs and above by others. Pointer to RFC or best-practice document, please? Some comments for historical accuracy: - The access map PREPEND feature was implemented without much consideration. I added Milter support years later, and obviously did not consider the possibility that Postfix might already have prepended lines above its own Received: header. I was only reminded of that recently. Otherwise I would have changed PREPEND years ago. - The header_checks prepend action will prepend content in the middle of the message header. That should be OK as long as it does not add headers with names that appear in the DKIM signature. As for the claim that Milters are supposed to see the on-the-wire message, do you have a pointer to support that? Wietse
Re: many domains fail dkim sig check
On Sun, Oct 12, 2014 at 06:07:32PM -0400, Wietse Venema wrote: Yes, but those are single-instance headers that pertain to the message as a whole, unlike trace information that pertains to a particular hop. Things like X-Envelope-From and various other prepends are typically hop-specific information, can be prepended multiple times, and their origin becomes ambiguous when placed below Received by some MTAs and above by others. Pointer to RFC or best-practice document, please? I am not aware of any formal standards covering this. This is my interpretation of current practice. As for the claim that Milters are supposed to see the on-the-wire message, do you have a pointer to support that? I am hoping Claus Assmann might comment on this, I believe he is subscribed to the list. As for me, that is my interpretation of why Sendmail avoids passing the local Received header to milters. -- Viktor.
Re: postfix-2.12 BC-warnings: confusing linenumbers
wietse: That's why I am implementint line RANGES to shut up people like you. A. Schulze: honestly, I only try to help ... I know. In the end Postfix will be better. Wietse
Re: many domains fail dkim sig check
On Sun, Oct 12, 2014, Wietse Venema wrote: As for the claim that Milters are supposed to see the on-the-wire message, do you have a pointer to support that? sendmail: libmilter/docs/smfi_insheader.html * A filter will receive only headers that have been sent by the SMTP client and those header modifications by earlier filters. It will not receive the headers that are inserted by sendmail itself.
Re: many domains fail dkim sig check
Claus Assmann: On Sun, Oct 12, 2014, Wietse Venema wrote: As for the claim that Milters are supposed to see the on-the-wire message, do you have a pointer to support that? sendmail: libmilter/docs/smfi_insheader.html * A filter will receive only headers that have been sent by the SMTP client and those header modifications by earlier filters. It will not receive the headers that are inserted by sendmail itself. Thanks, Claus. That clarifies things. Based on this I conclude that Postfix's own Received: header must not be exposed via the Milter API. Making Postfix's Received: header visible after some Postfix access/policy header PREPEND request would be a bug. In the case of Postfix access/policy header PREPEND requests, I will treat the resulting headers as if they were added by a filter, and expose all of them (not all minus one) via the Milter API. I'll back-port this to the existing stable releases. Wietse
