Re: Spawning milter processes

[Ron Garret]

On Jan 31, 2016, at 1:28 AM, Robert Schetterer  wrote:

> Am 31.01.2016 um 09:56 schrieb Ron Garret:
>> Hello,
>> 
>> What is the usual way to start a milter process?  Can postfix be configured 
>> to spawn it automatically, or does the milter have to be set up as a 
>> separate service?  If the former, how do you do it?
>> 
>> Thanks,
>> rg
>> 
> 
> milters are usually seperate services

OK, but is there any way to get Postfix to restart a milter if it goes down?  
By default, if a milter goes down, it takes postfix down with it.

Also, why did you hedge with “usually”?  What other possibilities are there?

rg

Re: Spawning milter processes

[Robert Schetterer]

Am 31.01.2016 um 18:04 schrieb Ron Garret:
> 
> On Jan 31, 2016, at 1:28 AM, Robert Schetterer  wrote:
> 
>> Am 31.01.2016 um 09:56 schrieb Ron Garret:
>>> Hello,
>>>
>>> What is the usual way to start a milter process?  Can postfix be configured 
>>> to spawn it automatically, or does the milter have to be set up as a 
>>> separate service?  If the former, how do you do it?
>>>
>>> Thanks,
>>> rg
>>>
>>
>> milters are usually seperate services
> 
> OK, but is there any way to get Postfix to restart a milter if it goes down?  
> By default, if a milter goes down, it takes postfix down with it.

in real milters have a tendence to stop sometimes, so some of them have
an auto restart feature, for safety use monit to monitor them
in postfix you can config what to do if milter isnt working anymore


http://postfix.cs.utah.edu/postconf.5.html#milter_default_action


> 
> Also, why did you hedge with “usually”?  What other possibilities are there?

to my knowledge none...but that may not ultimate

> 
> rg
> 



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: Spawning milter processes

[Steve Jenkins]

On Sun, Jan 31, 2016 at 9:04 AM, Ron Garret  wrote:

> OK, but is there any way to get Postfix to restart a milter if it goes
> down?  By default, if a milter goes down, it takes postfix down with it.


The usual way to start a milter service is to have it autostart when the
server boots, just as you would with any service. For example, if you're
using systemd, you'd have a miltername.service unit file to fire it up.

I don't know of any way for Postfix itself to then monitor the running
milter service to respawn if it fails, but the two milters I'm most
familiar with -- OpenDKIM and OpenDMARC -- both have "AutoRestart=yes"
configuration options in their conf files to respawn themselves in the
event they fail. I assume they're monitoring their own PID file, or
something to that effect, but I'm not a programmer, so I don't know what's
under-the-hood to enable that. I have Nagios configured to regularly check
that Postfix is up, and separately monitor my important milters.

If you're looking to write your own milter service, I'd join the dev
discussion list for one of the milters that supports AutoRestart (such as
OpenDKIM) and ask about it there. A good number of guys on this Postfix
list are also on that list.

Or you could look through the source code on SourceForge and find the
AutoRestart stuff:

http://sourceforge.net/projects/opendkim/

SteveJ

Re: Spawning milter processes

[Ron Garret]

OK, that’s exactly what I needed to know.  Thanks!

On Jan 31, 2016, at 9:16 AM, Steve Jenkins  wrote:

> On Sun, Jan 31, 2016 at 9:04 AM, Ron Garret  wrote:
> OK, but is there any way to get Postfix to restart a milter if it goes down?  
> By default, if a milter goes down, it takes postfix down with it.
> 
> The usual way to start a milter service is to have it autostart when the 
> server boots, just as you would with any service. For example, if you're 
> using systemd, you'd have a miltername.service unit file to fire it up.
> 
> I don't know of any way for Postfix itself to then monitor the running milter 
> service to respawn if it fails, but the two milters I'm most familiar with -- 
> OpenDKIM and OpenDMARC -- both have "AutoRestart=yes" configuration options 
> in their conf files to respawn themselves in the event they fail. I assume 
> they're monitoring their own PID file, or something to that effect, but I'm 
> not a programmer, so I don't know what's under-the-hood to enable that. I 
> have Nagios configured to regularly check that Postfix is up, and separately 
> monitor my important milters.
> 
> If you're looking to write your own milter service, I'd join the dev 
> discussion list for one of the milters that supports AutoRestart (such as 
> OpenDKIM) and ask about it there. A good number of guys on this Postfix list 
> are also on that list. 
> 
> Or you could look through the source code on SourceForge and find the 
> AutoRestart stuff:
> 
> http://sourceforge.net/projects/opendkim/
> 
> SteveJ

postfix to mailman: User doesn't exist/relay access denied

[wal...@ifkuk.org]

Hey guys

since three days I am stuck with a problem and it seems to me I am blind
for the solution by digging
into it so much, so I need your help to have a look at it please!

our server is up and running dovecot/postfix on debian 8 for three years
by now, without any problems.

I urgently needed to set up some mailinglists and choose mailman for it
(what else?).

I thought everything went fine till I tried to test my installation and
discovered that,
when I try to send from an internal emailaddress (managed by the server
itself) I get an
"User doesn't exist" error and if I send an email from an external
service like gmail,
I get "relay access denied".

Like I've said, I tried to fix this problem for over three days now and
can't see my mistake.

I uploaded my config files at HowtoForge, where you can have a look at it:
https://www.howtoforge.com/community/threads/postfix-mailman-debian8.72052/


Greetings and thank you in advance for your help
Walter

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[Curtis Villamizar]

In message <49c94ad9-3c94-4c48-9726-0e81e1109...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Jan 31, 2016, at 1:01 AM, Curtis Villamizar  
> > wrote:
> > 
> > I use tcsh so:
> > 
> >  # sh -c 'postconf -c $(postconf -dh config_directory ) \
> > -h multi_instance_directories'
> >  postconf: warning: inet_protocols: disabling IPv4 name/address
> >  support: Protocol not supported
> >  # postconf -c /etc/postfix -h multi_instance_directories
> > 
> > This didn't complain about smtputf8_enable but did complain about
> > inet_protocols.  The second form didn't complain at all.
> > 
> >> This is used to determine whether you're starting a secondary instance, 
> >> and uses
> >> the default configuration directory, which really needs to be properly 
> >> configured,
> >> even with "postfix -c ...".
> > 
> > So I would have to edit both?
>  
> No, either use the compile-time default configuration directory as the actual
> configuration directory of the primary Postfix instance, or compile Postfix
> with /etc/postfix as the default configuration directory.  Your:
>  
>   postfix -c /etc/postfix
>  
> hack to avoid using the compile-time configuration directory is not supported.

I'm sorry I used a feature that was described in the documentation and
seemed to mostly work fine.  :-)

I'll convert to /usr/local/etc/postfix.

> I've already posted the relevant link, here it is again.
>  
>http://www.postfix.org/INSTALL.html#build_over

Perhaps someone should clarify the limitation of "-c config_dir" in
the man pages.

http://www.postfix.org/postalias.1.html
http://www.postfix.org/postcat.1.html
http://www.postfix.org/postconf.1.html
http://www.postfix.org/postfix.1.html
http://www.postfix.org/postkick.1.html
http://www.postfix.org/postlock.1.html
http://www.postfix.org/postlog.1.html
http://www.postfix.org/postmap.1.html
http://www.postfix.org/postqueue.1.html
http://www.postfix.org/postsuper.1.html

Also there is no mention of a restriction in:

http://www.postfix.org/postconf.5.html#config_directory

> Either accept the compile-time directory of /usr/local/etc/postfix (on the
> NetBSD system I use it is /usr/pkg/etc/postfix, which works just fine), or
> build Postfix to your taste if using /etc/postfix is very important to you.
>  
> -- 
>   Viktor.

OK.  I'm fine with moving it.  The configuration documentation led me
to believe that it was supposed to work but apparently that is not the
case and the limitation was only in the build documentation.  Sorry to
be so dense.

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

[LuKreme]

On Jan 30, 2016, at 22:42, Curtis Villamizar  wrote:
> It would be:
> 
>  cd /usr/local/etc
>  mv postfix postfix.old
>  ln -s ../../../etc/postfix postfix

 No, it most certainly would not. Your configuration files ARE in local, if you 
want to pretend they are in /etc, then create a link in etc.  I've done this 
for years. Works just fine.

> And yes I did try that.

And what you tried will not work.

DKIM Signing (postfix + amavis-new)

[John A @ KLaM]

1. This maybe off topic.
2. I am currently unable to get at the output of postconf -n etc.

In the past we have had occasional problems with DKIM signing not working. 
It would be one or two emails and we would not find out about the problem 
immediately.  Often the sender would put it down a transient blip in the 
system and not report the problem.


I recently had to come to NZ for family emergency and have been here for 
awhile and as a result have suffered the same problem on a much larger 
scale. It is fairly obvious that as I am sending email from an IP not in my 
networks and amavis-new is not signing my emails.


I found several solutions to the problem all of which were essentially the 
same, forward submitted (port 587) emails to amavis-new on port A, where a 
policy bank would be setup to sign them. All other mail would be forwarded 
on port B where it would be handle as per usual or normal.


My question is what is the best way of getting postfix to forward mail to 
the signing policy bank.
In one example the submission section of master.cf had the following lines 
added

smtpd_proxy_filter=[127.0.0.1]:10026
milter_macro_deamon_name=ORIGINATING
Added, I think l understand the first line but why the second, it does seem 
to appear anywhere else.


In another a single line was added to the submission section
Smtpd_content_filter=[127.0.0.1]:10026


John A
KlaM

Re: postfix to mailman: User doesn't exist/relay access denied

[wal...@ifkuk.org]

  
  
dead steven

i ve just checked, bot variables virtual_alias_maps and
virtual_email2email point to the file
/var/lib/mailman/data/virtual_mailman,
which contains:

mail...@lists.ifkuk.org  mailman
mailman-ad...@lists.ifkuk.org    mailman-admin
mailman-boun...@lists.ifkuk.org  mailman-bounces
mailman-conf...@lists.ifkuk.org  mailman-confirm
mailman-j...@lists.ifkuk.org mailman-join
mailman-le...@lists.ifkuk.org    mailman-leave
mailman-ow...@lists.ifkuk.org    mailman-owner
mailman-requ...@lists.ifkuk.org  mailman-request
mailman-subscr...@lists.ifkuk.org    mailman-subscribe
mailman-unsubscr...@lists.ifkuk.org  mailman-unsubscribe

t...@lists.ifkuk.org  test
test-ad...@lists.ifkuk.org    test-admin
test-boun...@lists.ifkuk.org  test-bounces
test-conf...@lists.ifkuk.org  test-confirm
test-j...@lists.ifkuk.org test-join
test-le...@lists.ifkuk.org    test-leave
test-ow...@lists.ifkuk.org    test-owner
test-requ...@lists.ifkuk.org  test-request
test-subscr...@lists.ifkuk.org    test-subscribe
test-unsubscr...@lists.ifkuk.org  test-unsubscribe

i ve followed a howto when doing so, the marked as solution answer@
http://stackoverflow.com/questions/27431010/postfix-mailman-recipient-address-rejected-user-unknown-in-local-recipient-tab

so what you are saying is, that i need an entry like
"*@lists.ifkuk.org XXX" ?
but to where should i forward it to? "mailman:"?

thx for pointing out the debug level, will check it asap!


thank you for your time
walter

On 2016-02-01 03:28, Steven Kiehl
  wrote:


  Not having used Mailman in a Postfix setup before,
I can only speculate a bit.  From what I can tell, all your mail
is delivering through the dovecot transport and no transport
designation is being performed for the mailman address aliases. 
I'm not familiar with a virtual_email2email configuration
option.  Do your list addresses map to anything in your
virtual_mailbox_maps configuration? That is, do they map to a
real address defined in virtual_mailbox_maps?


For me, aliases in virtual_alias_maps map to real addresses
  in virtual_mailbox_maps, and then map to transports in
  transport_maps where they get passed off to the appropriate
  handler.  I would imagine the mailman addresses need to be
  mapped in virtual_mailbox_maps and handed off via
  transport_maps.


Also, have you tried raising the debug level to diagnose
  the hand-off in logs?
  
  
On Sun, Jan 31, 2016 at 6:21 PM, wal...@ifkuk.org
  
  wrote:
  Hey guys

since three days I am stuck with a problem and it seems to
me I am blind
for the solution by digging
into it so much, so I need your help to have a look at it
please!

our server is up and running dovecot/postfix on debian 8 for
three years
by now, without any problems.

I urgently needed to set up some mailinglists and choose
mailman for it
(what else?).

I thought everything went fine till I tried to test my
installation and
discovered that,
when I try to send from an internal emailaddress (managed by
the server
itself) I get an
"User doesn't exist" error and if I send an email from an
external
service like gmail,
I get "relay access denied".

Like I've said, I tried to fix this problem for over three
days now and
can't see my mistake.

I uploaded my config files at HowtoForge, where you can have
a look at it:
https://www.howtoforge.com/community/threads/postfix-mailman-debian8.72052/


Greetings and thank you in advance for your help
Walter
  


  


  

Re: postfix to mailman: User doesn't exist/relay access denied

[Steven Kiehl]

Another thing to try is running the 'postfix check' command to test if
there are any obvious configuration errors.  As I said before, I'm not
familiar with a 'virtual_email2email' configuration, which is not
documented on the Postfix website; I believe people just use that as their
alias map configuration file name.

I'd have to defer to someone else mroe familiar with Mailman, but do you
know if it works to add 'hash:/var/lib/mailman/data/virtual-mailman' to the
'virtual_mailbox_maps' configuration to basically add the mailman addresses
in as real addresses instead of aliases, then set up a transport_maps
configuration for them.

virtual_mailbox_maps = proxy:pgsql:/etc/postfix/pgsql-virtual_mailboxes.cf,
hash:/var/lib/mailman/data/virtual-mailman

A number of support forums suggest the following type of configuration for
'transport_maps'. Most put the virtual-mailman in the virtual_alias_maps,
but it really comes down to being able to find the address somewhere as
valid before sending it to a designated transport.

transport_maps = hash:/var/lib/mailman/data/transport-mailman,
proxy:pgsql:/etc/postfix/pgsql-virtual_transports.cf

On Sun, Jan 31, 2016 at 9:43 PM, wal...@ifkuk.org  wrote:

> dead steven
>
> i ve just checked, bot variables virtual_alias_maps and
> virtual_email2email point to the file /var/lib/mailman/data/virtual_mailman,
> which contains:
>
> mail...@lists.ifkuk.org  mailman
> mailman-ad...@lists.ifkuk.orgmailman-admin
> mailman-boun...@lists.ifkuk.org  mailman-bounces
> mailman-conf...@lists.ifkuk.org  mailman-confirm
> mailman-j...@lists.ifkuk.org mailman-join
> mailman-le...@lists.ifkuk.orgmailman-leave
> mailman-ow...@lists.ifkuk.orgmailman-owner
> mailman-requ...@lists.ifkuk.org  mailman-request
> mailman-subscr...@lists.ifkuk.orgmailman-subscribe
> mailman-unsubscr...@lists.ifkuk.org  mailman-unsubscribe
>
> t...@lists.ifkuk.org  test
> test-ad...@lists.ifkuk.orgtest-admin
> test-boun...@lists.ifkuk.org  test-bounces
> test-conf...@lists.ifkuk.org  test-confirm
> test-j...@lists.ifkuk.org test-join
> test-le...@lists.ifkuk.orgtest-leave
> test-ow...@lists.ifkuk.orgtest-owner
> test-requ...@lists.ifkuk.org  test-request
> test-subscr...@lists.ifkuk.orgtest-subscribe
> test-unsubscr...@lists.ifkuk.org  test-unsubscribe
>
> i ve followed a howto when doing so, the marked as solution answer@
>
> http://stackoverflow.com/questions/27431010/postfix-mailman-recipient-address-rejected-user-unknown-in-local-recipient-tab
>
> so what you are saying is, that i need an entry like "*@lists.ifkuk.org
> XXX" <*@lists.ifkuk.orgXXX> ?
> but to where should i forward it to? "mailman:"?
>
> thx for pointing out the debug level, will check it asap!
>
>
> thank you for your time
> walter
>
>
> On 2016-02-01 03:28, Steven Kiehl wrote:
>
> Not having used Mailman in a Postfix setup before, I can only speculate a
> bit.  From what I can tell, all your mail is delivering through the dovecot
> transport and no transport designation is being performed for the mailman
> address aliases.  I'm not familiar with a virtual_email2email configuration
> option.  Do your list addresses map to anything in your
> virtual_mailbox_maps configuration? That is, do they map to a real address
> defined in virtual_mailbox_maps?
>
> For me, aliases in virtual_alias_maps map to real addresses in
> virtual_mailbox_maps, and then map to transports in transport_maps where
> they get passed off to the appropriate handler.  I would imagine the
> mailman addresses need to be mapped in virtual_mailbox_maps and handed off
> via transport_maps.
>
> Also, have you tried raising the debug level to diagnose the hand-off in
> logs?
>
> On Sun, Jan 31, 2016 at 6:21 PM, wal...@ifkuk.org <
> wal...@ifkuk.org> wrote:
>
>> Hey guys
>>
>> since three days I am stuck with a problem and it seems to me I am blind
>> for the solution by digging
>> into it so much, so I need your help to have a look at it please!
>>
>> our server is up and running dovecot/postfix on debian 8 for three years
>> by now, without any problems.
>>
>> I urgently needed to set up some mailinglists and choose mailman for it
>> (what else?).
>>
>> I thought everything went fine till I tried to test my installation and
>> discovered that,
>> when I try to send from an internal emailaddress (managed by the server
>> itself) I get an
>> "User doesn't exist" error and if I send an email from an external
>> service like gmail,
>> I get "relay access denied".
>>
>> Like I've said, I tried to fix this problem for over three days now and
>> can't see my mistake.
>>
>> I uploaded my config files at HowtoForge, where you can have a look at it:
>>
>> https://www.howtoforge.com/community/threads/postfix-mailman-debian8.72052/
>>
>>
>> Greetings and thank you in advance for your help
>> Walter
>>
>
>
>

Re: postfix to mailman: User doesn't exist/relay access denied

[Larry Stone]

> Mailman requires local(8) delivery via an aliases(5) file that
> belongs to the mailman user.  With any luck the OP will post actual
> configuration details to this list, rather than some website most
> readers won't bother to look at, and someone how knows Postfix<->mailman
> integration will provide some help.

I expect the poster will get better help on the Mailman Users list 
(https://mail.python.org/mailman/listinfo/mailman-users/ for information). 
There are lots of people who use Mailman with Postfix there.

In a standard Mailman with Postfix configuration, aliases are created 
(automatically by Mailman) to pipe the Mailman addresses to the proper Mailman 
program. Postfix transports are not involved (however, there are a lot of 
non-standard Mailman distributions out there). It appears the OP is doing 
something non-standard.

-- 
Larry Stone
lston...@stonejongleux.com







smime.p7s
Description: S/MIME cryptographic signature

Re: postfix to mailman: User doesn't exist/relay access denied

[Steven Kiehl]

Not having used Mailman in a Postfix setup before, I can only speculate a
bit.  From what I can tell, all your mail is delivering through the dovecot
transport and no transport designation is being performed for the mailman
address aliases.  I'm not familiar with a virtual_email2email configuration
option.  Do your list addresses map to anything in your
virtual_mailbox_maps configuration? That is, do they map to a real address
defined in virtual_mailbox_maps?

For me, aliases in virtual_alias_maps map to real addresses in
virtual_mailbox_maps, and then map to transports in transport_maps where
they get passed off to the appropriate handler.  I would imagine the
mailman addresses need to be mapped in virtual_mailbox_maps and handed off
via transport_maps.

Also, have you tried raising the debug level to diagnose the hand-off in
logs?

On Sun, Jan 31, 2016 at 6:21 PM, wal...@ifkuk.org  wrote:

> Hey guys
>
> since three days I am stuck with a problem and it seems to me I am blind
> for the solution by digging
> into it so much, so I need your help to have a look at it please!
>
> our server is up and running dovecot/postfix on debian 8 for three years
> by now, without any problems.
>
> I urgently needed to set up some mailinglists and choose mailman for it
> (what else?).
>
> I thought everything went fine till I tried to test my installation and
> discovered that,
> when I try to send from an internal emailaddress (managed by the server
> itself) I get an
> "User doesn't exist" error and if I send an email from an external
> service like gmail,
> I get "relay access denied".
>
> Like I've said, I tried to fix this problem for over three days now and
> can't see my mistake.
>
> I uploaded my config files at HowtoForge, where you can have a look at it:
> https://www.howtoforge.com/community/threads/postfix-mailman-debian8.72052/
>
>
> Greetings and thank you in advance for your help
> Walter
>

Re: postfix to mailman: User doesn't exist/relay access denied

[Viktor Dukhovni]

On Sun, Jan 31, 2016 at 11:35:51PM -0500, Steven Kiehl wrote:

> Another thing to try is running the 'postfix check' command to test if
> there are any obvious configuration errors.

Neither the debug level suggestion nor this one are likely to be
of any use.

> I'd have to defer to someone else more familiar with Mailman, but do you
> know if it works to add 'hash:/var/lib/mailman/data/virtual-mailman' to the
> 'virtual_mailbox_maps' configuration to basically add the mailman addresses
> in as real addresses instead of aliases, then set up a transport_maps
> configuration for them.

Mailman requires local(8) delivery via an aliases(5) file that
belongs to the mailman user.  With any luck the OP will post actual
configuration details to this list, rather than some website most
readers won't bother to look at, and someone how knows Postfix<->mailman
integration will provide some help.

-- 
Viktor.

Re: Spawning milter processes

[Robert Schetterer]

Am 31.01.2016 um 09:56 schrieb Ron Garret:
> Hello,
> 
> What is the usual way to start a milter process?  Can postfix be configured 
> to spawn it automatically, or does the milter have to be set up as a separate 
> service?  If the former, how do you do it?
> 
> Thanks,
> rg
> 

milters are usually seperate services


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

Spawning milter processes

[Ron Garret]

Hello,

What is the usual way to start a milter process?  Can postfix be configured to 
spawn it automatically, or does the milter have to be set up as a separate 
service?  If the former, how do you do it?

Thanks,
rg

Re: PCRE regex in header_checks ignored - why?

[Sebastian Wolfgarten]

Hi Sebastian,

yes but this would require me to actually know all the hostnames upfront, i.e. 
I cannot use a PCRE regex if I am not mistaken, or?

Thanks.

Best regards
Sebastian

> Am 31.01.2016 um 12:52 schrieb Sebastian Nielsen :
> 
> I would suggest use check_sender_access intead of header checks. Then you can 
> reject based on MAIL FROM:, since apparently the hosts are using their e**. 
> hostname in MAIL FROM.
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] För Sebastian Wolfgarten
> Skickat: den 31 januari 2016 11:56
> Till: postfix-users@postfix.org
> Ämne: PCRE regex in header_checks ignored - why? [Invalid]
> 
> Hi,
> 
> I have a problem with a PCRE-based rule in header_checks which seems to be 
> ignored and I can’t understand why this is the case. Hopefully you guys have 
> an idea on how to fix this :-)
> 
> So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as I am 
> being bombarded with emails from certain hosts in France (and I have no idea 
> why). These hosts are always following this format:
> 
> letter e
> 1-2 digit number
> hostname
> .fr
> 
> Here are some samples from today:
> 
> e16.sodipoc.fr
> e38.info-essentiel.fr
> e42.1jour1news.fr
> 
> I have defined a rule in SpamAssassin which successfully marks the related 
> spam accordingly (works like a charm):
> 
> header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i score French_Spam 4.8
> 
> Now I am trying not to mark the unsolicited emails anymore but block them 
> entirely. As such I have defined the following rule in header_checks based on 
> the rule that I have defined in SpamAssassin:
> 
> /e\d{1,2}\.\S+\.fr/i REJECT French Spam
> 
> I reloaded Postfix (postmap is not necessary for PCRE files, or?) but still I 
> have received three spam mails today. Still the rule seems okay from my 
> perspective - here is a test of the rule with three hosts I have received 
> spam from today:
> 
> $ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks REJECT French 
> Spam
> 
> $ postmap -q "e38.info-essentiel.fr" pcre:/etc/postfix/header_checks REJECT 
> French Spam
> 
> $ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks REJECT 
> French Spam
> 
> Any idea why this is happening?
> 
> Here an extract of the headers of one of the emails received today (note: The 
> message was marked as spam by Postfix but I manually removed all the related 
> headers and information not to end up in your spam filters):
> 
> Return-Path: 
> Delivered-To: sebast...@wolfgarten.com
> Received: from waldfest (localhost [127.0.0.1])
>   by waldfest.wolfgarten.com (Postfix) with ESMTP id 4154D704B9
>   for ; Sun, 31 Jan 2016 11:06:58 +0100 (CET)
> X-Quarantine-ID: 
> Received: from waldfest.wolfgarten.com ([127.0.0.1])
>   by waldfest (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 
> 10024)
>   with LMTP id xg91jhFD9UJP for ;
>   Sun, 31 Jan 2016 11:06:44 +0100 (CET)
> X-Greylist: delayed 300 seconds by postgrey-1.36 at waldfest; Sun, 31 Jan 
> 2016 11:06:44 CET
> Received: from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102])
>   by waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC
>   for ; Sun, 31 Jan 2016 11:06:44 +0100 (CET)
> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; 
> d=e42.1jour1news.fr;  
> h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
>  i=s...@e42.1jour1news.fr;  bh=zQj93n30egRyo2hFB5OnJZSylLw=;  
> b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
>   6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
>   y0Nre8XUjO0vR+d2Jbs=
> DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key; d=e42.1jour1news.fr;  
> b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
>   LxgAMqLl9nmkNLI6FRS0zn3cC/Pq8wUoUxdhyity3JWxiTo3q12ZP2/UxsYaOcWccB03Ch8VsB2u
>   9dhJQsHlnHCxcvj2Grs=;
> List-Unsubscribe: 
> 
> Message-ID: <1454234504.tinkiwinkilalapo56addb880b...@link.lilinews.fr>
> Date: Sun, 31 Jan 2016 11:01:44 +0100
> Subject: =?UTF-8?Q?15=E2=82=AC?= offerts sur la nouvelle collection
> 
> Finally, here is Postfix config:
> 
> alias_maps = hash:/etc/aliases,mysql:/etc/postfix/mysql_virtual_alias_maps.cf
> body_checks = pcre:/etc/postfix/body_checks,pcre:/etc/postfix/bad_urls
> canonical_maps = regexp:/etc/postfix/rewrite command_directory = /usr/sbin 
> config_directory = /etc/postfix content_filter = amavisfeed:[127.0.0.1]:10024 
> daemon_directory = /usr/libexec/postfix data_directory = /var/db/postfix 
> debug_peer_level = 2 debugger_command = 
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
> 

SV: PCRE regex in header_checks ignored - why?

[Sebastian Nielsen]

I would suggest use check_sender_access intead of header checks. Then you can 
reject based on MAIL FROM:, since apparently the hosts are using their e**. 
hostname in MAIL FROM.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Sebastian Wolfgarten
Skickat: den 31 januari 2016 11:56
Till: postfix-users@postfix.org
Ämne: PCRE regex in header_checks ignored - why? [Invalid]

Hi,

I have a problem with a PCRE-based rule in header_checks which seems to be 
ignored and I can’t understand why this is the case. Hopefully you guys have an 
idea on how to fix this :-)

So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as I am being 
bombarded with emails from certain hosts in France (and I have no idea why). 
These hosts are always following this format:

letter e
1-2 digit number
hostname
.fr

Here are some samples from today:

e16.sodipoc.fr
e38.info-essentiel.fr
e42.1jour1news.fr

I have defined a rule in SpamAssassin which successfully marks the related spam 
accordingly (works like a charm):

header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i score French_Spam 4.8

Now I am trying not to mark the unsolicited emails anymore but block them 
entirely. As such I have defined the following rule in header_checks based on 
the rule that I have defined in SpamAssassin:

/e\d{1,2}\.\S+\.fr/i REJECT French Spam

I reloaded Postfix (postmap is not necessary for PCRE files, or?) but still I 
have received three spam mails today. Still the rule seems okay from my 
perspective - here is a test of the rule with three hosts I have received spam 
from today:

$ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks REJECT French Spam

$ postmap -q "e38.info-essentiel.fr" pcre:/etc/postfix/header_checks REJECT 
French Spam

$ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks REJECT French 
Spam

Any idea why this is happening?

Here an extract of the headers of one of the emails received today (note: The 
message was marked as spam by Postfix but I manually removed all the related 
headers and information not to end up in your spam filters):

Return-Path: 
Delivered-To: sebast...@wolfgarten.com
Received: from waldfest (localhost [127.0.0.1])
by waldfest.wolfgarten.com (Postfix) with ESMTP id 4154D704B9
for ; Sun, 31 Jan 2016 11:06:58 +0100 (CET)
X-Quarantine-ID: 
Received: from waldfest.wolfgarten.com ([127.0.0.1])
by waldfest (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 
10024)
with LMTP id xg91jhFD9UJP for ;
Sun, 31 Jan 2016 11:06:44 +0100 (CET)
X-Greylist: delayed 300 seconds by postgrey-1.36 at waldfest; Sun, 31 Jan 2016 
11:06:44 CET
Received: from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102])
by waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC
for ; Sun, 31 Jan 2016 11:06:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; d=e42.1jour1news.fr; 
 
h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
 i=s...@e42.1jour1news.fr;  bh=zQj93n30egRyo2hFB5OnJZSylLw=;  
b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
   6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
   y0Nre8XUjO0vR+d2Jbs=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key; d=e42.1jour1news.fr;  
b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
   LxgAMqLl9nmkNLI6FRS0zn3cC/Pq8wUoUxdhyity3JWxiTo3q12ZP2/UxsYaOcWccB03Ch8VsB2u
   9dhJQsHlnHCxcvj2Grs=;
List-Unsubscribe: 

Message-ID: <1454234504.tinkiwinkilalapo56addb880b...@link.lilinews.fr>
Date: Sun, 31 Jan 2016 11:01:44 +0100
Subject: =?UTF-8?Q?15=E2=82=AC?= offerts sur la nouvelle collection

Finally, here is Postfix config:

alias_maps = hash:/etc/aliases,mysql:/etc/postfix/mysql_virtual_alias_maps.cf
body_checks = pcre:/etc/postfix/body_checks,pcre:/etc/postfix/bad_urls
canonical_maps = regexp:/etc/postfix/rewrite command_directory = /usr/sbin 
config_directory = /etc/postfix content_filter = amavisfeed:[127.0.0.1]:10024 
daemon_directory = /usr/libexec/postfix data_directory = /var/db/postfix 
debug_peer_level = 2 debugger_command = 
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5 
default_destination_concurrency_limit = 20 dovecot_destination_recipient_limit 
= 1 header_checks = pcre:/etc/postfix/header_checks html_directory = 
/usr/share/doc/postfix in_flow_delay = 1s inet_interfaces = all inet_protocols 
= ipv4 local_destination_concurrency_limit = 2 mail_owner = postfix 
mail_spool_directory = /var/mail mailbox_size_limit = 0 mailq_path = 
/usr/bin/mailq manpage_directory = 

SV: PCRE regex in header_checks ignored - why?

[Sebastian Nielsen]

No, you can use PCRE lists with check_sender_access too.
I use it successfully to block certain tld's and partial domains.

However, I would suggest using DISCARD instead of REJECT. With REJECT, you tell 
the spammer that he got blocked, thus he will switch to a new domain.
With DISCARD, it will silently "swallow" the email (eg pipe it to /dev/null), 
thus the spammer will think the email got through the spam filter.
(However, only use DISCARD with hosts/domains you are 100% sure its spam 
related and no legit mail will ever originate from that particular host or 
domain, if unsure, use REJECT instead).

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Sebastian Wolfgarten
Skickat: den 31 januari 2016 14:03
Till: Sebastian Nielsen 
Kopia: postfix-users@postfix.org
Ämne: Re: PCRE regex in header_checks ignored - why? [Invalid]

Hi Sebastian,

yes but this would require me to actually know all the hostnames upfront, i.e. 
I cannot use a PCRE regex if I am not mistaken, or?

Thanks.

Best regards
Sebastian

> Am 31.01.2016 um 12:52 schrieb Sebastian Nielsen :
> 
> I would suggest use check_sender_access intead of header checks. Then you can 
> reject based on MAIL FROM:, since apparently the hosts are using their e**. 
> hostname in MAIL FROM.
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] För Sebastian Wolfgarten
> Skickat: den 31 januari 2016 11:56
> Till: postfix-users@postfix.org
> Ämne: PCRE regex in header_checks ignored - why? [Invalid]
> 
> Hi,
> 
> I have a problem with a PCRE-based rule in header_checks which seems 
> to be ignored and I can’t understand why this is the case. Hopefully 
> you guys have an idea on how to fix this :-)
> 
> So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as I am 
> being bombarded with emails from certain hosts in France (and I have no idea 
> why). These hosts are always following this format:
> 
> letter e
> 1-2 digit number
> hostname
> .fr
> 
> Here are some samples from today:
> 
> e16.sodipoc.fr
> e38.info-essentiel.fr
> e42.1jour1news.fr
> 
> I have defined a rule in SpamAssassin which successfully marks the related 
> spam accordingly (works like a charm):
> 
> header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i score French_Spam 4.8
> 
> Now I am trying not to mark the unsolicited emails anymore but block them 
> entirely. As such I have defined the following rule in header_checks based on 
> the rule that I have defined in SpamAssassin:
> 
> /e\d{1,2}\.\S+\.fr/i REJECT French Spam
> 
> I reloaded Postfix (postmap is not necessary for PCRE files, or?) but still I 
> have received three spam mails today. Still the rule seems okay from my 
> perspective - here is a test of the rule with three hosts I have received 
> spam from today:
> 
> $ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks REJECT 
> French Spam
> 
> $ postmap -q "e38.info-essentiel.fr" pcre:/etc/postfix/header_checks 
> REJECT French Spam
> 
> $ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks 
> REJECT French Spam
> 
> Any idea why this is happening?
> 
> Here an extract of the headers of one of the emails received today (note: The 
> message was marked as spam by Postfix but I manually removed all the related 
> headers and information not to end up in your spam filters):
> 
> Return-Path: 
> Delivered-To: sebast...@wolfgarten.com
> Received: from waldfest (localhost [127.0.0.1])
>   by waldfest.wolfgarten.com (Postfix) with ESMTP id 4154D704B9
>   for ; Sun, 31 Jan 2016 11:06:58 +0100 (CET)
> X-Quarantine-ID: 
> Received: from waldfest.wolfgarten.com ([127.0.0.1])
>   by waldfest (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 
> 10024)
>   with LMTP id xg91jhFD9UJP for ;
>   Sun, 31 Jan 2016 11:06:44 +0100 (CET)
> X-Greylist: delayed 300 seconds by postgrey-1.36 at waldfest; Sun, 31 
> Jan 2016 11:06:44 CET
> Received: from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102])
>   by waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC
>   for ; Sun, 31 Jan 2016 11:06:44 +0100 (CET)
> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; 
> d=e42.1jour1news.fr;  
> h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
>  i=s...@e42.1jour1news.fr;  bh=zQj93n30egRyo2hFB5OnJZSylLw=;  
> b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
>   6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
>   y0Nre8XUjO0vR+d2Jbs=
> DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key; d=e42.1jour1news.fr;  
> b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
>   

PCRE regex in header_checks ignored - why?

[Sebastian Wolfgarten]

Hi,

I have a problem with a PCRE-based rule in header_checks which seems to be 
ignored and I can’t understand why this is the case. Hopefully you guys have an 
idea on how to fix this :-)

So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as I am being 
bombarded with emails from certain hosts in France (and I have no idea why). 
These hosts are always following this format:

letter e
1-2 digit number
hostname
.fr

Here are some samples from today:

e16.sodipoc.fr
e38.info-essentiel.fr
e42.1jour1news.fr

I have defined a rule in SpamAssassin which successfully marks the related spam 
accordingly (works like a charm):

header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i
score French_Spam 4.8

Now I am trying not to mark the unsolicited emails anymore but block them 
entirely. As such I have defined the following rule in header_checks based on 
the rule that I have defined in SpamAssassin:

/e\d{1,2}\.\S+\.fr/i REJECT French Spam

I reloaded Postfix (postmap is not necessary for PCRE files, or?) but still I 
have received three spam mails today. Still the rule seems okay from my 
perspective - here is a test of the rule with three hosts I have received spam 
from today:

$ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks
REJECT French Spam

$ postmap -q "e38.info-essentiel.fr" pcre:/etc/postfix/header_checks
REJECT French Spam

$ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks
REJECT French Spam

Any idea why this is happening?

Here an extract of the headers of one of the emails received today (note: The 
message was marked as spam by Postfix but I manually removed all the related 
headers and information not to end up in your spam filters):

Return-Path: 
Delivered-To: sebast...@wolfgarten.com
Received: from waldfest (localhost [127.0.0.1])
by waldfest.wolfgarten.com (Postfix) with ESMTP id 4154D704B9
for ; Sun, 31 Jan 2016 11:06:58 +0100 (CET)
X-Quarantine-ID: 
Received: from waldfest.wolfgarten.com ([127.0.0.1])
by waldfest (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 
10024)
with LMTP id xg91jhFD9UJP for ;
Sun, 31 Jan 2016 11:06:44 +0100 (CET)
X-Greylist: delayed 300 seconds by postgrey-1.36 at waldfest; Sun, 31 Jan 2016 
11:06:44 CET
Received: from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102])
by waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC
for ; Sun, 31 Jan 2016 11:06:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; d=e42.1jour1news.fr;
 
h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
 i=s...@e42.1jour1news.fr;
 bh=zQj93n30egRyo2hFB5OnJZSylLw=;
 b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
   6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
   y0Nre8XUjO0vR+d2Jbs=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key; d=e42.1jour1news.fr;
 b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
   LxgAMqLl9nmkNLI6FRS0zn3cC/Pq8wUoUxdhyity3JWxiTo3q12ZP2/UxsYaOcWccB03Ch8VsB2u
   9dhJQsHlnHCxcvj2Grs=;
List-Unsubscribe: 

Message-ID: <1454234504.tinkiwinkilalapo56addb880b...@link.lilinews.fr>
Date: Sun, 31 Jan 2016 11:01:44 +0100
Subject: =?UTF-8?Q?15=E2=82=AC?= offerts sur la nouvelle collection

Finally, here is Postfix config:

alias_maps = hash:/etc/aliases,mysql:/etc/postfix/mysql_virtual_alias_maps.cf
body_checks = pcre:/etc/postfix/body_checks,pcre:/etc/postfix/bad_urls
canonical_maps = regexp:/etc/postfix/rewrite
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 20
dovecot_destination_recipient_limit = 1
header_checks = pcre:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix
in_flow_delay = 1s
inet_interfaces = all
inet_protocols = ipv4
local_destination_concurrency_limit = 2
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 0
milter_default_action = accept
milter_protocol = 2
mlmmj_destination_recipient_limit = 1
mydestination = $myhostname, sms.wolfgarten.com
mydomain = wolfgarten.com
myhostname = waldfest.wolfgarten.com
mynetworks = ***REMOVED***
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = $smtpd_milters
propagate_unmatched_extensions = virtual
queue_directory = /var/spool/postfix

Re: PCRE regex in header_checks ignored - why?

[wilfried.es...@essignetz.de]

Hi,

do you use amavis in before or after queue mode?

If before, you should possibly look to your master.cf, to the lines
who get the mail from amavis back. Do you have somthing like

-o receive_override_options=no_header_body_checks
or
-o header_checks=
there ?

Willi


Am 31.01.2016 um 11:56 schrieb Sebastian Wolfgarten:
> Hi,
> 
> I have a problem with a PCRE-based rule in header_checks which
> seems to be ignored and I can’t understand why this is the case.
> Hopefully you guys have an idea on how to fix this :-)
> 
> So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as
> I am being bombarded with emails from certain hosts in France (and
> I have no idea why). These hosts are always following this format:
> 
> letter e 1-2 digit number hostname .fr
> 
> Here are some samples from today:
> 
> e16.sodipoc.fr e38.info-essentiel.fr e42.1jour1news.fr
> 
> I have defined a rule in SpamAssassin which successfully marks the
> related spam accordingly (works like a charm):
> 
> header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i score French_Spam
> 4.8
> 
> Now I am trying not to mark the unsolicited emails anymore but
> block them entirely. As such I have defined the following rule in
> header_checks based on the rule that I have defined in
> SpamAssassin:
> 
> /e\d{1,2}\.\S+\.fr/i REJECT French Spam
> 
> I reloaded Postfix (postmap is not necessary for PCRE files, or?)
> but still I have received three spam mails today. Still the rule
> seems okay from my perspective - here is a test of the rule with
> three hosts I have received spam from today:
> 
> $ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks 
> REJECT French Spam
> 
> $ postmap -q "e38.info-essentiel.fr"
> pcre:/etc/postfix/header_checks REJECT French Spam
> 
> $ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks 
> REJECT French Spam
> 
> Any idea why this is happening?
> 
> Here an extract of the headers of one of the emails received today
> (note: The message was marked as spam by Postfix but I manually
> removed all the related headers and information not to end up in
> your spam filters):
> 
> Return-Path:  Delivered-To:
> sebast...@wolfgarten.com Received: from waldfest (localhost
> [127.0.0.1]) by waldfest.wolfgarten.com (Postfix) with ESMTP id
> 4154D704B9 for ; Sun, 31 Jan 2016
> 11:06:58 +0100 (CET) X-Quarantine-ID:  Received: from
> waldfest.wolfgarten.com ([127.0.0.1]) by waldfest
> (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 10024) 
> with LMTP id xg91jhFD9UJP for ; Sun, 31
> Jan 2016 11:06:44 +0100 (CET) X-Greylist: delayed 300 seconds by
> postgrey-1.36 at waldfest; Sun, 31 Jan 2016 11:06:44 CET Received:
> from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102]) by
> waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC for
> ; Sun, 31 Jan 2016 11:06:44 +0100 (CET) 
> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key;
> d=e42.1jour1news.fr; 
> h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
> i=s...@e42.1jour1news.fr; bh=zQj93n30egRyo2hFB5OnJZSylLw=; 
> b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
>
> 
6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
> y0Nre8XUjO0vR+d2Jbs= DomainKey-Signature: a=rsa-sha1; c=nofws;
> q=dns; s=key; d=e42.1jour1news.fr; 
> b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
>
> 
LxgAMqLl9nmkNLI6FRS0zn3cC/Pq8wUoUxdhyity3JWxiTo3q12ZP2/UxsYaOcWccB03Ch8VsB2u
> 9dhJQsHlnHCxcvj2Grs=; List-Unsubscribe:
> 
>
> 
Message-ID: <1454234504.tinkiwinkilalapo56addb880b...@link.lilinews.fr>
> Date: Sun, 31 Jan 2016 11:01:44 +0100 Subject:
> =?UTF-8?Q?15=E2=82=AC?= offerts sur la nouvelle collection
> 
> Finally, here is Postfix config:
> 
> alias_maps =
> hash:/etc/aliases,mysql:/etc/postfix/mysql_virtual_alias_maps.cf 
> body_checks =
> pcre:/etc/postfix/body_checks,pcre:/etc/postfix/bad_urls 
> canonical_maps = regexp:/etc/postfix/rewrite command_directory =
> /usr/sbin config_directory = /etc/postfix content_filter =
> amavisfeed:[127.0.0.1]:10024 daemon_directory =
> /usr/libexec/postfix data_directory = /var/db/postfix 
> debug_peer_level = 2 debugger_command =
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
> $daemon_directory/$process_name $process_id & sleep 5 
> default_destination_concurrency_limit = 20 
> dovecot_destination_recipient_limit = 1 header_checks =
> pcre:/etc/postfix/header_checks html_directory =
> /usr/share/doc/postfix in_flow_delay = 1s inet_interfaces = all 
> inet_protocols = ipv4 local_destination_concurrency_limit = 2 
> mail_owner = postfix mail_spool_directory = /var/mail 
> mailbox_size_limit = 0 mailq_path = /usr/bin/mailq 
> 

Re: PCRE regex in header_checks ignored - why?

[Sebastian Wolfgarten]

Hi,

spot on: I did have indeed the override_options set not to do any 
header_body_checks. I just removed the option which should hopefully fix my 
problem.

Many thanks again. I didn’t think of this.

Best regards
Sebastian

> Am 31.01.2016 um 14:44 schrieb wilfried.es...@essignetz.de:
> 
> Hi,
> 
> do you use amavis in before or after queue mode?
> 
> If before, you should possibly look to your master.cf, to the lines
> who get the mail from amavis back. Do you have somthing like
> 
>   -o receive_override_options=no_header_body_checks
> or
>   -o header_checks=
> there ?
> 
> Willi
> 
> 
> Am 31.01.2016 um 11:56 schrieb Sebastian Wolfgarten:
>> Hi,
>> 
>> I have a problem with a PCRE-based rule in header_checks which
>> seems to be ignored and I can’t understand why this is the case.
>> Hopefully you guys have an idea on how to fix this :-)
>> 
>> So here is my setup: I am using Postfix 2.11.7 on FreeBSD 10 and as
>> I am being bombarded with emails from certain hosts in France (and
>> I have no idea why). These hosts are always following this format:
>> 
>> letter e 1-2 digit number hostname .fr
>> 
>> Here are some samples from today:
>> 
>> e16.sodipoc.fr e38.info-essentiel.fr e42.1jour1news.fr
>> 
>> I have defined a rule in SpamAssassin which successfully marks the
>> related spam accordingly (works like a charm):
>> 
>> header French_Spam ALL =~ / e\d{1,2}\.\S+\.fr /i score French_Spam
>> 4.8
>> 
>> Now I am trying not to mark the unsolicited emails anymore but
>> block them entirely. As such I have defined the following rule in
>> header_checks based on the rule that I have defined in
>> SpamAssassin:
>> 
>> /e\d{1,2}\.\S+\.fr/i REJECT French Spam
>> 
>> I reloaded Postfix (postmap is not necessary for PCRE files, or?)
>> but still I have received three spam mails today. Still the rule
>> seems okay from my perspective - here is a test of the rule with
>> three hosts I have received spam from today:
>> 
>> $ postmap -q "e16.sodipoc.fr" pcre:/etc/postfix/header_checks
>> REJECT French Spam
>> 
>> $ postmap -q "e38.info-essentiel.fr"
>> pcre:/etc/postfix/header_checks REJECT French Spam
>> 
>> $ postmap -q "e42.1jour1news.fr" pcre:/etc/postfix/header_checks
>> REJECT French Spam
>> 
>> Any idea why this is happening?
>> 
>> Here an extract of the headers of one of the emails received today
>> (note: The message was marked as spam by Postfix but I manually
>> removed all the related headers and information not to end up in
>> your spam filters):
>> 
>> Return-Path:  Delivered-To:
>> sebast...@wolfgarten.com Received: from waldfest (localhost
>> [127.0.0.1]) by waldfest.wolfgarten.com (Postfix) with ESMTP id
>> 4154D704B9 for ; Sun, 31 Jan 2016
>> 11:06:58 +0100 (CET) X-Quarantine-ID:  Received: from
>> waldfest.wolfgarten.com ([127.0.0.1]) by waldfest
>> (waldfest.wolfgarten.com [127.0.0.1]) (amavisd-new, port 10024)
>> with LMTP id xg91jhFD9UJP for ; Sun, 31
>> Jan 2016 11:06:44 +0100 (CET) X-Greylist: delayed 300 seconds by
>> postgrey-1.36 at waldfest; Sun, 31 Jan 2016 11:06:44 CET Received:
>> from e42.1jour1news.fr (e42.1jour1news.fr [62.210.13.102]) by
>> waldfest.wolfgarten.com (Postfix) with ESMTP id A6750704AC for
>> ; Sun, 31 Jan 2016 11:06:44 +0100 (CET)
>> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key;
>> d=e42.1jour1news.fr;
>> h=List-Unsubscribe:Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
>> i=s...@e42.1jour1news.fr; bh=zQj93n30egRyo2hFB5OnJZSylLw=;
>> b=FSLGriDlKRcl/NXBkxXU7ANj7JEO3+ltGllwY3hZu2bXxjJLXjFbz+fTZljB2BHbYMaKFmZxd6cF
>> 
>> 
> 6OhoV689FNZPqC1SBUt7rA2qMTRP0gqpuCGkMqTZ9KaSObrSNlZgCsxnsOuLWt7zrjF1OHL6jT8C
>> y0Nre8XUjO0vR+d2Jbs= DomainKey-Signature: a=rsa-sha1; c=nofws;
>> q=dns; s=key; d=e42.1jour1news.fr;
>> b=Y4c0lfDPkQ4YaimLaY4exKzB9WpnZVLpQ+HP7976BIB5gFzWEIF+n9wYB7afXxThUNNWaomOHcJs
>> 
>> 
> LxgAMqLl9nmkNLI6FRS0zn3cC/Pq8wUoUxdhyity3JWxiTo3q12ZP2/UxsYaOcWccB03Ch8VsB2u
>> 9dhJQsHlnHCxcvj2Grs=; List-Unsubscribe:
>> 
>> 
>> 
> Message-ID: <1454234504.tinkiwinkilalapo56addb880b...@link.lilinews.fr>
>> Date: Sun, 31 Jan 2016 11:01:44 +0100 Subject:
>> =?UTF-8?Q?15=E2=82=AC?= offerts sur la nouvelle collection
>> 
>> Finally, here is Postfix config:
>> 
>> alias_maps =
>> hash:/etc/aliases,mysql:/etc/postfix/mysql_virtual_alias_maps.cf
>> body_checks =
>> pcre:/etc/postfix/body_checks,pcre:/etc/postfix/bad_urls
>> canonical_maps = regexp:/etc/postfix/rewrite command_directory =
>> /usr/sbin config_directory = /etc/postfix content_filter =
>> amavisfeed:[127.0.0.1]:10024 daemon_directory =
>> /usr/libexec/postfix data_directory = /var/db/postfix
>> debug_peer_level = 2 debugger_command =
>> PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
>> $daemon_directory/$process_name $process_id & sleep