Re: discard mime to and cc recipients
Thank you Wietse this was what i didnt` knew. B?ny?sz Botond: I would like to ask? if it`s possible to configure postfix to not send mails to mime to and cc recipients Postfix does not send to the To:/Cc: recipients by default. It will do so only when you execute sendmail -t. Wietse
A major fuckup on part of spamhaus:
http://www.spamhaus.org/sbl/query/SBL138067 The evidence section lists inetnum: 95.218.0.0 - 95.219.255.255, yet spamhaus listed 93.218.0.0/15 (93 instead of 95)! 93.218.0.0/15 includes large parts of german Deutsche Telekom dialups :| -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: A major fuckup on part of spamhaus:
WTF ! Am 04.05.2012 13:12, schrieb Ralf Hildebrandt: http://www.spamhaus.org/sbl/query/SBL138067 The evidence section lists inetnum: 95.218.0.0 - 95.219.255.255, yet spamhaus listed 93.218.0.0/15 (93 instead of 95)! 93.218.0.0/15 includes large parts of german Deutsche Telekom dialups :|
Re: A major fuckup on part of spamhaus:
1) Should not happen but it did. No one is perfect. 2) I hope you guys don't just blindly trust one RBL provider? Postscreen allows perfectly to craft weighted BL. 3) Instead of shouting out here has any one reported them their mistake? Original-Nachricht Datum: Fri, 04 May 2012 14:13:59 +0200 Von: Marko Weber we...@zackbummfertig.de An: postfix-users@postfix.org Betreff: Re: A major fuckup on part of spamhaus: WTF ! Am 04.05.2012 13:12, schrieb Ralf Hildebrandt: http://www.spamhaus.org/sbl/query/SBL138067 The evidence section lists inetnum: 95.218.0.0 - 95.219.255.255, yet spamhaus listed 93.218.0.0/15 (93 instead of 95)! 93.218.0.0/15 includes large parts of german Deutsche Telekom dialups :| -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: A major fuckup on part of spamhaus:
* Steve stev...@gmx.net: 1) Should not happen but it did. No one is perfect. 2) I hope you guys don't just blindly trust one RBL provider? Postscreen allows perfectly to craft weighted BL. 3) Instead of shouting out here has any one reported them their mistake? It has been fixed. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: A major fuckup on part of spamhaus:
On 2012-05-04 Steve wrote: 1) Should not happen but it did. No one is perfect. 2) I hope you guys don't just blindly trust one RBL provider? Postscreen allows perfectly to craft weighted BL. policyd-weight does weighted checks, too. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: A major fuckup on part of spamhaus:
Original-Nachricht Datum: Fri, 4 May 2012 14:34:45 +0200 Von: Ralf Hildebrandt ralf.hildebra...@charite.de An: postfix-users@postfix.org Betreff: Re: A major fuckup on part of spamhaus: * Steve stev...@gmx.net: 1) Should not happen but it did. No one is perfect. 2) I hope you guys don't just blindly trust one RBL provider? Postscreen allows perfectly to craft weighted BL. 3) Instead of shouting out here has any one reported them their mistake? It has been fixed. Sturm im Wasserglas? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: A major fuckup on part of spamhaus:
Original-Nachricht Datum: Fri, 4 May 2012 14:36:44 +0200 Von: Ansgar Wiechers li...@planetcobalt.net An: postfix-users@postfix.org Betreff: Re: A major fuckup on part of spamhaus: On 2012-05-04 Steve wrote: 1) Should not happen but it did. No one is perfect. 2) I hope you guys don't just blindly trust one RBL provider? Postscreen allows perfectly to craft weighted BL. policyd-weight does weighted checks, too. I know. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Multiple IP
On 05/03/2012 07:45 AM, Kirill Bychkov wrote: Hi all, I need create server with 5 IP addresses (interfaces) and postfix(es). The role of this server is relay. If message delivered into my mail server on one ip address, for example, 172.16.35.35, so this message should be sent from same ip: 172.16.35.35. In other words, on which interface the message came, with this should be sent. What method should I do? 1. Postfix multi instace (postmulti) 2. Postfix manual multi instance (http://advosys.ca/papers/email/58-postfix-instance.html) 3. Configure master.cf http://master.cf and main.cf http://main.cf of one postfix instance. Thank you. Hi, This may or may not be what you are looking for. If you have a dedicated machine with lots of IP addresses then I would do LXC[1] (Linux Containers) on it. This way you can have completely different rules on each postfix. Your containers will act as if they were different physical machines. HTH, Mikael [1] http://lxc.sourceforge.net/
Re: Stress docs update
On 05/03/12 05:14, Rob Sterenborg wrote: h2a name=credits Credits /a/h2 According to the POSTSCREEN_README, postscreen doesn't do greylisting at all: postscreen and greylisting are different things. The below is your patch adapted with a partial copy-paste from the POSTSCREEN_README. When a client passes the deep protocol tests, postscreen sends it a 4xx; that's essentially greylisting. But, there's no need to mention that on STRESS_README: it can be inferred from POSTSCREEN_README.
Postscreen DNSBL weights
Hi all, Was wondering if anyone would be willing to share what DNSBL and weights they are using with Postscreen. Thanks, Rod
still being delivered
Hello I noticed 534 messages like the following on our MX server's log, since this morning ... I need some clarifications please. postfix version is 2.10-20120423 May 4 18:00:14 hp9 postfix/qmgr[13147]: BA27314E95DE: skipped, still being delivered Thank you
Re: still being delivered
Am 04.05.2012 18:07, schrieb Frank Bonnet: Hello I noticed 534 messages like the following on our MX server's log, since this morning ... I need some clarifications please. postfix version is 2.10-20120423 May 4 18:00:14 hp9 postfix/qmgr[13147]: BA27314E95DE: skipped, still being delivered sounds like a restart after prcoeed of the messages has already started - the only case where i seen the message skipped, still being delivered in my logs signature.asc Description: OpenPGP digital signature
Re: still being delivered
On 05/04/2012 06:10 PM, Reindl Harald wrote: Am 04.05.2012 18:07, schrieb Frank Bonnet: Hello I noticed 534 messages like the following on our MX server's log, since this morning ... I need some clarifications please. postfix version is 2.10-20120423 May 4 18:00:14 hp9 postfix/qmgr[13147]: BA27314E95DE: skipped, still being delivered sounds like a restart after prcoeed of the messages has already started - the only case where i seen the message skipped, still being delivered in my logs hello well ... it happened 534 times today ... from 00:00 till 18:00 I reload postfix one time today after updating one map
separate log for amavisd-new
Hello, Instead of including the amavisd activity in the maillog, I want to have a separate log file. I can't figure out how to get this working though. For some reason, amavisd isn't writing to the log file that's defined in /etc/amavisd.conf If I do a directory listing, the log still shows as 0 bytes: ls -l amavis.log -rwxrwxrwx 1 vscan vscan 0 Nov 30 09:39 amavis.log when I initially set up the postfix/mysql/amavisd system, I created an empty amavis.log and changed the owner to the user amavis is running under: chown vscan:vscan /var/log/amavis.log chmod u=rw,g=rw,o=rw /var/log/amavis.log Any idea what could be wrong? Below are the relevant entries from amavisd.conf: $log_level = 2; # verbosity 0..5, -d $log_recip_templ = undef; # disable by-recipient level-0 log entries $DO_SYSLOG = 0; # log via syslogd (preferred) $LOGFILE = /var/log/amavis.log; $log_templ = '[? %#V |[? %#F |[?%#D|Not-Delivered|Passed]|BANNED name/type (%F)]|INFECTED (%V)], %o - [%R|,][? %i ||, quarantine %i], Message-ID: %m, Hits: %c'; #$syslog_facility = 'local7'; # Syslog facility as a string # e.g.: mail, daemon, user, local0, ... local7 #$syslog_priority = 'debug'; # Syslog base (minimal) priority as a string, # choose from: emerg, alert, crit, err, warning, notice, info, debug Thank you Scott Brown
Re: separate log for amavisd-new
I am not sure that this is the right place to ask about NON-postfix problems. But, have you checked the log file permissions. JohnA On 04/05/2012 12:45 PM, Scott Brown wrote: Hello, Instead of including the amavisd activity in the maillog, I want to have a separate log file. I can't figure out how to get this working though. For some reason, amavisd isn't writing to the log file that's defined in /etc/amavisd.conf If I do a directory listing, the log still shows as 0 bytes: ls -l amavis.log -rwxrwxrwx 1 vscan vscan 0 Nov 30 09:39 amavis.log when I initially set up the postfix/mysql/amavisd system, I created an empty amavis.log and changed the owner to the user amavis is running under: chown vscan:vscan /var/log/amavis.log chmod u=rw,g=rw,o=rw /var/log/amavis.log Any idea what could be wrong? Below are the relevant entries from amavisd.conf: $log_level = 2; # verbosity 0..5, -d $log_recip_templ = undef;# disable by-recipient level-0 log entries $DO_SYSLOG = 0; # log via syslogd (preferred) $LOGFILE = /var/log/amavis.log; $log_templ = '[? %#V |[? %#F |[?%#D|Not-Delivered|Passed]|BANNED name/type (%F)]|INFECTED (%V)], %o - [%R|,][? %i ||, quarantine %i], Message-ID: %m, Hits: %c'; #$syslog_facility = 'local7'; # Syslog facility as a string # e.g.: mail, daemon, user, local0, ... local7 #$syslog_priority = 'debug'; # Syslog base (minimal) priority as a string, # choose from: emerg, alert, crit, err, warning, notice, info, debug Thank you Scott Brown
Re: still being delivered
Frank Bonnet: On 05/04/2012 06:10 PM, Reindl Harald wrote: Am 04.05.2012 18:07, schrieb Frank Bonnet: Hello I noticed 534 messages like the following on our MX server's log, since this morning ... I need some clarifications please. postfix version is 2.10-20120423 May 4 18:00:14 hp9 postfix/qmgr[13147]: BA27314E95DE: skipped, still being delivered sounds like a restart after prcoeed of the messages has already started - the only case where i seen the message skipped, still being delivered in my logs hello well ... it happened 534 times today ... from 00:00 till 18:00 I reload postfix one time today after updating one map What other maps did you update? I have tried to remove all lookup table dependencies from qmgr, because qmgr will restart after map update, and that is bad for performance. Wietse
Re: separate log for amavisd-new
On 2012-05-04 18:45, Scott Brown wrote: Hello, Instead of including the amavisd activity in the maillog, I want to have a separate log file. I can't figure out how to get this working though. For some reason, amavisd isn't writing to the log file that's defined in /etc/amavisd.conf If I do a directory listing, the log still shows as 0 bytes: ls -l amavis.log -rwxrwxrwx 1 vscan vscan 0 Nov 30 09:39 amavis.log when I initially set up the postfix/mysql/amavisd system, I created an empty amavis.log and changed the owner to the user amavis is running under: chown vscan:vscan /var/log/amavis.log chmod u=rw,g=rw,o=rw /var/log/amavis.log Any idea what could be wrong? Below are the relevant entries from amavisd.conf: $log_level = 2; # verbosity 0..5, -d $log_recip_templ = undef;# disable by-recipient level-0 log entries $DO_SYSLOG = 0; # log via syslogd (preferred) $LOGFILE = /var/log/amavis.log; $log_templ = '[? %#V |[? %#F |[?%#D|Not-Delivered|Passed]|BANNED name/type (%F)]|INFECTED (%V)],%o - [%R|,][? %i ||, quarantine %i], Message-ID: %m, Hits: %c'; #$syslog_facility = 'local7'; # Syslog facility as a string # e.g.: mail, daemon, user, local0, ... local7 #$syslog_priority = 'debug'; # Syslog base (minimal) priority as a string, # choose from: emerg, alert, crit, err, warning, notice, info, debug Thank you Scott Brown Wrong list, Postfix doesn't have anything to do with Amavisd.
Re: discard mime to and cc recipients
On May 3, 2012, at 11:23 PM, Bányász Botond wrote: Thank you Wietse this was what i didnt` knew. A custom Policy Daemon might be able to achieve what you seek by inspecting the message's 822 headers, and then rendering a verdict on it. B?ny?sz Botond: I would like to ask? if it`s possible to configure postfix to not send mails to mime to and cc recipients Postfix does not send to the To:/Cc: recipients by default. It will do so only when you execute sendmail -t. Wietse Aloha, Michael. -- Please have your Internet License and Usenet Registration handy...
Timeout when talking to slow remote SMTP server
I'm having issues sending email to a public list because connecting to the MX for the list takes too long. From the postfix log: May 3 09:50:32 edge01-zcs postfix/qmgr[13714]: 54A1D1BD: from=qua...@zimbra.com, size=1764, nrcpt=1 (queue active) May 3 09:50:53 edge01-zcs postfix/smtp[14285]: connect to megawatt.resistor.net[208.69.177.116]:25: Connection timed out May 3 09:50:53 edge01-zcs postfix/smtp[14285]: 54A1D1BD: to=opendkim-us...@lists.opendkim.org, relay=none, delay=4106, delays=4085/0.08/21/0, dsn=4.4.1, status=deferred (connect to megawatt.resistor.net[208.69.177.116]:25: Connection timed out) I checked the MX server via http://www.mxtoolbox.com/SuperTool.aspx and found it sees a significant response delay: smtp:megawatt.resistor.net 220 mx.elandsys.com ESMTP Sendmail 8.14.5/8.14.5; Thu, 3 May 2012 09:45:12 -0700 (PDT) 11.981 seconds - Not good! on Transaction Time From the above logs, you can see postfix timed out within 21 seconds of me flushing the queue. However, I have smtp_connect_timeout set to 60 seconds: [zimbra@edge01-zcs ~]$ postconf smtp_connect_timeout smtp_connect_timeout = 60s Am I setting the wrong parameter? Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: Running on idle systems
On 5/3/2012 6:54 PM, Bill Cole wrote: ... For many of these systems, the OS resides on a mirrored pair of local disks which see very infrequent writes because every filesystem with significant flux is physically resident across the SAN. Spinning disks draw power. Anything drawing power generates heat. Heat requires cooling. Cooling typically requires more power than the devices it is compensating for. Cooling also requires careful attention to the details of physical server density and rack design and so on... This could be completely resolved by PXE/bootp and NFS mounted root filesystems, and save you $200-500/node in disk drive costs after spending $1000-2000 for the NFS server hardware, or nothing using a VM server. It would also save you substantial admin time by using templates for new node deployments. This diskless node methodology has been around for ~30 years. A local mail submission and trivial outbound transport subsystem is a normal feature of any Unix-like machine. To operate robustly, it needs a queueing and retry mechanism. It is helpful for environments with power and cooling concerns if a mechanical disk (or worse: a mirrored pair of disks) isn't forced to spin up every time that mechanism activates. Every little wattage savings is useful, and avoiding truly pointless disk writes is never a bad thing. SSD is a perfect solution here, in cases of non netboot machines. And right now small SSDs are less expensive than their rusty disk counterparts. If one is truly concerned about spurious spin ups eating power and generating heat, I would think one would not go after the software stack in a piecemeal fashion to solve the problem. The MTA isn't the only software waking the disk. The kernel will write logs far more often in many/most situations. Well, beyond the data center environment there is also a very widespread deployment of Postfix as the legacy mail subsystem on MacOS personal machines, where the mail flow is typically extremely low. ... Ultimately the result is having to choose between power management and timely delivery. If the periodic wakeups didn't force a disk write, it would be less onerous to let master run in its normal persistent mode for a lot of Postfix users (many of whom may not even be aware that they are Postfix users.) This is only true if two things persist into the future: 1. Postfix isn't modified in order to perform a power management role 2. Laptops will forever have spinning rust storage Addressing the first point, should it be the responsibility of application software to directly address power management concerns? Or should this be left to the OS and hardware platform/BIOS? Addressing the 2nd, within a few years all new laptops will ship with SSD instead of SRD specifically to address battery run time issues. Many are shipping now with SSDs. All netbooks already do, smart phones use other flash types. Whether it is actually worthwhile to make a change that is only significant for people who are barely using Postfix isn't a judgment I can make. It's obvious that Dr. Venema takes significantly more care with his code than I can really relate to, so I don't really know what effort a conceptually small change in Postfix really entails. Wietse will make his own decisions as he always has. I'm simply making the point that issues such as power/cooling, wake/sleep, etc should be addressed at the hardware platform/OS level, or system or network architecture level, at the application level, especially if the effort to implement it is more than trivial. This is especially true when any such coding effort may only produce very short term gains, as these issues are already being addressed and will be completely resolved by other means (SSD) in the near future, or have already been resolved by 30 year old technology/architecture methods (netboot/NFS), depending on the platform scenario. -- Stan
Re: Timeout when talking to slow remote SMTP server
--On Thursday, May 03, 2012 9:57 AM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: I'm having issues sending email to a public list because connecting to the MX for the list takes too long. From the postfix log: This can be ignored, it was because of a firewall rule blocking the new hardware I am using from delivering outgoing mail, which has now been fixed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
best way to stop all outbound delivery?
I've a Linux machine which is used as a final destination for test emails. Some local inboxes are created, local delivery via Dovecot to IMAP. I want this machine to never send out any email whatsoever. Never relay. Accept inbound messages, deliver locally to IMAP - all that is fine. But no message should ever leave this box, for no reason, even if it's a notification for delivery error. I could block outbound port tcp/25 with iptables, but it seems inelegant. Would this do the trick? default_transport = error:no outbound emails, sorry -- Florin Andrei http://florin.myip.org/
Re: best way to stop all outbound delivery?
Florin Andrei: I've a Linux machine which is used as a final destination for test emails. Some local inboxes are created, local delivery via Dovecot to IMAP. I want this machine to never send out any email whatsoever. Never relay. Accept inbound messages, deliver locally to IMAP - all that is fine. But no message should ever leave this box, for no reason, even if it's a notification for delivery error. Turn off the SMTP client in master.cf. Wietse I could block outbound port tcp/25 with iptables, but it seems inelegant. Would this do the trick? default_transport = error:no outbound emails, sorry -- Florin Andrei http://florin.myip.org/
Re: Running on idle systems
On 4 May 2012, at 17:00, Stan Hoeppner wrote: On 5/3/2012 6:54 PM, Bill Cole wrote: ... For many of these systems, the OS resides on a mirrored pair of local disks which see very infrequent writes because every filesystem with significant flux is physically resident across the SAN. Spinning disks draw power. Anything drawing power generates heat. Heat requires cooling. Cooling typically requires more power than the devices it is compensating for. Cooling also requires careful attention to the details of physical server density and rack design and so on... This could be completely resolved by PXE/bootp and NFS mounted root filesystems, and save you $200-500/node in disk drive costs after spending $1000-2000 for the NFS server hardware, or nothing using a VM server. It would also save you substantial admin time by using templates for new node deployments. This diskless node methodology has been around for ~30 years. Yes, it is possible to fundamentally re-architect working environments that have been organically developed over years by adding significant new infrastructure to save on capital costs of hypothetical growth and maybe on future admin time. The idea that a server in the $1000-$2000 range would be part of a global conversion to diskless servers or even the largest capital cost of such a project reveals that I failed to communicate an accurate understanding of the environment, but that's not terribly important. There's no shortage of well-informed well-developed specific proposals for comprehensive infrastructure overhaul, and in the interim between now and the distant never when one of those meets up with a winning lottery ticket and an unutilized skilled head or three, I have sufficient workarounds in place. I didn't mention that environment seeking a solution, but rather to point out that there are real-world systems that take advantage of the power management capabilities of modern disks and have nothing else in common with the average personal system. I think that was responsive to the paragraph of yours that I originally quoted. It's easy to come up with flippant advice for others to spend time and money to replace stable working systems, but it is also irrelevant and a bit rude. [...] Ultimately the result is having to choose between power management and timely delivery. If the periodic wakeups didn't force a disk write, it would be less onerous to let master run in its normal persistent mode for a lot of Postfix users (many of whom may not even be aware that they are Postfix users.) This is only true if two things persist into the future: 1. Postfix isn't modified in order to perform a power management role No reason for it to perform but it would be nice for it to stop thwarting. 2. Laptops will forever have spinning rust storage Who said anything about laptops? Addressing the first point, should it be the responsibility of application software to directly address power management concerns? Or should this be left to the OS and hardware platform/BIOS? Applications should not do things that are actively hostile to housekeeping functions of lower-level software (in this case: drive firmware) without a functional justification. It's not wrong for a filesystem to change the mtime on a pipe with every write to it, nor is it wrong for a filesystem to commit every change in a timely manner. This is not really fixable at a lower level without eliminating the hardware in question or making changes to filesystem software that could cause wide-ranging problems with other software. Addressing the 2nd, within a few years all new laptops will ship with SSD instead of SRD specifically to address battery run time issues. Many are shipping now with SSDs. All netbooks already do, smart phones use other flash types. This is not about laptops. Really. Systems can live a long time without drive replacements. Spinning rust with power management firmware is not going to be rare in running systems until at least 5 years after dependable fast SSD's hit $1/GB for devices larger than 100GB. Of course, those drives may die out a lot faster where applications do periodic pointless writes that keep them running continuously. Note that the reason this issue exists *AT ALL* is to work around a bug in Solaris 2.4. I spent most of the last 14 years working mostly on Solaris systems in change-averse places and the last time I saw Solaris 2.4 was 1999. I don't have the details of the bug or the free time to rig up a test system to prove it gone in whatever version Postfix needs to work on today, but I have no gripe with that relatively ancient and *likely* inoperative history being the blocking issue. I hope someone else can settle the issue. An argument that time will soon make this fix pointless is a bit ironic. Whether it is actually worthwhile to make a change that is only significant for people who are barely using Postfix
header_checks rule that doesn't work
I've received a mail having: From: =?GB2312?B?tfXBoyy2/rrP0ru19cGjLMj9us/Su7X1waMsy8S6z9K7tfXBoyy3/srOtfXB?= I wanted to reject such mail with /^.=\?GB2312\?B\?/ REJECT GB2312 in headers in header_checks.pcre, but this didn't work. I don't understand because postmap -q - pcre:/etc/postfix/header_checks.pcre the_message says that the rule applies on this line. Any idea? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: header_checks rule that doesn't work
Vincent Lefevre: I've received a mail having: From: =?GB2312?B?tfXBoyy2/rrP0ru19cGjLMj9us/Su7X1waMsy8S6z9K7tfXBoyy3/srOtfXB?= I wanted to reject such mail with /^.=\?GB2312\?B\?/ REJECT GB2312 in headers in header_checks.pcre, but this didn't work. I don't understand because postmap -q - pcre:/etc/postfix/header_checks.pcre the_message says that the rule applies on this line. Try: postmap -h -q This way you enforce that it looks at headers only. Wietse
Re: header_checks rule that doesn't work
On Fri, May 04, 2012 at 10:03:35PM -0400, Wietse Venema wrote: Vincent Lefevre: I've received a mail having: From: =?GB2312?B?tfXBoyy2/rrP0ru19cGjLMj9us/Su7X1waMsy8S6z9K7tfXBoyy3/srOtfXB?= I wanted to reject such mail with /^.=\?GB2312\?B\?/ REJECT GB2312 in headers The OP showed that on two lines, but if it is, there would be leading whitespace. You want to match a whole logical header, not only a continued line. The expression should be: /^From:.=\?GB2312\?B\?/ REJECT GB2312 in headers Or, remove the anchor: /=\?GB2312\?B\?/ REJECT GB2312 in headers in header_checks.pcre, but this didn't work. I don't understand because postmap -q - pcre:/etc/postfix/header_checks.pcre the_message says that the rule applies on this line. Try: postmap -h -q This way you enforce that it looks at headers only. One thing the header_checks(5) manual is not clear about is how to match the line end and leading whitespace. Is it matched by a single space in the expression, or would we have to replace spaces with something like this: [[:blank:]]+ ? -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: still being delivered
Le 04/05/2012 19:42, Wietse Venema a écrit : Frank Bonnet: On 05/04/2012 06:10 PM, Reindl Harald wrote: Am 04.05.2012 18:07, schrieb Frank Bonnet: Hello I noticed 534 messages like the following on our MX server's log, since this morning ... I need some clarifications please. postfix version is 2.10-20120423 May 4 18:00:14 hp9 postfix/qmgr[13147]: BA27314E95DE: skipped, still being delivered sounds like a restart after prcoeed of the messages has already started - the only case where i seen the message skipped, still being delivered in my logs hello well ... it happened 534 times today ... from 00:00 till 18:00 I reload postfix one time today after updating one map What other maps did you update? I have tried to remove all lookup table dependencies from qmgr, because qmgr will restart after map update, and that is bad for performance. Wietse Hello I just added one entry in smtpd_sender_restrictions so I don't think it is related see below the log of one implied transaction ... I need gurus lights ! thank you hp9# grep 0EE1214E9546 /var/log/maillog May 5 01:05:15 hp9 postfix/qmgr[22837]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 01:10:18 hp9 postfix/smtp[22866]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=173296, delays=172993/0/303/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) May 5 02:20:14 hp9 postfix/qmgr[94246]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 02:25:20 hp9 postfix/smtp[94286]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=177799, delays=177492/0.01/306/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) May 5 03:35:15 hp9 postfix/qmgr[66017]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 03:40:18 hp9 postfix/smtp[66070]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=182296, delays=181993/0.03/303/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) May 5 04:50:15 hp9 postfix/qmgr[37586]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 04:55:18 hp9 postfix/smtp[37629]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=186797, delays=186494/0.06/303/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) May 5 06:05:15 hp9 postfix/qmgr[9113]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 06:05:45 hp9 postfix/smtp[9156]: 0EE1214E9546: to=t...@beca.rs, relay=none, delay=191023, delays=190993/0.03/30/0, dsn=4.4.1, status=deferred (connect to mail.beca.rs[178.254.133.163]:25: Operation timed out) May 5 07:15:14 hp9 postfix/qmgr[66250]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 07:15:15 hp9 postfix/qmgr[80516]: 0EE1214E9546: skipped, still being delivered May 5 07:16:28 hp9 postfix/qmgr[80516]: 0EE1214E9546: skipped, still being delivered May 5 07:17:42 hp9 postfix/qmgr[80516]: 0EE1214E9546: skipped, still being delivered May 5 07:18:54 hp9 postfix/qmgr[80516]: 0EE1214E9546: skipped, still being delivered May 5 07:20:00 hp9 postfix/qmgr[80516]: 0EE1214E9546: skipped, still being delivered May 5 07:20:30 hp9 postfix/smtp[80348]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=195509, delays=195193/0.06/316/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) May 5 07:21:01 hp9 postfix/qmgr[80516]: 0EE1214E9546: from=, size=10681, nrcpt=1 (queue active) May 5 07:26:01 hp9 postfix/smtp[80550]: 0EE1214E9546: to=t...@beca.rs, relay=mail.beca.rs[178.254.133.163]:25, delay=195839, delays=195539/0/300/0, dsn=4.4.2, status=deferred (conversation with mail.beca.rs[178.254.133.163] timed out while receiving the initial server greeting) hp9#
