>Alex:
>if it was
>
>^From:.*\@.*\.tw$
>it would not.
$ is optional and it only means the end of expression, the rule works either
with or without it in the problem I was trying to solve.
>And again according to the man page, $ is usable:
>"/^(.*)-outgoing@(.*)$/"
This is again an option ($), n
>...could you advise if it is actually possible to use both before-queue and
>after-queue filtering?
> Reindl
>surely but how does that make sense?
It makes because it will use two filters, not just one. It will filter before
queue first and then anything that may be missed or let through on pu
>Joseph Tam writes:
>
> However, my header_checks file has just 5 lines of regexp as follows:
> ...
> /^From:.*\@.*\.tw/ REJECT Sorry, Taiwanese mail is not
> allowed.
>
>Can't speak about the other issues you are having, but is this regexp pattern
>what you want? Unless Po
>Reindl:
>that's no problem because with RBL weighting and postscreen you reject 95% of
>the crap before it ever touchs smtpd or even the contentfilter that stats
>below are about a maillog starting with Sep 18 19:50:39
>for some hundrest domains and currently 2000 valid RCPT, if the contentfilte
>Alex:
>One *very* convincing argument not to send an *email* response (reject at SMTP
>is fine) is that it is very likely indeed you'll end up on an RBL yourself for
>doing this. It happened to us when we were still bouncing (probably >about
>8-10 years ago). It was the main reason we stopped.
>it is true and besides the german legal letter below you violate a second law
>at the same time - that is why you have to run a spamfilter *before queue* and
>sa-milter exists - in case you reject a message
>the sending server is responsible for a bounce
>
>in case you accept and silently drop i
>I realise it's probably because of the use of the reject action, which
>presumably inserts the text "No spamming allowed here." into the subject of
>the bounce.
>
>However what also concerns me is that sending MDN's back to the envelope
>sender of SPAM messages is very likely to cause your ser
>Not true. Postfix regexp (and pcre) matches are case insensitive by default,
>adding the /i flag makes them case sensitive. This should be quite clear in
>the postfix docs quoted above. This documented
>default behavior may be different from other software you're familiar with.
>
>You're welc
>So why does it state in man 5 regexp_table that such tables are *case
>insensitive* by default and the /i actually toggles that? Are you saying that
>man page is wrong? I'd be surprised as I don't think I've yet come
>across an occasion where postfix man pages are incorrect!
I am not saying tha
> /^Subject:.**{5}SPAM*{5}/REJECT No spammers allowed here.
> /^Subject:.*\*\*\*\*\*SPAM\*\*\*\*\*/REJECT No spammers allowed.
> /\s**{5}SPAM*{5}/REJECT No spamming
> hullababballos allowed.
>I think it may be this one above. From the postfix manuals"By
action as per my previous guess?
But the target to perform this same action on was different... Any more ideas
anyone? Alex? Many thanks in advance for any input!
From: Klaipedaville on Google
Sent: Friday, September 26, 2014 15:00
To: Alex Crow ; dovecot@dovecot.org
Subject: Re: Dovecot Siev
to be rejected.
There is no reason why you cannot use both.
On 26/09/14 12:35, Klaipedaville on Google wrote:
> Hello List,
>
> I tried to subscribe but it's taking forever for the confirmation email to
> arrive so I thought I would ask away by emailing directly. My apologies in
Hello List,
I tried to subscribe but it's taking forever for the confirmation email to
arrive so I thought I would ask away by emailing directly. My apologies in
advance should this question appear twice.
It may seem real simple to experts but I cannot really figure it out. I'll try
to be conc
13 matches
Mail list logo
