Re: Example of postfix's pcre \A \z /A false positive

[sb]

Re: body_checks(5)

> The input string for body_checks is a single message body line.
> so "\A" == "^" and "\z" == "$".

Both /m and /A are compliant with postfix's pcre_table(5). Therefore,
\A and \z *must not* fall back to ^ and $ when using /Am.

Postfix's adaptation of pcre leads to false positives,
as stated in the OP.

> Postfix does not read the entire message into memory.
> That does not scale well.

Yes, this confirms the OP.

I suggest to either allow postfix to read the entire message body, 
except the attachments, or deprecate postfix's /Am altogether.

Re: Deny attachement extension directly in postfix ?

[Nicolás]

El 23/12/15 a las 13:29, Olivier CALVANO escribió:

Hi

it's possible to deny a attachment extension directly into postfix ?

and create a database :

domaine1.com  .exe;.bat;.cab
domaine2.com  .exe

?

thanks for your help
Olivier



Yes, but to do it per destination domain I think you'll need to write an 
own filter. However, if you want to configure it generally for any 
recipient, you should do something like this:


main.cf:
--

mime_header_checks = regexp:/etc/postfix/mime_header_checks

/etc/postfix/mime_header_checks
-

/name=[^>]*\.(com|exe|dll|vbs)/ REJECT Attachment extension not allowed

Reload Postfix and that's it.

In man (5) header_checks you'll also find a more complex example with 
some very useful extensions to block (with the header_checks parameter 
instead of mime_header_checks, though).


Regards,

Nicolás

AW: How to Block EHLO/HELO that has IP Only

[Uwe Drießen]

smtpd_helo_required =   yes

smtpd_recipient_restrictions =
..
reject_invalid_helo_hostname


Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server. 
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045 


> -Ursprüngliche Nachricht-
> Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] Im Auftrag von L. D. James
> Gesendet: Mittwoch, 23. Dezember 2015 09:39
> An: postfix-users@postfix.org
> Betreff: How to Block EHLO/HELO that has IP Only
> 
> I have many log entries where there are "helo=[1.2.3.4]" entries with no
> domain name.  It has an IP address only.  Each of these occasions are
> unwanted spam messages.
> 
> Can some one specify a policy restriction that will block these messages.
> 
> An example from the log is:
> 
> Dec 22 16:00:52 hera5 policyd-spf[9883]: None; identity=mailfrom;
> client-ip=75.211.27.210; helo=[63.205.88.41];
> envelope-from=dtrue-nore...@example.com;
> receiver=u...@example.com
> 
> Thanks in advance for any suggestions on this.
> 
> -- L. James
> 
> --
> L. D. James
> lja...@apollo3.com
> www.apollo3.com/~ljames

Deny attachement extension directly in postfix ?

[Olivier CALVANO]

Hi

it's possible to deny a attachment extension directly into postfix ?

and create a database :

domaine1.com .exe;.bat;.cab
domaine2.com .exe

?

thanks for your help
Olivier

R: R: R: R: smtpd_recipient_restrictions in error

[Nicola Piazzi]

Error was the word reject_unverified_recipients instead of 
reject_unverified_recipient
Sorry





Nicola Piazzi
CED - Sistemi
COMET s.p.a.
Via Michelino, 105 - 40127 Bologna - Italia
Tel.  +39 051.6079.293
Cell. +39 328.21.73.470
Web: www.gruppocomet.it



-Messaggio originale-
Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
Per conto di wilfried.es...@essignetz.de
Inviato: mercoledì 23 dicembre 2015 11:31
A: postfix-users@postfix.org
Oggetto: Re: R: R: R: smtpd_recipient_restrictions in error

Am 23.12.2015 um 09:13 schrieb Nicola Piazzi:
> Do you mean that i must give logging of the problem ?
I think so.

> I don't undestrand if you say that there is a solution and I have done 
> some error in typing
You corrected your misspelling. But now there seems to be another error.

Additionally i'd like to ask you the following:

Which postfix version do you use?

Can you show us the complete "smtpd_recipient_restrictions = ..." part, when it 
failed?


Willi


> Nicola Piazzi
> CED - Sistemi
> COMET s.p.a.
> Via Michelino, 105 - 40127 Bologna - Italia Tel.  +39 051.6079.293 
> Cell. +39 328.21.73.470
> Web: www.gruppocomet.it
> 
> 
> 
> -Messaggio originale-
> Da: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] Per conto di Viktor Dukhovni
> Inviato: mercoledì 23 dicembre 2015 09:00
> A: postfix-users@postfix.org
> Oggetto: Re: R: R: smtpd_recipient_restrictions in error
> 
> On Wed, Dec 23, 2015 at 07:54:22AM +, Nicola Piazzi wrote:
> 
>> At now my "smtpd_recipient_restrictions" is configured to use sqlgrey 
>> and is working :  smtpd_recipient_restrictions = 
>> permit_sasl_authenticated, permit_mynetworks, 
>> reject_unauth_destination, reject_non_fqdn_recipient, 
>> reject_unknown_recipient_domain, check_recipient_access 
>> hash:/etc/postfix/recipient_access, check_policy_service
>> inet:127.0.0.1:2501
>>
>> If I want to verify recipients in exchange I need to put 
>> "reject_unverified_recipient" but it work ONLY if I remove 
>> "check_policy_service" :  smtpd_recipient_restrictions = 
>> permit_sasl_authenticated, permit_mynetworks, 
>> reject_unauth_destination, reject_non_fqdn_recipient, 
>> reject_unknown_recipient_domain, check_recipient_access 
>> hash:/etc/postfix/recipient_access,
>> reject_unverified_recipient
>>
>> Using together "reject_unverified_recipient" and check_policy_service 
>> give error after typing rcpt to
> 
> http://www.postfix.org/DEBUG_README.html#mail
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
> 

RE: How to Block EHLO/HELO that has IP Only

[L . P . H . van Belle]

This is how i run it.  ( postfix 2.11.x on debian Jessie ) 
This stops a lot of "spamming" servers, and if anyone sees improvements,... im 
all ear...  ;-) 
This was a drop op about 90% of all spam, remaining used "good" configured 
servers..  :-/  but for that spamassassin.. 


unknown_hostname_reject_code = 550
unknown_client_reject_code = 550
unknown_address_reject_code = 550
unverified_recipient_reject_code = 550

smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/postfix/overrule/allow_client_access.map,
check_client_access cidr:/etc/postfix/cidr/drop.spamhaus-lasso.cidr,
check_client_access cidr:/etc/postfix/cidr/drop.tor-exitnode-ips.cidr,
check_client_access cidr:/etc/postfix/cidr/drop.bad-networks.cidr,
weightcheck_policy,
spfcheck_policy,
#greycheck_policy,
reject_unauth_destination,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_unauth_pipelining


smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access pcre:/etc/postfix/pcre/helo.pcre
check_helo_access hash:/etc/postfix/overrule/allow_helo_access.map
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_unauth_destination,
reject_unauth_pipelining


In the helo.pcre put all known hostnames and ip your server is using.
## Name based
/^localhost$/   554 Don't use my own hostname
/^localhost\.localdomain$/  554 Don't use my own hostname
/^localhost\.domain\.tld$/   554 Don't use my own hostname
/^ip6-localhost$/   554 Don't use my own hostname
/^domain\.tld$/  554 Don't use my own domainname
/^hostname\.domain\.tld$/  554 Don't use my own hostname
## IP Based
/^127\.0\.0\.1$/554 Don't use my own IP address
/^\[127\.0\.0\.1\]$/554 Don't use my own IP address
/^\:\:1$/   554 Don't use my own IP address
/^\[\:\:1\]$/   554 Don't use my own IP address
/^\1\.2\.3\.4$/ 554 Don't use my own IP address
/^\[1\.2\.3\.4]$/   554 Don't use my own IP address

If you get in trouble with customers..  overrule/allow_helo_access.map 
Put in : (IP OK ) 
1.2.3.4 OK 

smtpd_sender_restrictions = 
permit_mynetworks, 
reject_non_fqdn_sender,
reject_unknown_sender_domain, 
check_sender_mx_access 
cidr:/etc/postfix/cidr/check_sender_mx_access.cidr,
 reject_unauth_pipelining

smtpd_recipient_restrictions = 
permit_mynetworks, 
permit_sasl_authenticated, 
reject_unauth_destination, 
reject_unknown_recipient_domain

smtpd_relay_restrictions = 
permit_mynetworks, 
permit_sasl_authenticated, 
reject_unauth_destination, 
reject_unknown_recipient_domain, 
check_policy_service unix:private/policy-spf

### Before-220 tests (postscreen / DNSBL)
postscreen_access_list  = permit_mynetworks, 
cidr:/etc/postfix/cidr/postscreen_whitelist_access.cidr, 
cidr:/etc/postfix/cidr/postscreen_spamhaus-lasso_access.cidr
postscreen_dnsbl_reply_map  = 
pcre:/etc/postfix/pcre/postscreen_dnsbl_reply_map.pcre
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_threshold  = 4
postscreen_dnsbl_sites =
zen.spamhaus.org*3
b.barracudacentral.org*2
bl.spameatingmonkey.net*2
dnsbl.anonmails.de
dnsbl.kempt.net
dnsbl.inps.de
bl.spamcop.net
dnsbl.sorbs.net
psbl.surriel.com
bl.mailspike.net
swl.spamhaus.org*-4
postscreen_whitelist_interfaces = $mynetworks, static:all



Greetz, 

Louis

> -Oorspronkelijk bericht-
> Van: nico...@devels.es [mailto:owner-postfix-us...@postfix.org] Namens
> Nicolás
> Verzonden: woensdag 23 december 2015 16:10
> Aan: postfix-users@postfix.org
> Onderwerp: Re: How to Block EHLO/HELO that has IP Only
> 
> 
> El 23/12/15 a las 08:38, L. D. James escribió:
> > I have many log entries where there are "helo=[1.2.3.4]" entries with
> > no domain name.  It has an IP address only.  Each of these occasions
> > are unwanted spam messages.
> >
> > Can some one specify a policy restriction that will block these
> messages.
> >
> > An example from the log is:
> >
> > Dec 22 16:00:52 hera5 policyd-spf[9883]: None; identity=mailfrom;
> > client-ip=75.211.27.210; helo=[63.205.88.41];
> > envelope-from=dtrue-nore...@example.com; receiver=u...@example.com
> >
> > Thanks in advance for any suggestions on this.
> >
> > -- L. James
> >
> 
> You can use reject_non_fqdn_helo_hostname in the smtpd_helo_restrictions
> parameter. For example:
> 
> smtpd_helo_restrictions =
>  permit_mynetworks
>  reject_non_fqdn_helo_hostname
>  reject_unknown_helo_hostname
>  permit
> 
> Regards,
> 
> Nicolás

Re: How to Block EHLO/HELO that has IP Only

[Nicolás]

El 23/12/15 a las 08:38, L. D. James escribió:
I have many log entries where there are "helo=[1.2.3.4]" entries with 
no domain name.  It has an IP address only.  Each of these occasions 
are unwanted spam messages.


Can some one specify a policy restriction that will block these messages.

An example from the log is:

Dec 22 16:00:52 hera5 policyd-spf[9883]: None; identity=mailfrom; 
client-ip=75.211.27.210; helo=[63.205.88.41]; 
envelope-from=dtrue-nore...@example.com; receiver=u...@example.com


Thanks in advance for any suggestions on this.

-- L. James



You can use reject_non_fqdn_helo_hostname in the smtpd_helo_restrictions 
parameter. For example:


smtpd_helo_restrictions =
permit_mynetworks
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
permit

Regards,

Nicolás

Re: check_sender_access and pattern matching

[Alex]

Hi,

On Wed, Dec 23, 2015 at 12:53 PM, Bill Cole
 wrote:
> On 21 Dec 2015, at 12:38, Alex wrote:
>
>> Perhaps the ordering of restrictions is not correct?
>>
>> smtpd_client_restrictions = permit_mynetworks,
>>  check_client_access hash:/etc/postfix/client_checks,
>>  check_reverse_client_hostname_access
>> pcre:/etc/postfix/fqrdns-042715a.pcre,
>>  check_reverse_client_hostname_access
>> pcre:/etc/postfix/reverse_client_hostname_access.pcre,
>>  check_client_access cidr:/etc/postfix/client_access_blocklist
>>
>> smtpd_recipient_restrictions = reject_non_fqdn_recipient,
>>  reject_non_fqdn_sender,
>>  reject_unlisted_recipient,
>>  reject_unknown_recipient_domain,
>>  permit_mynetworks,
>>  reject_unauth_destination,
>>  reject_unknown_sender_domain,
>>  reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
>>  reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
>>  reject_rhsbl_helo mykey.dbl.dq.spamhaus.net
>>  check_helo_access pcre:/etc/postfix/helo_checks.pcre,
>>  check_helo_access hash:/etc/postfix/helo_checks,
>>  reject_non_fqdn_helo_hostname,
>>  reject_invalid_helo_hostname,
>>  check_policy_service inet:127.0.0.1:2501,
>>  check_recipient_access pcre:/etc/postfix/relay_recips_access,
>>  permit
>>
>> smtpd_sender_restrictions = permit_mynetworks,
>>  check_sender_access hash:/etc/postfix/sender_checks,
>>  check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf
>>  reject_unknown_sender_domain
>
>
> It does not matter what order the various lists of restrictions have in
> main.cf, they are always evaluated in the same order:
> http://www.postfix.org/SMTPD_ACCESS_README.html#timing
>
> Each restriction list is evaluated independently but a REJECT or DEFER
> result from any list causes later lists to be skipped. Note that
> http://www.postfix.org/SMTPD_ACCESS_README.html#lists does not say OK/PERMIT
> from one list is carried forward to whitelist against restrictions in later
> lists *because it is not.*
>
> Individual restriction rules inside a list are evaluated in order, so the
> above applies your check_sender_access whitelist inside
> smtpd_sender_restrictions, protecting it from the
> reject_unknown_sender_domain in that list. This allows the message to
> proceed and be evaluated by the smtpd_recipient_restrictions list, which has
> its own reject_unknown_sender_domain. You can tell that this is what
> rejected your message by noting the log entry wording:
>
>> Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from
>> mailout.example.com[64.123.123.200]: 450 4.1.8
>> : Sender address rejected: Domain not found;
>> from= to=
>> proto=ESMTP helo=

Okay, I understand. So if the list wasn't also included in
smtpd_sender_restrictions, would it have been rejected there, due to
the reject_unknown_sender_domain at the end?

How can I get around the duplication? One of the reasons I separated
the restrictions was to avoid the problem of too permissive access.

Should I just expect to duplicate the check_*_access using the same
lists to solve this?

If it would be best to combine the restrictions, can you suggest how I
might do that?

Thanks again,
Alex

Re: Blank EHLO/HELO commands

[Bill Cole]

On 21 Dec 2015, at 17:54, Wolfe, Robert wrote:

Hi all.  This is not a postfix-specific question, but rather a generic 
one, but I hope I can get the answer I am searching for here.



I run a third part SMTP filtering program in which I have "EHLO/HELO 
Must Resolve" turned on.  I am amazed at the number of exceptions I 
have to put into my configuration to accept email from domains 
affected by this.  Is this normal practice,


Not normal, but quite common. A substantial number of apparently 
legitimate mail systems introduce themselves as members of the .local or 
.localdomain TLDs or with unqualified or otherwise unresolvable 
hostnames. The first 3 flavors seem to be symptoms of running servers 
that are "so easy any idiot can set one up" (and one did.) Historically 
that mostly meant Exchange, but in recent years MacOS X Server, Zimbra, 
and random "mail appliance" VMs for cloud hosters apparently share the 
problem of being unable to truncate human errors by failing when 
definitively misconfigured.


For Postfix, I've found that rejecting *invalid* HELO names (illegal 
characters, trailing dot, etc) never causes trouble but rarely occurs, 
while rejecting IP literals, bare IPs (not in brackets,) and my own 
names would catch a huge pile of bots, were it not for postscreen 
already catching almost all of them for talking too fast. I also reject 
*.local and *.localdomain and unqualified names EXCEPT for a substantial 
number of exceptions added when I learn that a particular user wants the 
mail from that broken MTA.


That is of course all in regards to SMTP transport (port 25) NOT for 
mail submission (port 587) because the people writing MUAs are a large 
enough set to follow Sturgeon's Law and so it is a small minority of 
port 587 connections that use a resolvable FQDN in EHLO.



or, according to RFCs, is the FQDN _REQUIRED_ to be present in the 
EHLO/HELO verbage during an SMTP session?


Neither RFC5321 nor its predecessor RFC2821 use SHOULD or MUST regarding 
the name used in EHLO/HELO *except* where they also say that a SMTP 
client SHOULD use an IP literal if it doesn't have a meaningful FQDN. 
Note that they also say:


   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.

Of course, RFCs are not laws, they are documentation for the primary 
purpose of interoperability. A rule that "EHLO/HELO Must Resolve" in a 
MTA may not quite violate that MUST NOT, but it comes close and some 
MTAs can be configured to require that the name resolves to the IP of 
the client. That can cause mail from some major mail providers to be 
frequently rejected.

Re: How to Block EHLO/HELO that has IP Only

[L. D. James]

On 12/23/2015 10:10 AM, Nicolás wrote:


El 23/12/15 a las 08:38, L. D. James escribió:
I have many log entries where there are "helo=[1.2.3.4]" entries with 
no domain name.  It has an IP address only.  Each of these occasions 
are unwanted spam messages.


Can some one specify a policy restriction that will block these 
messages.


An example from the log is:

Dec 22 16:00:52 hera5 policyd-spf[9883]: None; identity=mailfrom; 
client-ip=75.211.27.210; helo=[63.205.88.41]; 
envelope-from=dtrue-nore...@example.com; receiver=u...@example.com


Thanks in advance for any suggestions on this.

-- L. James



You can use reject_non_fqdn_helo_hostname in the 
smtpd_helo_restrictions parameter. For example:


smtpd_helo_restrictions =
permit_mynetworks
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
permit

Regards,

Nicolás


@Nicolás, @Uwe Drießen, @Louis

Thanks for all the input.  I see where I was going wrong.  My 
smtpd-helo_restrictions was mistakenly placed in the 
smtpd_recipient_restrictions block.


I see lots of spam control improvements already.  I'll study more in 
detail the suggestions from Louis for his extensive input.


-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames

Bounces and dmarc reports

[Alex]

Hi,

I've recently implemented dmarc on my system. I've implemented both
rua and ruf reports. I'm trying to understand why my postfix queue is
being inundated with undeliverable messages such as these:

E45A5182C7E 2700 Wed Dec 23 11:11:52  postmas...@cheatcodes.com
(connect to mulish.yachtspecialnewtips.info[162.214.5.75]:25: No route to host)
 ab...@yachtspecialnewtips.info

Dec 23 11:11:53 juggernaut postfix/qmgr[14771]: E45A5182C7E:
from=, size=2700,
 nrcpt=2 (queue active)

Dec 23 11:11:53 juggernaut postfix/smtp[10932]: A2733182CA4:
to=, relay=127.0.0.1[127.0.0.1]:10024,
conn_use=10, delay=16, delays=0.18/16/0.01/0.18, dsn=2.0.0,
status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok:
queued as E45A5182C7E)

I don't understand why reports from postmas...@cheatcodes.com are
being received then attempted to be sent to an obvious spam domain.

I suppose this isn't strictly a postfix problem, but I've been unable
to find help elsewhere. I was hoping someone familiar with dmarc could
guide me to the right solution.

Thanks,
Alex

Re: Deny attachement extension directly in postfix ?

[Noel Jones]

On 12/23/2015 7:29 AM, Olivier CALVANO wrote:
> Hi
> 
> it's possible to deny a attachment extension directly into postfix ?

You can block attachment extensions using either header_checks or
mime_header_checks.  There's a nice working example at the end of
the header_checks man page (the example also works with
mime_header_checks).
http://www.postfix.org/header_checks.5.html

header_checks and mime_header_checks rules will apply to all mail
without exception. There is no bypass or whitelist function for
specific domains/recipients/senders/etc.


> 
> and create a database :
> 
> domaine1.com  .exe;.bat;.cab
> domaine2.com  .exe

To perform blocking with exceptions, you'll need a milter,
smtpd_proxy_filter, or content_filter outside of postfix, such as
mimedefang or amavisd-new.



  -- Noel Jones

Re: check_sender_access and pattern matching

[Bill Cole]

On 21 Dec 2015, at 12:38, Alex wrote:


Perhaps the ordering of restrictions is not correct?

smtpd_client_restrictions = permit_mynetworks,
 check_client_access hash:/etc/postfix/client_checks,
 check_reverse_client_hostname_access 
pcre:/etc/postfix/fqrdns-042715a.pcre,

 check_reverse_client_hostname_access
pcre:/etc/postfix/reverse_client_hostname_access.pcre,
 check_client_access cidr:/etc/postfix/client_access_blocklist

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
 reject_non_fqdn_sender,
 reject_unlisted_recipient,
 reject_unknown_recipient_domain,
 permit_mynetworks,
 reject_unauth_destination,
 reject_unknown_sender_domain,
 reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
 reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
 reject_rhsbl_helo mykey.dbl.dq.spamhaus.net
 check_helo_access pcre:/etc/postfix/helo_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 reject_non_fqdn_helo_hostname,
 reject_invalid_helo_hostname,
 check_policy_service inet:127.0.0.1:2501,
 check_recipient_access pcre:/etc/postfix/relay_recips_access,
 permit

smtpd_sender_restrictions = permit_mynetworks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf
 reject_unknown_sender_domain


It does not matter what order the various lists of restrictions have in 
main.cf, they are always evaluated in the same order: 
http://www.postfix.org/SMTPD_ACCESS_README.html#timing


Each restriction list is evaluated independently but a REJECT or DEFER 
result from any list causes later lists to be skipped. Note that 
http://www.postfix.org/SMTPD_ACCESS_README.html#lists does not say 
OK/PERMIT from one list is carried forward to whitelist against 
restrictions in later lists *because it is not.*


Individual restriction rules inside a list are evaluated in order, so 
the above applies your check_sender_access whitelist inside 
smtpd_sender_restrictions, protecting it from the 
reject_unknown_sender_domain in that list. This allows the message to 
proceed and be evaluated by the smtpd_recipient_restrictions list, which 
has its own reject_unknown_sender_domain. You can tell that this is what 
rejected your message by noting the log entry wording:



Dec 21 12:30:16 mail02 postfix/smtpd[1560]: NOQUEUE: reject: RCPT from
mailout.example.com[64.123.123.200]: 450 4.1.8
: Sender address rejected: Domain not found;
from= to=
proto=ESMTP helo=


Strictly speaking, the domain is not "invalid" (containing characters 
not allowed in hostnames or otherwise technically malformed) but simply 
"unknown" (not found in DNS). Presumably it has a dot in it so it's 
nominally fully-qualified.

Re: Example of postfix's pcre \A \z /A false positive

[Bill Cole]

On 23 Dec 2015, at 18:05, Viktor Dukhovni wrote:


On Wed, Dec 23, 2015 at 05:29:12PM -0500, Bill Cole wrote:

The /m modifier may in fact never be useful in a Postfix pcre maps 
and I'm
not sure how one would test for whether it is actually functional. I 
cannot
think of any circumstance where Postfix might want to pass pcre a 
truly

multiline subject string for a map query, but such a case may exist.


Headers are processed one logical (folded) header at a time, and
may contain internal newlines.  Multiline matching is meaningful
in header_checks(5).


Thanks! I've have been operating under the delusion that they were 
"unfolded" and passed as one line.

Re: Example of postfix's pcre \A \z /A false positive

[Bill Cole]

On 23 Dec 2015, at 5:26, sb wrote:


Re: body_checks(5)

> The input string for body_checks is a single message body line.
> so "\A" == "^" and "\z" == "$".

Both /m and /A are compliant with postfix's pcre_table(5). Therefore,
\A and \z *must not* fall back to ^ and $ when using /Am.


That apparent "logic" is not what it is pretending to be.

The fact that the pcre subject string does not actually contain multiple 
lines but rather only contains one line (as documented for body_checks) 
has no effect on how Postfix handles the /A and /m modifiers or the 
logical semantics of the \A and \z anchors.


Viktor's statement was not about Postfix-specific logic but about the 
degeneracy of pcre anchor semantics when operating in multiline mode on 
a single-line subject string. See the pcreapi(3) man page for the full 
details, but in short: subject anchors and line anchors match precisely 
the same way if a subject is exactly one line and isn't marked as being 
a partial line.



Postfix's adaptation of pcre


This is not an "adaptation" it is simply "use." The subject string 
provided to pcre by  body_checks is, AS CLEARLY DOCUMENTED, always 
exactly one raw undecoded body line from the message. The Postfix 
modifiers are documented to set various option flags when calling pcre, 
and they do so.



leads to false positives,
as stated in the OP.


There was no false positive. You expected body_checks to function in a 
way that its documentation clearly and explicitly states it DOES NOT 
function. Instead, body_checks behaved as it is designed and documented 
to behave.



> Postfix does not read the entire message into memory.
> That does not scale well.

Yes, this confirms the OP.

I suggest to either allow postfix to read the entire message body, 
except the attachments,


I hope Dr. Venema does not follow that suggestion. I expect he will not, 
because the lightweight limited functionality of the header and body 
checks internal to Postfix is sufficient for some very simple content 
inspection but is limited in scope to keep Postfix itself from being a 
resource hog or a hiding place for subtle vulnerabilities to crafted 
email input. Keeping the scope of Postfix's internal content inspection 
tightly limited while providing diverse ways to hook into external tools 
has enabled a rich environment for more versatile content filtering 
tools like Amavis and MIMEDefang to flourish.


Also, it seems unwise to ask a MTA to define what constitutes an "entire 
message body, except the attachments" in a world where 
multipart/alternative and multipart/related and message/rfc822 are 
defined types used in real messages. MUAs don't all see "body" vs. 
"attachment" the same way, and we hardly need Yet Another View by a MTA 
that is largely invisible.


Finally: see Postfix's BUILTIN_FILTER_README for why the internal 
filtering functions are so lightweight and limited *by design*.



or deprecate postfix's /Am altogether.


The /A modifier is useful and functional in Postfix pcre maps. I see no 
reason to deprecate it or to change its documentation in the pcre_table 
man page, as it seems perfectly accurate.


The /m modifier may in fact never be useful in a Postfix pcre maps and 
I'm not sure how one would test for whether it is actually functional. I 
cannot think of any circumstance where Postfix might want to pass pcre a 
truly multiline subject string for a map query, but such a case may 
exist. If it does not, perhaps the documentation should make clear that 
setting PCRE_MULTILINE isn't actually useful for its primary effect and 
will only provide whatever subtle semantic side-effects exist in pcre 
when that option is set. Since anyone reading the body_checks man page 
carefully knows the subject string never has embedded newlines, there's 
not really any reason to deprecate /m. It's not dangerous.

Re: Example of postfix's pcre \A \z /A false positive

[Viktor Dukhovni]

On Wed, Dec 23, 2015 at 05:29:12PM -0500, Bill Cole wrote:

> The /m modifier may in fact never be useful in a Postfix pcre maps and I'm
> not sure how one would test for whether it is actually functional. I cannot
> think of any circumstance where Postfix might want to pass pcre a truly
> multiline subject string for a map query, but such a case may exist.

Headers are processed one logical (folded) header at a time, and
may contain internal newlines.  Multiline matching is meaningful
in header_checks(5).

-- 
Viktor.

Re: check_sender_access and pattern matching

[Bill Cole]

On 23 Dec 2015, at 13:53, Alex wrote:

[...]


Okay, I understand. So if the list wasn't also included in
smtpd_sender_restrictions, would it have been rejected there, due to
the reject_unknown_sender_domain at the end?


Yes.


How can I get around the duplication?


If you don't duplicate rejection rules then you don't need to duplicate 
map rules to exempt special cases from them.



One of the reasons I separated
the restrictions was to avoid the problem of too permissive access.


I can see why: if your check_sender_access whitelist is in 
smtpd_recipient_restrictions, it whitelists against every rule following 
it in smtpd_recipient_restrictions, based on an arbitrarily forgeable 
sender domain. Using a magically bogus sender domain would become a free 
relay pass.



Should I just expect to duplicate the check_*_access using the same
lists to solve this?


No. You only need to duplicate whitelisting if you duplicate rejection, 
and there is a risk of opening loopholes if you put whitelisting maps 
for client/helo/sender rejections into smtpd_recipient_restrictions. So: 
remove reject_unknown_sender_domain from smtpd_recipient_restrictions, 
leave smtpd_sender_restrictions intact as-is.


General rule: If you want to use a reject_* rule but also need a 
whitelist exempting special cases from that rule, put the rejection rule 
immediately after its whitelist map in the earliest legal rejection list 
for that rejection rule, as far down as possible.



If it would be best to combine the restrictions, can you suggest how I
might do that?


Don't try to use a single unified restriction list in 
smtpd_recipient_restrictions if you use maps based on client, helo, or 
sender values to exempt specific violators only from reject_* rules that 
apply to the same values. You need to be very careful about using any 
maps that act as whitelists in smtpd_recipient_restrictions; you can 
order rules there to get complexity that can't be set up elsewhere, but 
it is risky.

Re: R: R: R: smtpd_recipient_restrictions in error

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

Am 23.12.2015 um 09:13 schrieb Nicola Piazzi:
> Do you mean that i must give logging of the problem ?
I think so.

> I don't undestrand if you say that there is a solution and I have done some 
> error in typing
You corrected your misspelling. But now there seems to be another error.

Additionally i'd like to ask you the following:

Which postfix version do you use?

Can you show us the complete "smtpd_recipient_restrictions = ..." part,
when it failed?


Willi


> Nicola Piazzi
> CED - Sistemi
> COMET s.p.a.
> Via Michelino, 105 - 40127 Bologna - Italia
> Tel.  +39 051.6079.293
> Cell. +39 328.21.73.470
> Web: www.gruppocomet.it
> 
> 
> 
> -Messaggio originale-
> Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
> Per conto di Viktor Dukhovni
> Inviato: mercoledì 23 dicembre 2015 09:00
> A: postfix-users@postfix.org
> Oggetto: Re: R: R: smtpd_recipient_restrictions in error
> 
> On Wed, Dec 23, 2015 at 07:54:22AM +, Nicola Piazzi wrote:
> 
>> At now my "smtpd_recipient_restrictions" is configured to use sqlgrey 
>> and is working :  smtpd_recipient_restrictions = 
>> permit_sasl_authenticated, permit_mynetworks, 
>> reject_unauth_destination, reject_non_fqdn_recipient, 
>> reject_unknown_recipient_domain, check_recipient_access 
>> hash:/etc/postfix/recipient_access, check_policy_service 
>> inet:127.0.0.1:2501
>>
>> If I want to verify recipients in exchange I need to put 
>> "reject_unverified_recipient" but it work ONLY if I remove 
>> "check_policy_service" :  smtpd_recipient_restrictions = 
>> permit_sasl_authenticated, permit_mynetworks, 
>> reject_unauth_destination, reject_non_fqdn_recipient, 
>> reject_unknown_recipient_domain, check_recipient_access 
>> hash:/etc/postfix/recipient_access,
>> reject_unverified_recipient
>>
>> Using together "reject_unverified_recipient" and check_policy_service 
>> give error after typing rcpt to
> 
> http://www.postfix.org/DEBUG_README.html#mail
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
> 

R: R: R: smtpd_recipient_restrictions in error

[Nicola Piazzi]

Do you mean that i must give logging of the problem ?
I don't undestrand if you say that there is a solution and I have done some 
error in typing


Nicola Piazzi
CED - Sistemi
COMET s.p.a.
Via Michelino, 105 - 40127 Bologna - Italia
Tel.  +39 051.6079.293
Cell. +39 328.21.73.470
Web: www.gruppocomet.it



-Messaggio originale-
Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
Per conto di Viktor Dukhovni
Inviato: mercoledì 23 dicembre 2015 09:00
A: postfix-users@postfix.org
Oggetto: Re: R: R: smtpd_recipient_restrictions in error

On Wed, Dec 23, 2015 at 07:54:22AM +, Nicola Piazzi wrote:

> At now my "smtpd_recipient_restrictions" is configured to use sqlgrey 
> and is working :  smtpd_recipient_restrictions = 
> permit_sasl_authenticated, permit_mynetworks, 
> reject_unauth_destination, reject_non_fqdn_recipient, 
> reject_unknown_recipient_domain, check_recipient_access 
> hash:/etc/postfix/recipient_access, check_policy_service 
> inet:127.0.0.1:2501
> 
> If I want to verify recipients in exchange I need to put 
> "reject_unverified_recipient" but it work ONLY if I remove 
> "check_policy_service" :  smtpd_recipient_restrictions = 
> permit_sasl_authenticated, permit_mynetworks, 
> reject_unauth_destination, reject_non_fqdn_recipient, 
> reject_unknown_recipient_domain, check_recipient_access 
> hash:/etc/postfix/recipient_access,
> reject_unverified_recipient
> 
> Using together "reject_unverified_recipient" and check_policy_service 
> give error after typing rcpt to

http://www.postfix.org/DEBUG_README.html#mail
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

-- 
Viktor.

Re: R: R: smtpd_recipient_restrictions in error

[Viktor Dukhovni]

On Wed, Dec 23, 2015 at 07:54:22AM +, Nicola Piazzi wrote:

> At now my "smtpd_recipient_restrictions" is configured to use sqlgrey and
> is working :  smtpd_recipient_restrictions = permit_sasl_authenticated,
> permit_mynetworks, reject_unauth_destination, reject_non_fqdn_recipient,
> reject_unknown_recipient_domain, check_recipient_access
> hash:/etc/postfix/recipient_access, check_policy_service inet:127.0.0.1:2501
> 
> If I want to verify recipients in exchange I need to put
> "reject_unverified_recipient" but it work ONLY if I remove
> "check_policy_service" :  smtpd_recipient_restrictions =
> permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination,
> reject_non_fqdn_recipient, reject_unknown_recipient_domain,
> check_recipient_access hash:/etc/postfix/recipient_access,
> reject_unverified_recipient
> 
> Using together "reject_unverified_recipient" and check_policy_service give
> error after typing rcpt to

http://www.postfix.org/DEBUG_README.html#mail
http://www.postfix.org/ADDRESS_VERIFICATION_README.html

-- 
Viktor.

How to Block EHLO/HELO that has IP Only

[L. D. James]

I have many log entries where there are "helo=[1.2.3.4]" entries with no 
domain name.  It has an IP address only.  Each of these occasions are 
unwanted spam messages.


Can some one specify a policy restriction that will block these messages.

An example from the log is:

Dec 22 16:00:52 hera5 policyd-spf[9883]: None; identity=mailfrom; 
client-ip=75.211.27.210; helo=[63.205.88.41]; 
envelope-from=dtrue-nore...@example.com; receiver=u...@example.com


Thanks in advance for any suggestions on this.

-- L. James

--
L. D. James
lja...@apollo3.com
www.apollo3.com/~ljames