Noel Jones-2 wrote
> On 6/8/2019 10:11 AM, Den1 wrote:
>> Hello,
>>
>> I would be really thankful if someone could clarify it, please. It says
>> the
>> following, "Postfix works as documented in regexp_table(5) and
>> pcre_table(5), i.e. each query stops at the first matching rule. Now the
>> fol
Viktor Dukhovni wrote
>> On Jun 9, 2019, at 12:42 AM, Webmaster <
> webmaster@.klaipedaville
> > wrote:
>>
> The answer is simple. Postfix header checks DO NOT support any sort
> of multi-header conditionals or logic that depends on the order in
> which headers are checked against the rules. E
> On Jun 9, 2019, at 12:42 AM, Webmaster
> wrote:
>
> OK. This is gmail.com and the sequence / order of its headers is always the
> same isn't it? Plus, that is always the same user, always the same email
> address, always the same "empty" subject field and always the same recipient
> all the
OK. This is gmail.com and the sequence / order of its headers is always the
same isn't it? Plus, that is always the same user, always the same email
address, always the same "empty" subject field and always the same recipient
all the time. Now according to your explanation could you advise me pl
On 6/8/2019 10:11 AM, Den1 wrote:
Hello,
I would be really thankful if someone could clarify it, please. It says the
following, "Postfix works as documented in regexp_table(5) and
pcre_table(5), i.e. each query stops at the first matching rule. Now the
following two rules are in conflict:
/^Fro
But if in the message Subject is before From, then the Subject will be
tested before the From header is tested.
The rules process the message, starting from the first header IN THE
MESSAGE, and that gets checked against the rules.
THEN the second header in the message is tested, then the third.
Th
Thank you so much for your input, Richard. Appreciate.
Hmm.. Right, this is the way I understand it too. However, my first rule that
matches the header (from field) is skipped for some reason. Then the second
rule that matches the header (subject field) is applied, not skipped. Now these
two r
I think the sequence (and Wietse can correct me if I am wrong) is that
the first header in the message is taken, and searched to see if any
rule matches, if so, that rule is used. If that header doesn't match any
rule, the next header is gotten and checked against the rules, and so
on. The first he
Thank you for replying but I still do not understand it. Are you saying that I
should swap rules' places? I have already tried that before posting my quesion
but it doesn't help. The matter is that these rules work OK one by one, but
when put together the REPLACE rule is skipped wheather it come
d tbsky:
> Hi:
> I want to filter all the mails send to filter...@example.com. so I
> create configuration at main.cf like below:
>
> smtpd_recipient_restrictions =
>check_recipient_access hash:/etc/postfix/filter_access,
>reject_unknown_sender_domain,
>permit
>
> and create filte
Den1:
> Hello,
>
> I would be really thankful if someone could clarify it, please. It says the
> following, "Postfix works as documented in regexp_table(5) and
> pcre_table(5), i.e. each query stops at the first matching rule. Now the
> following two rules are in conflict:
>
> /^From:\s*assistant
Hello,
I would be really thankful if someone could clarify it, please. It says the
following, "Postfix works as documented in regexp_table(5) and
pcre_table(5), i.e. each query stops at the first matching rule. Now the
following two rules are in conflict:
/^From:\s*assistant\@gmail\.com$/ REPLACE
Hi:
I want to filter all the mails send to filter...@example.com. so I
create configuration at main.cf like below:
smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/filter_access,
reject_unknown_sender_domain,
permit
and create filter_access like below
filter_m
On Sat, Jun 08, 2019 at 11:12:24AM +0200, L. Jankok wrote:
> In my main.cf I have"tls_ssl_options=NO_RENEGOTIATION" but when I use the
> mailserver verification option from https://internet.nl I get the report
> that TLS client-initiated renegotiation is not disabled and that therefore
> my postfi
In my main.cf I have"tls_ssl_options=NO_RENEGOTIATION" but when I use the
mailserver verification option from https://internet.nl I get the report
that TLS client-initiated renegotiation is not disabled and that therefore
my postfix setup is prone to a DOS attack by means of CPU resource
starvation
15 matches
Mail list logo
