Re: blocking attachment extensions

[Philip Prindeville]

On Sep 17, 2014, at 3:28 PM, Bill Cole 
 wrote:

> On 16 Sep 2014, at 18:18, Philip Prindeville wrote:
> 
>> MIMEDefang allows you to do all this, plus you can call Perl modules like 
>> File::Type on attachments to figure out if the file has been mistyped (i.e. 
>> the content-type disagrees with what the actual file header and/or file 
>> extension says it is).
> 
> Other reasons to use MD for this:
> 
> 1. It analyzes the MIME structure of messages and interprets header 
> attributes so you don't need to figure out a complex RE to match all of the 
> edge & corner cases of legal MIME headers and don't need to test a complex RE 
> against every logical header.
> 
> 2. Optionally, you can have it unpack zip archives and check the files inside.
> 
> 3. It has robust, mature support for SpamAssassin & a long list of AV tools 
> so you can put lightweight policy enforcement like this (or other conditional 
> diversions) before passing messages to the more demanding deep scanners.

Yup.

I have it intercept Spam, stick it in an ARF wrapper, and deliver it to the 
Drafts folder of the Abuse department…

Good stuff.

Re: Dealing with a lookup with null result?

[Wietse Venema]

CSS:
> I often get confused about the difference between responses from
> a policy check and an access check.  I guess they are basically
> the same.

There is no difference. As documented in SMTPD_POLICY_README:

The policy server replies with any action that is allowed in a
Postfix SMTPD access(5) table. Example:

action=defer_if_permit Service temporarily unavailable
[empty line]

That way, there are fewer things to learn, and less code to maintain.

Wietse

Re: Dealing with a lookup with null result?

[CSS]

On Sep 17, 2014, at 2:19 PM, Wietse Venema  wrote:

>> CSS:
>> Quick question?
>> 
>> I finally decided to build a web UI for our support guys to be
>> able to manually kill relaying for compromised accounts using the
>> new check_sasl_access
>> (http://www.postfix.org/postconf.5.html#check_sasl_access) feature
>> introduced in 2.11.
>> 
>> A thread regarding this is here:
>> http://thread.gmane.org/gmane.mail.postfix.user/245474
>> 
>> So this does work - in my main mail account db table I added a
>> column.  If it's empty, then the user is OK.  If it contains
>> something like 'REJECT 5.7.1 Account Compromised' then that error
>> is returned to the sender, and all is well.
> 
> Postfix does not accept empty responses. If you want to report "not
> found" then that is what the database should respond with. If you
> cannot do that, then return DUNNO for the Postfix access map, and
> return something else human users.

Got it.  Just did a quick test and DUNNO as a response seems to
work.  I manually set my policyd tracking to look like Id sent 8,000
emails in the last 30 minutes and my checks properly went past the
DUNNO and on to the REJECT from the policyd service.  I often get
confused about the difference between responses from a policy check
and an access check.  I guess they are basically the same.

Thanks so much,

Charles

> 
>   Wietse

Re: blocking attachment extensions

[Bill Cole]

On 16 Sep 2014, at 18:18, Philip Prindeville wrote:

MIMEDefang allows you to do all this, plus you can call Perl modules 
like File::Type on attachments to figure out if the file has been 
mistyped (i.e. the content-type disagrees with what the actual file 
header and/or file extension says it is).


Other reasons to use MD for this:

1. It analyzes the MIME structure of messages and interprets header 
attributes so you don't need to figure out a complex RE to match all of 
the edge & corner cases of legal MIME headers and don't need to test a 
complex RE against every logical header.


2. Optionally, you can have it unpack zip archives and check the files 
inside.


3. It has robust, mature support for SpamAssassin & a long list of AV 
tools so you can put lightweight policy enforcement like this (or other 
conditional diversions) before passing messages to the more demanding 
deep scanners.

Re: tlsv1 alert decode error

[Viktor Dukhovni]

On Mon, Sep 15, 2014 at 04:59:15PM +1000, shm...@riseup.net wrote:

> This server is using an EC cert not RSA eventually, The email gets sent
> in the clear any help appreciated.

The above is devoid of any technical content.  No help is possible.

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

> $ openssl s_client -cipher SSLv3 -starttls smtp -connect igwx10.cba.com.au:25
> Protocol  : TLSv1
> Cipher: DHE-RSA-AES256-SHA
> 
> why does it connect with TLS or is this because specifying SSLv3 allows
> anything above SSLv3 ?

Because "cipher SSLv3" is not the same as requiring the SSLv3
protocol, rather it limits the ciphers to those defined in SSLv3,
many of which are also defined with later protocol revisions.

> but openssl gives same result on a different computer
> 
> OpenSSL 1.0.1g 7 Apr 2014
> 
> $ openssl s_client -cipher SSLv3 -starttls smtp -connect igwx10.cba.com.au:25
> CONNECTED(0003)
> 140155330672272:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert decode error:s23_clnt.c:762:

The 1.0.1g client's HELLO message was not sucessfully decoded by
the server.  Perhaps a bug in 1.0.1g.

> postfix/smtp[11167]: initializing the client-side TLS engine
> postfix/smtp[11167]: setting up TLS connection to
> igwx10.cba.com.au[140.168.71.11]:25
> postfix/smtp[11167]: igwx10.cba.com.au[140.168.71.11]:25: TLS cipher list
> "!aNULL:!eNULL:!EXPORT:!MD5:!DES:!SRP:!DSS:!SEED:!ADH:!AECDH:!PSK:!LOW:ALL:@STRENGTH"

Where did this cipherlist come from?  It looks nothing like the
Postfix defaults.  Is this an attempt to work-around interoperability
issues with Exchange 2003 servers?

> postfix/smtp[11167]: warning: TLS library problem: error:1407741A:SSL
> routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:

Why are you asking about SSLv3?

> tls_high_cipherlist   = 
> !aNULL:!eNULL:!EXPORT:!MD5:!DES:!SRP:!DSS:!SEED:!ADH:!AECDH:!PSK:!LOW:ALL:@STRENGTH
> tls_medium_cipherlist = 
> !aNULL:!eNULL:!EXPORT:!MD5:!DES:!SRP:!DSS:!SEED:!ADH:!AECDH:!PSK:!LOW:ALL:@STRENGTH
> tls_low_cipherlist= 
> !aNULL:!eNULL:!EXPORT:!MD5:!DES:!SRP:!DSS:!SEED:!ADH:!AECDH:!PSK:!LOW:ALL:@STRENGTH

You've made high == medium == low.  Why?  The ADH and AECDH ciphers
are a subset of the aNULL ciphers, no need to exclude them "again".

-- 
Viktor.

Re: Dealing with a lookup with null result?

[Wietse Venema]

>CSS:
> Quick question?
>
> I finally decided to build a web UI for our support guys to be
> able to manually kill relaying for compromised accounts using the
> new check_sasl_access
> (http://www.postfix.org/postconf.5.html#check_sasl_access) feature
> introduced in 2.11.
>
> A thread regarding this is here:
> http://thread.gmane.org/gmane.mail.postfix.user/245474
>
> So this does work - in my main mail account db table I added a
> column.  If it's empty, then the user is OK.  If it contains
> something like 'REJECT 5.7.1 Account Compromised' then that error
> is returned to the sender, and all is well.

Postfix does not accept empty responses. If you want to report "not
found" then that is what the database should respond with. If you
cannot do that, then return DUNNO for the Postfix access map, and
return something else human users.

Wietse

Dealing with a lookup with null result?

[CSS]

Quick question…  

I finally decided to build a web UI for our support guys to be able to manually 
kill relaying for compromised accounts using the new check_sasl_access 
(http://www.postfix.org/postconf.5.html#check_sasl_access) feature introduced 
in 2.11. 

A thread regarding this is here: 
http://thread.gmane.org/gmane.mail.postfix.user/245474

So this does work - in my main mail account db table I added a column.  If it’s 
empty, then the user is OK.  If it contains something like “REJECT 5.7.1 
Account Compromised”, then that error is returned to the sender, and all is 
well.

My main.cf checks look like this, with this check coming first:

smtpd_recipient_restrictions =
 check_sasl_access proxy:mysql:$config_directory/sasl-access.cf
 check_policy_service inet:127.0.0.1:10031,  # policyd
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination

sasl-access.cf looks like this:

hosts = 10.88.77.xx 10.88.77.xx
user = 
password = 
dbname = vpopmail
query = SELECT postfix_deny FROM vpopmail WHERE pw_name='%u' AND pw_domain='%d’;

As noted, this functions well, but Postfix does not like the empty answer when 
there’s no match:

Sep 17 12:27:16 smtp1 postfix/proxymap[46006]: warning: table 
"mysql:/usr/local/etc/postfix/sasl-access.cf": empty lookup result for: 
“x...@example.com" — ignored

I briefly considered putting some kind of positive response as the default then 
realized that would short circuit my other checks (I think?).  Is there a value 
I can return that will quell this warning but not allow any sasl-auth’d user to 
relay if the other checks would have blocked them?

Thanks,

Charles

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

[Wietse Venema]

Viktor Dukhovni:
> I gather you're suggesting a chang along the lines of:
> 
> diff --git a/src/smtpstone/smtp-sink.c b/src/smtpstone/smtp-sink.c
> index 617fbf9..33872b0 100644

I came up with similar code. It works without surprises.

Wietse

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

[Viktor Dukhovni]

On Wed, Sep 17, 2014 at 06:48:28PM +0200, Mark Martinec wrote:

> Was investigating why I can't connect to my smtp-sink:
> 
> $ smtp-sink -v [::1]:10055 10
> smtp-sink: name_mask: all
> smtp-sink: trying... [::1]:10055
> 
>   then in another window: $ smtp-source [::1]:10055
> 
>   and the smtp-sink aborts with:
> 
> smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name
> resolution
> 
> 
> Turns out that the problem is a structure declared too short
> by two bytes to receive a sockaddr_in6 from accept(),
> and the two bytes of a received IP address are then clobbered.
> 
> In smtp-sink.c/connect_event() the sa is declared
> as struct sockaddr instead of struct sockaddr_storage
> (RFC 3493).
> 
> Seems like elsewhere this is handled correctly
> ( like in inet_listen.c/inet_accept() ).

I gather you're suggesting a chang along the lines of:

diff --git a/src/smtpstone/smtp-sink.c b/src/smtpstone/smtp-sink.c
index 617fbf9..33872b0 100644
--- a/src/smtpstone/smtp-sink.c
+++ b/src/smtpstone/smtp-sink.c
@@ -1298,31 +1298,32 @@ static void disconnect(SINK_STATE *state)
 
 static void connect_event(int unused_event, char *unused_context)
 {
-struct sockaddr sa;
-SOCKADDR_SIZE len = sizeof(sa);
+struct sockaddr_storage ss;
+struct sockaddr *sa = (struct sockaddr *)&ss;
+SOCKADDR_SIZE salen = sizeof(ss);
 SINK_STATE *state;
 int fd;
 
-if ((fd = sane_accept(sock, &sa, &len)) >= 0) {
+if ((fd = sane_accept(sock, sa, &salen)) >= 0) {
/* Safety: limit the number of open sockets and capture files. */
if (++client_count == max_client_count)
event_disable_readwrite(sock);
state = (SINK_STATE *) mymalloc(sizeof(*state));
-   if (strchr((char *) proto_info->sa_family_list, sa.sa_family))
-   SOCKADDR_TO_HOSTADDR(&sa, len, &state->client_addr,
-(MAI_SERVPORT_STR *) 0, sa.sa_family);
+   if (strchr((char *) proto_info->sa_family_list, sa->sa_family))
+   SOCKADDR_TO_HOSTADDR(sa, salen, &state->client_addr,
+(MAI_SERVPORT_STR *) 0, sa->sa_family);
else
strncpy(state->client_addr.buf, "local", sizeof("local"));
if (msg_verbose)
msg_info("connect (%s %s)",
 #ifdef AF_LOCAL
-sa.sa_family == AF_LOCAL ? "AF_LOCAL" :
+sa->sa_family == AF_LOCAL ? "AF_LOCAL" :
 #else
-sa.sa_family == AF_UNIX ? "AF_UNIX" :
+sa->sa_family == AF_UNIX ? "AF_UNIX" :
 #endif
-sa.sa_family == AF_INET ? "AF_INET" :
+sa->sa_family == AF_INET ? "AF_INET" :
 #ifdef AF_INET6
-sa.sa_family == AF_INET6 ? "AF_INET6" :
+sa->sa_family == AF_INET6 ? "AF_INET6" :
 #endif
 "unknown protocol family",
 state->client_addr.buf);
@@ -1340,7 +1341,7 @@ static void connect_event(int unused_event, char 
*unused_context)
state->delayed_args = 0;
/* Initialize file capture attributes. */
 #ifdef AF_INET6
-   if (sa.sa_family == AF_INET6)
+   if (sa->sa_family == AF_INET6)
state->addr_prefix = "ipv6:";
else
 #endif

-- 
Viktor.

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

[Wietse Venema]

Mark Martinec:
> Turns out that the problem is a structure declared too short
> by two bytes to receive a sockaddr_in6 from accept(),
> and the two bytes of a received IP address are then clobbered.
> 
> In smtp-sink.c/connect_event() the sa is declared
> as struct sockaddr instead of struct sockaddr_storage
> (RFC 3493).

Thanks. What took you so long?  :-)

The accept() calls in test programs must have escaped attention
when Postfix 2.2 was ported to IPv6 (a similar call exists in the
qmqp-sink test program).

All other accept() calls are handled by the Postfix library, which
has been IPv6 compatible for the past 10 years.

Wietse

smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

[Mark Martinec]

Was investigating why I can't connect to my smtp-sink:

$ smtp-sink -v [::1]:10055 10
smtp-sink: name_mask: all
smtp-sink: trying... [::1]:10055

  then in another window: $ smtp-source [::1]:10055

  and the smtp-sink aborts with:

smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name 
resolution



Turns out that the problem is a structure declared too short
by two bytes to receive a sockaddr_in6 from accept(),
and the two bytes of a received IP address are then clobbered.

In smtp-sink.c/connect_event() the sa is declared
as struct sockaddr instead of struct sockaddr_storage
(RFC 3493).

Seems like elsewhere this is handled correctly
( like in inet_listen.c/inet_accept() ).

  Mark

Re: different transport for all mail introduced via sendmail(1)

[btb]

On 2014.09.10 14.02, wie...@porcupine.org (Wietse Venema) wrote:
> btb:
>> hi-
>>
>> i have a mail submission server [submission/587 only] [msa.example.com]
>> for our users [config below].  in that context, it's working as desired.
>>we also have another, separate, msa [msa.systems.example.com], which
>> servers and other infrastructure devices use for submitting mail.  how
>> can i configure postfix so that all mail introduced via sendmail(1) on
>> msa.example.com [regardless of envelope sender/recipient, etc] is
>> delivered directly to msa.systems.example.com:submission,
> 
> /etc/postfix/master.cf:
>  pickup ..   ..   ..   ..   ..   ..   ..   ..  pickup
>   -o filter=smtp_pickup:a.systems.example.com:submission
>  smtp_pickup ..  ..   ..   ..   ..   ..   ..   ..  smtp
>   -o 
> smtp_sender_dependent_authentication=$smtp_pickup_sender_dependent_authentication
>   -o smtp_sasl_password_maps=$smtp_pickup_sasl_password_maps
> 
>> and smtp auth is performed with the necessary credentials,
> 
> Perhaps you mean sender-dependent credentials?
> 
> /etc.postfix/master.cf:
>  smtp_pickup_sender_dependent_authentication = yes
>  smtp_pickup_sasl_password_maps = hash:/etc/postfix/smtp_pickup_sasl_pass

here's what i ended up with [i think -o filter=... was meant to be -o 
content_filter=... ? - and in this case, it's just a single set of credentials]:

main.cf:
null_client_syslog_name = postfix/null_client
null_client_content_filter = 
smtp-nullclient:[msa.systems.${mydomain}]:submission
null_client_sasl_auth_enable = yes
null_client_sasl_tls_security_options = noanonymous
null_client_sasl_password_maps = 
hash:${table_directory}/null_client_smtp_auth_creds

master.cf:
pickupunix  n   -   -   60  1   pickup
-o content_filter=${null_client_content_filter}

smtp-nullclientunix  -   -   -   -   10   smtp
-o syslog_name=${null_client_syslog_name}
-o smtp_sasl_auth_enable=${null_client_sasl_auth_enable}
-o 
smtp_sasl_tls_security_options=${null_client_sasl_tls_security_options}
-o smtp_sasl_password_maps=${null_client_sasl_password_maps}

this seems to be working well, thanks.

-ben

Re: Reverse DNS Failure Code

[Viktor Dukhovni]

On Wed, Sep 17, 2014 at 03:09:15PM +0200, Patrick Ben Koetter wrote:

> > Thanks for keeping an eye on this. Yes, I suppose that Postfix
> > should adopt such status codes (make them configurable?), but there
> > is no need to do this for older releases.
> 
> Having them configurable with sane defaults would be nice for those who want
> to run their own status policy. I don't know how many do and if its worth the
> effort.

I would not make the code configurable, that just invites creative
abuse.  There is no need to rush aut and retrofit legacy software,
brand new codes will take a long time to be understood by MUAs.

Just updating 2.12 is sufficient.

-- 
Viktor.

Re: Reverse DNS Failure Code

[Patrick Ben Koetter]

* Wietse Venema :
> Patrick Ben Koetter:
> > There's an RFC for "Email Authentication Status Codes"
> >  out, which specifies a 
> > dedicated
> > status code "when an SMTP client's IP address failed a reverse DNS 
> > validation
> > check, contrary to local policy requirements" (see: 3.3.  Reverse DNS 
> > Failure
> > Code):
> > 
> > 3.3.  Reverse DNS Failure Code
> > 
> >   Code:   X.7.25
> >   Sample Text:Reverse DNS validation failed
> >   Associated basic status code:  550
> >   Description:This status code is returned when an SMTP
> >   client's IP address failed a reverse DNS
> >   validation check, contrary to local policy
> >   requirements.
> >   Reference:  [RFC7372]; Section 3 of [RFC7001]
> >   Submitter:  M. Kucherawy
> >   Change controller:  IESG
> > 
> > Should Postfix send that code when reject_unknown_reverse_client_hostname is
> > in place?
> 
> Thanks for keeping an eye on this. Yes, I suppose that Postfix
> should adopt such status codes (make them configurable?), but there
> is no need to do this for older releases.

Having them configurable with sane defaults would be nice for those who want
to run their own status policy. I don't know how many do and if its worth the
effort.

p@rick

-- 
[*] sys4 AG
 
https://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: Reverse DNS Failure Code

[Wietse Venema]

Patrick Ben Koetter:
> There's an RFC for "Email Authentication Status Codes"
>  out, which specifies a dedicated
> status code "when an SMTP client's IP address failed a reverse DNS validation
> check, contrary to local policy requirements" (see: 3.3.  Reverse DNS Failure
> Code):
> 
> 3.3.  Reverse DNS Failure Code
> 
>   Code:   X.7.25
>   Sample Text:Reverse DNS validation failed
>   Associated basic status code:  550
>   Description:This status code is returned when an SMTP
>   client's IP address failed a reverse DNS
>   validation check, contrary to local policy
>   requirements.
>   Reference:  [RFC7372]; Section 3 of [RFC7001]
>   Submitter:  M. Kucherawy
>   Change controller:  IESG
> 
> Should Postfix send that code when reject_unknown_reverse_client_hostname is
> in place?

Thanks for keeping an eye on this. Yes, I suppose that Postfix
should adopt such status codes (make them configurable?), but there
is no need to do this for older releases.

Wietse

Re: FYI: blocking attachment extensions

[li...@rhsoft.net]

Am 17.09.2014 um 13:20 schrieb Wietse Venema:
> li...@rhsoft.net:
>> /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1"
> 
> - What is $1 supposed to contain?

in fact the attachment name in the log as well
as in the REJET response (Thunderbird dialog)

excerpt from the logs
5.7.1 554 Attachment Blocked "test.exe.txt.sh"
5.7.1 554 Attachment Blocked "bla test.com"
5.7.1 554 Attachment Blocked "bla .com.pif test.pif"

> - Use "REJECT" or "554", not both

OK

Re: postscreen deep protocol tests and Amazon timeouts

[Wietse Venema]

Jose Borges Ferreira:
> On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema  wrote:
> > When you follow the include: directives you get lists of net/mask
> > forms that are easy to convert to postscreen.
> >
> > $ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{
> > s/^ip.:\(.*\)/\1 permit/
> > p
> > }' | sort -u
> >
> > I thought there would be a nice script that converts SPF net/mask
> > lists to postscreen access lists but I could not quickly find one.
> >
> I also searched and found none.
> 
> Usually I use https://dmarcian.com/spf-survey/amazon.com ( see last
> section : Record flattening ) for manual lookups.
> It's also nice because it shows record errors and warning  like
> invalid ( or not so valid ) CIDR blocks or too many DNS lookups (
> https://dmarcian.com/spf-survey/tam.com.br )

I'm working on a Perl script that parses relevant parts of SPF
syntax, and that's about 80% done.

Wietse 

Re: FYI: blocking attachment extensions

[Wietse Venema]

li...@rhsoft.net:
> /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1"

- What is $1 supposed to contain?

- Use "REJECT" or "554", not both.

Wietse

Re: can check_helo_access go in smtpd_helo_restrictions?

[Robert Schetterer]

Am 17.09.2014 um 12:17 schrieb LuKreme:
> Subject kind of says it all, can you put check_helo_access in the 
> smtpd_helo_restrictions block or does it need to be in 
> smtp_recipient_restrictions?
> 

i have

smtpd_helo_restrictions = permit_mynetworks,
  permit_sasl_authenticated,
  ...
  ...
 reject_invalid_hostname,
  reject_non_fqdn_hostname,
  check_helo_access hash:/etc/postfix/helo_access,
  reject_unauth_pipelining


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: can check_helo_access go in smtpd_helo_restrictions?

[li...@rhsoft.net]

Am 17.09.2014 um 12:17 schrieb LuKreme:
> Subject kind of says it all, can you put check_helo_access in the 
> smtpd_helo_restrictions block or does it need to be in 
> smtp_recipient_restrictions?

yes, it's indicated by the name but anyways:
http://www.postfix.org/postconf.5.html#smtpd_delay_reject


inbound only MTA:

smtpd_helo_restrictions =
 check_helo_access proxy:regexp:/etc/postfix/blacklist_helo.cf
 check_sender_access proxy:hash:/etc/postfix/whitelist_sender.cf
 reject_non_fqdn_helo_hostname
 reject_invalid_helo_hostname

[root@mail-gw:~]$ cat maillog | grep "Unacceptable HELO" | wc -l
45

helo=
helo=
helo=
...

can check_helo_access go in smtpd_helo_restrictions?

[LuKreme]

Subject kind of says it all, can you put check_helo_access in the 
smtpd_helo_restrictions block or does it need to be in 
smtp_recipient_restrictions?

-- 
Good old Dame Fortune. You can _depend_ on her.

Re: current best practice on the usage of the reject_unknown_hostname

[LuKreme]

On 16 Sep 2014, at 17:59 , Bill Cole 
 wrote:
> It is much safer to use 'reject_invalid_helo_hostname' or 
> 'reject_non_fqdn_helo_hostname' or for maximal safety to use a 
> 'check_helo_access' map to specifically reject HELO names & patterns that 
> fingerprint spambots (e.g. 'friend', 'ylmf-pc', '[127.0.0.1]', your own local 
> names/IPs, etc.) or gross incompetence (unqualified names, *.local, etc.) and 
> perhaps to exempt special cases where you are willing to tolerate 
> incompetence.

I suspect a lot of people get reject_invalid_helo_hostname and 
reject_unknown_helo_hostname confused.

I think you can always add the following and then look at your logs:

warn_if_reject reject_unknown_helo_hostname

I used to have a helo check, but no longer use it:

$ cat helo_checks.pcre 
/(unknown|localhost|localdomain|lan|home|example|local)$/ REJECT Mailserver 
name in private namespace
/kreme\.com$/ REJECT helo Don't spoof my hostname 
#several more like that for various domains.
/(\d{1,3}[.-]){3}[.-]\d{1,3}/ WARN Too many numbers in your HELO/EHLO (D)
/([[:digit:]]{1,3}[.-]){3}[[:digit:]]{1,3}/ WARN Too many numbers in HELO/EHLO 
(dig)
/\.(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic . servers not 
allowed
/^(dsl|adsl|pool|dynamic|user|hsd|dyn|dial)/ REJECT helo Dynamic ^ servers not 
allowed
/home\.com$/ REJECT home.com is poisoned


-- 
I'll have what the gentleman on the floor is having.

Re: current best practice on the usage of the reject_unknown_hostname

[li...@rhsoft.net]

Am 17.09.2014 um 11:37 schrieb AndreaML:
> On Tuesday 16 September 2014 23:33:43 li...@rhsoft.net wrote:
>>
>> that still too much mail admins sadly don't care about 3 things
>>
>> * A record
>> * PTR
>> * HELO name
>>
>> and instead "reject_unknown_hostname" you need for a sane sleep
>> specific rules to at least reject insane HELO :-(
> 
> thank you for your reply and the configuration excerpt.
> 
> After reading yours and Bill Cole replies, i am now inclined to remove the 
> hard check on the HELO dns resolvability favoring the "soft" check 
> 
> I am just contended between two approach.
> 
> The first is maintaining the restriction, prepending with a whitelist lookup 
> table populated in semi-automatic manner with a phase analyzing the logs to 
> identify the unresolvable unique helos that need to be whitelisted.
> 
> Or the second is converting the hard check to a soft one like yours with a 
> table to reject clearly bogus names, that needs me to check not the smtp logs 
> but the antismap/antivirus logs and then the headers of the actual messages 
> to 
> build the table.
> 
> I am referring to your (our) mail administrators wisdom and experience. what 
> is your opinion on these approaches?

i prefer in general soft rules and scoring when possible

thats why i only listed things like "ends with .localhost" and
some pretty clear ISP client HELO made it through SA and can
never be a legit mailserver

unconditional rules leads in complaints if they are really
catch a relevant amount or are meaningless because they
anyways don't really help

what i have in all rule sets is a sender-based whitelist
table to even override a hand picked hard blocking rule

the same for PTR checks where i try to get rid of most dynamic
clients not catched by DUL RBL's starting with a lot of DUNNO
rules if something smells like it could be a mailserver "out",
"mail", "gateway" since admins are too creative and/or careless
by naming their machines and ISP's not clear in naming their
enduser ranges PTR's

the intention is to block clear junk before it passes to
SpamAssassin because SA scales not that much if there
starts again a spam-wave like a few months ago with
50 rejected messages per day :-(

Re: current best practice on the usage of the reject_unknown_hostname

[AndreaML]

On Wednesday 17 September 2014 00:31:48 LuKreme wrote:
> On 16 Sep 2014, at 15:24 , AndreaML  wrote:
> > Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT from
> > wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 :
> > Helo command rejected: Host not found; from=
> > to= proto=ESMTP helo=
> > 
> > for a transaction of a prefectly valid test email i sent to myself.
> 
> Since your helo name does not exist, this is correct.
> 
> I see very few rejections (relatively speaking) for non-existing domains or
> hosts. They are, definitionally, invalid emails. I haven’t looked closely,
> but I haven’t had anyone complain in quite a long time about missing mail.
> 
> The there most recent are:
> 
> 1E.bnsfd.com
> Nyt.pilisofe.com
> friendswhatitappears.in

you are free to be skeptic :) i have some from the ministry of justice 
(giustizia.it) ad some from the government authority on the comminication 
systems (agcom.it):

Sep 16 21:14:56 server1 postfix/smtpd[609]: NOQUEUE: reject: RCPT from 
93-63-160-217.ip28.fastwebnet.it[93.63.160.217]: 450 4.7.1 
: Helo command rejected: Host not found; 
from= to= proto=SMTP helo=

I see two cases, more probably there is something that i don't know or, more 
creeply, the quality of mail system administrator is dramatically lowering.

I don't know wich one frightens me the most. :)


-Andrea-


-A-

Re: current best practice on the usage of the reject_unknown_hostname

[AndreaML]

On Tuesday 16 September 2014 23:33:43 li...@rhsoft.net wrote:
> 
> that still too much mail admins sadly don't care about 3 things
> 
> * A record
> * PTR
> * HELO name
> 
> and instead "reject_unknown_hostname" you need for a sane sleep
> specific rules to at least reject insane HELO :-(
> 

thank you for your reply and the configuration excerpt.

After reading yours and Bill Cole replies, i am now inclined to remove the 
hard check on the HELO dns resolvability favoring the "soft" check 

I am just contended between two approach.

The first is maintaining the restriction, prepending with a whitelist lookup 
table populated in semi-automatic manner with a phase analyzing the logs to 
identify the unresolvable unique helos that need to be whitelisted.

Or the second is converting the hard check to a soft one like yours with a 
table to reject clearly bogus names, that needs me to check not the smtp logs 
but the antismap/antivirus logs and then the headers of the actual messages to 
build the table.

I am referring to your (our) mail administrators wisdom and experience. what 
is your opinion on these approaches?

-Andrea-

Re: FYI: blocking attachment extensions

[li...@rhsoft.net]

Am 17.09.2014 um 11:28 schrieb Christian Rößner:
> Am 17.09.2014 um 10:02 schrieb Christian Rößner 
> :
> 
>> /x   REJECT blocked filename ${1}
> 
> Missing indention here. Got it. Thanks

i attached once again my final (appearing to work)
config file - may somebody review if there was no
harm by copy&paste from mail / remove comments

thanks!
# Reject Attachment Extensions

/^Content-(?:Disposition|Type):(?:.*?;)? \s*(?:file)?name \s* = 
\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x
 REJECT 554 Attachment Blocked "$1"

Re: FYI: blocking attachment extensions

[Christian Rößner]

Am 17.09.2014 um 10:02 schrieb Christian Rößner 
:

> /xREJECT blocked filename ${1}

Missing indention here. Got it. Thanks

Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature

Reverse DNS Failure Code

[Patrick Ben Koetter]

There's an RFC for "Email Authentication Status Codes"
 out, which specifies a dedicated
status code "when an SMTP client's IP address failed a reverse DNS validation
check, contrary to local policy requirements" (see: 3.3.  Reverse DNS Failure
Code):

3.3.  Reverse DNS Failure Code

  Code:   X.7.25
  Sample Text:Reverse DNS validation failed
  Associated basic status code:  550
  Description:This status code is returned when an SMTP
  client's IP address failed a reverse DNS
  validation check, contrary to local policy
  requirements.
  Reference:  [RFC7372]; Section 3 of [RFC7001]
  Submitter:  M. Kucherawy
  Change controller:  IESG

Should Postfix send that code when reject_unknown_reverse_client_hostname is
in place?

p@rick


-- 
[*] sys4 AG
 
https://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: postscreen deep protocol tests and Amazon timeouts

[Jose Borges Ferreira]

On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema  wrote:
> When you follow the include: directives you get lists of net/mask
> forms that are easy to convert to postscreen.
>
> $ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{
> s/^ip.:\(.*\)/\1 permit/
> p
> }' | sort -u
>
> I thought there would be a nice script that converts SPF net/mask
> lists to postscreen access lists but I could not quickly find one.
>
I also searched and found none.

Usually I use https://dmarcian.com/spf-survey/amazon.com ( see last
section : Record flattening ) for manual lookups.
It's also nice because it shows record errors and warning  like
invalid ( or not so valid ) CIDR blocks or too many DNS lookups (
https://dmarcian.com/spf-survey/tam.com.br )

José Borges Ferreira

Re: FYI: blocking attachment extensions

[Christian Rößner]

Am 16.09.2014 um 21:42 schrieb Viktor Dukhovni :

> On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
> 
>>># block windows executables PCRE
>>>/^\s*Content-(?:Disposition|Type):   # Header label
>>>  (?:.*?;)? \s*  # Any prior attributes
>>>  (?:file)?name\s*=\s*"? # name or filename
>>>   ( # Capture name for response
>>>  .*?(\.|=2E)# File basename and "."
>>> (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
>>>  inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
>>>  ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
>>>  vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)# Capture risky extensions
>>>   ) # Close capture
>>>   (?:\?=)?  # Trailer of ad-hoc RFC 2047 
>>> encoding
>>>   "?# Optional close quote
>>>   \s*(;|$)  # End of attribute or header
>>> /x
>>> 
>>> [ untested ]
>> 
>> thanks!
>> 
>> interesting - none of both blocking a empty textfile renamed to "test.exe"
>> i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA)
> 
> That's because Postfix does not support in-line comments in PCRE
> patterns.  The multi-line pattern is unfolded first, and the first
> comment gobbles up all the remaining text.  If you strip all the
> comments:
> 
>$ postmap -q 'Content-Type: name="test.exe.txt"; charset=us-ascii' 
> pcre:/tmp/foo.pcre
>$ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii' 
> pcre:/tmp/foo.pcre
>REJECT blocked filename test.exe
> 
> With /tmp/foo.pcre containing:
> 
> # block windows executables PCRE
> /^Content-(?:Disposition|Type):
>  (?:.*?;)? \s*
>  (?:file)?name \s* = \s*"?
>   (
>   .*?(\.|=2E)
> (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
>  inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
>  ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
>  vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)
>   )
>   (?:\?=)?
>   "?
>   \s*(;|$)
> /xREJECT blocked filename ${1}
> 
> -- 
>   Viktor.

I just wanted to give this a try, but it seems I have done something wrong. I 
copied the comment-free version to a pcre-table-file and gave it a try, but 
Postfix now tells me this in the logs:

postconf -c $PWD mime_header_checks
mime_header_checks = pcre:${map}/mime_header_checks.pcre
Sep 17 09:51:15 mx postfix-submission/cleanup[23573]: warning: pcre map 
/etc/postfix-submission/maps/mime_header_checks.pcre, line 14: no closing 
regexp delimiter "/": ignoring this rule
Sep 17 09:51:15 mx postfix-submission/cleanup[23573]: warning: pcre map 
/etc/postfix-submission/maps/mime_header_checks.pcre, line 16: no closing 
regexp delimiter "/": ignoring this rule

postconf -c $PWD mime_header_checks
mime_header_checks = pcre:${map}/mime_header_checks.pcre

cat maps/mime_header_checks.pcre
# block windows executables PCRE
/^Content-(?:Disposition|Type):
 (?:.*?;)? \s*
 (?:file)?name \s* = \s*"?
  (
  .*?(\.|=2E)
(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
 inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
 ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
 vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)
  )
  (?:\?=)?
  "?
  \s*(;|$)
/x  REJECT blocked filename ${1}

Or do I have to make this all become one line?

It’s on Postfix 2.12_pre20140907

Kind regards

Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com



smime.p7s
Description: S/MIME cryptographic signature