SV: SSL Certificates

[Sebastian Nielsen]

No. That Email copuldn't been authenticated In Gmail jargong, means you have to 
set up SPF, DKIM and DMARC records.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Henry
Skickat: den 15 februari 2017 08:10
Till: postfix-users@postfix.org
Ämne: SSL Certificates

When I send a message to Gmail I am informed that it could not be authenticated 
and will probably end in the spam folder. I understand the resolution to this 
is to obtain an SSL certificate and configure postfix to use that certificate.

I have obtained a certificate from LetsEncrypt which is working well with 
Apache. I have tried to update my main.cf file to use this certificate however 
I am now unable to send email. I am following this
post:
https://community.letsencrypt.org/t/using-lets-encrypt-certs-with-postfix/18957

Another guide suggests I can check the config using sslscan which outputs:
sslscan --starttls --no-failed localhost:587
   _
   ___ ___| |___  ___ __ _ _ __
  / __/ __| / __|/ __/ _` | '_ \
  \__ \__ \ \__ \ (_| (_| | | | |
  |___/___/_|___/\___\__,_|_| |_|

  Version 1.8.2
 http://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009

Testing SSL server localhost on port 587

  Supported Server Cipher(s):
ERROR: The SMTP service on localhost port 587 did not appear to support 
STARTTLS.


My main.cf file is as follows:

cat /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first # line of that 
file to be used as the name.  The Debian default # is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings 
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
#smtpd_use_tls=yes
#smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
#smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # 
information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination myhostname = hermes.mydomain.local alias_maps = 
hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname 
mydestination = ldap:/etc/postfix/ldap/mydestination.cf
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 mailbox_command = 
procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_tls_auth_only = yes
transport_maps = ldap:/etc/postfix/ldap/transport_maps.cf,
hash:/etc/postfix/transport
content_filter = smtp-amavis:[127.0.0.1]:10024 smtpd_sender_login_maps = 
$local_recipient_maps local_recipient_maps = 
ldap:/etc/postfix/ldap/local_recipient_maps.cf
virtual_alias_maps = $alias_maps,
ldap:/etc/postfix/ldap/virtual_alias_maps.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_mailforwarding.cf,
ldap:/etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf,
ldap:/etc/postfix/ldap/mailenabled_distgroups.cf,
ldap:/etc/postfix/ldap/mailenabled_dynamic_distgroups.cf
submission_sender_restrictions = reject_non_fqdn_sender, check_policy_service 
unix:private/submission_policy, permit_sasl_authenticated, reject 
submission_recipient_restrictions = check_policy_service 
unix:private/submission_policy, permit_sasl_authenticated, reject 
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_pipelining, 
reject_rbl_client zen.spamhaus.org, reject_non_fqdn_recipient, 
reject_invalid_helo_hostname, reject_unknown_recipient_domain, 
reject_unauth_destination, check_policy_service 
unix:private/recipient_policy_incoming, permit smtp_tls_security_level = may 
smtpd_data_restrictions = permit_mynetworks, check_policy_service 
unix:private/recipient_policy_incoming
submission_data_restrictions = check_policy_service 
unix:private/submission_policy smtpd_tls_security_level = may 
smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = permit_mynetworks, 
reject_sender_login_mismatch, check_policy_service 
unix:private/sender_policy_incoming


# logging
smtpd_tls_loglevel = 1

# Allow use of TLS but make it optional
smtp_use_tls=yes

# Disable SSLv2/3 as they are vulnerable smtpd_tls_protocols = !SSLv2, !SSLv3 
smtp_tls_protocols = !SSLv2, !SSLv3

# Insist on stronger ciphers
smtpd_tls_ciphers = high
smtp_tls_ciphers = high

# keys
smtp_tls_cert_file = /etc/letsencrypt/live/mail.mydomain.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.mydomain.com/privkey.pem


I am unsure of how to figure the fact that the certificate is for 

Re: Why no List-ID header in the postfix-users posts?

[Sebastian Nielsen]

Theres no relay between me and postfix. And this is the report:

Feedback-Type: auth-failure
Version: 1
User-Agent: OpenDMARC-Filter/1.3.2
Auth-Failure: dmarc
Authentication-Results: mx01.nausch.org; dmarc=fail header.from=sebbe.eu
Original-Envelope-Id: 68ED4C00088
Original-Mail-From: owner-postfix-us...@postfix.org
Source-IP: 168.100.1.3 (camomile.cloud9.net)
Reported-Domain: sebbe.eu

-
And original mail:
-
Authentication-Results: mx1.nausch.org;
dkim=pass (1024-bit key) header.d=sebbe.eu header.i=@sebbe.eu 
header.b="AnBtXcH6"
Authentication-Results: mx01.nausch.org; spf=none 
smtp.mailfrom=<owner-postfix-us...@postfix.org> smtp.helo=camomile.cloud9.net
Received: by camomile.cloud9.net (Postfix)
id 7474A336498; Sat, 11 Feb 2017 20:55:58 -0500 (EST)
Delivered-To: postfix-users-outgo...@cloud9.net
Received: from localhost (localhost [127.0.0.1])
by camomile.cloud9.net (Postfix) with ESMTP id 728E83310A6
for <postfix-users-outgo...@cloud9.net>; Sat, 11 Feb 2017 20:55:58 
-0500 (EST)
X-Virus-Scanned: amavisd-new at cloud9.net
Received: from camomile.cloud9.net ([127.0.0.1])
by localhost (camomile.cloud9.net [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id wFb_dh5o0Qze for <postfix-users-outgo...@cloud9.net>;
Sat, 11 Feb 2017 20:55:58 -0500 (EST)
Received: by camomile.cloud9.net (Postfix, from userid 54)
id 50BF13364A0; Sat, 11 Feb 2017 20:55:58 -0500 (EST)
Delivered-To: postfix-us...@cloud9.net
Received: from localhost (localhost [127.0.0.1])
by camomile.cloud9.net (Postfix) with ESMTP id 328E4336498
for <postfix-us...@cloud9.net>; Sat, 11 Feb 2017 20:55:58 -0500 (EST)
X-Virus-Scanned: amavisd-new at cloud9.net
Received: from camomile.cloud9.net ([127.0.0.1])
by localhost (camomile.cloud9.net [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id eeHrKBrRbl4U for <postfix-us...@cloud9.net>;
Sat, 11 Feb 2017 20:55:58 -0500 (EST)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [185.86.107.140])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by camomile.cloud9.net (Postfix) with ESMTPS id CE06D3310A6
for <postfix-users@postfix.org>; Sat, 11 Feb 2017 20:55:57 -0500 (EST)
Received: from linuxlite-desktop (localhost [127.0.0.1])
by dns2.sebbe.eu (Postfix) with ESMTP id 2E31476024B
for <postfix-users@postfix.org>; Sun, 12 Feb 2017 02:55:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sebbe.eu; s=root;
t=1486864555; bh=QG62M3r5Lc+7o9a5bmtrhKgDItf9g2IQHyYASOb1hFc=;
h=Date:From:To:In-Reply-To:References:Subject:From;
b=AnBtXcH6dIzWlO8tvRvhYxjFfHth6ioQDTnHiSmRl2ZFgRs6P9eUsrIRcUeJuABKT
 aXDhQlpzqGTNehqqtKamWb4cc5VqOLATXeR/2hD2Uiz63QQJHMyiC6eAzUzarfvwjU
 NpXW2pHtVj/J7c+XO/rrKeapamzY8aCTiPImxI6k=
Received: from [192.168.3.90] (unknown [192.168.3.90])
by dns1.sebbe.eu (Postfix) with ESMTP id 323CB76024B
for <postfix-users@postfix.org>; Sun, 12 Feb 2017 02:55:41 +0100 (CET)
Date: Sun, 12 Feb 2017 02:55:39 +0100
From: Sebastian Nielsen <sebast...@sebbe.eu>
To: postfix-users@postfix.org
Message-ID: <3dfb9ae5-1bd8-417f-9b00-c3954c22e...@sebbe.eu>
In-Reply-To: <20170212015134.gb18...@naleco.com>
References: <20170212005312.ga12...@naleco.com> 
<1cf4d7a776ca97544eb0d21d36253...@junc.eu> <20170212015134.gb18...@naleco.com>
Subject: Re: Why no List-ID header in the postfix-users posts?
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; 
micalg=sha-256; 
boundary="=_Part_17_905167004.1486864541512"
User-Agent: WristMail for Android
X-Hashcash: 
1:26:170212:postfix-users@postfix.org::8sJRinKtSCxqHE9u:0003Mp9h
Sender: owner-postfix-us...@postfix.org
Precedence: bulk
List-Id: Postfix users <postfix-users@postfix.org>
List-Post: <mailto:postfix-users@postfix.org>
List-Help: <http://www.postfix.org/lists.html>
List-Unsubscribe: <mailto:majord...@postfix.org>
List-Subscribe: <mailto:majord...@postfix.org>
-


As you see, its not going through even if dkim = pass.
I think DKIM on postfix list server would solve that.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Why no List-ID header in the postfix-users posts?

[Sebastian Nielsen]

I agree about the DKIM signing. I get regularly authentication failures 
(forensic reports) when posting to this list. Propably because my domain is set 
to require mandatory DKIM signing and postfix list server isn't.

However, I don't think there should be any subject tags.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: The "from" header looks like paypal but it is coming from somewhere else. [signed]

[Sebastian Nielsen]

It is a DKIM issue. Google "strict DKIM alignment"

This is something usually defined in DMARC, but you could have a local 
definition that forces strict DKIM alignment for sensitive domains, like "all 
domains containing *paypal* or *bank*".

Dominic Raferd <domi...@timedicer.co.uk> skrev: (9 februari 2017 12:11:11 CET)
>On 9 Feb 2017 12:53, <li...@lazygranch.com> wrote:
>
>That is the mailchimp server. (Technically rocketsciencegroup.com) So
>has
>the email originator figured out some sort of unintended use of
>mailchimp?
>
>
>
>*From: *Sebastian Nielsen
>*Sent: *Thursday, February 9, 2017 2:24 AM
>*To: *postfix-users@postfix.org
>*Subject: *Re: The "from" header looks like paypal but it is coming
>from
>somewhere else. [signed]
>
>The problem here is that DKIM isn't aligned to paypal.com
>Enforce strict DKIM alignment on sensitive domains like paypal
>
>I don't think this is a DKIM issue. A bespoke regex as check_header
>should
>be able to trap this specific faking attempt - if it relates as I think
>to
>the internal From header not the envelope sender (client).
>
>More generally, are there legitimate cases where a sender shows a
>different
>but apparently valid email address as the (whole) to text of the From
>compared with the actual address which follows it? If not, can a pcre
>regex
>match such situations or is something more sophisticated needed?


smime.p7s
Description: S/MIME Cryptographic Signature

Re: The "from" header looks like paypal but it is coming from somewhere else. [signed]

[Sebastian Nielsen]

The problem here is that DKIM isn't aligned to paypal.com
Enforce strict DKIM alignment on sensitive domains like paypal

smime.p7s
Description: S/MIME Cryptographic Signature

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!] [invalid signature!]

[Sebastian Nielsen]

Oops wrong, forgot about reject... (I tested on my system and I currently have 
no outgoing rejects)

grep "postfix/smtp\[" LOGFILE | grep -i "reject" | grep -io 
"\]\:\s[0123456789ABCDEF]*\:" | grep -io "[0123456789ABCDEF]*" | grep -f - 
LOGFILE | grep "postfix/qmgr\[" | grep "from="


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Christian Ro¨ßner
Skickat: den 16 januari 2017 15:17
Till: Sebastian Nielsen <sebast...@sebbe.eu>
Kopia: Postfix users <postfix-users@postfix.org>
Ämne: Re: [Feature-request for 3.2] log from= in postfix/smtp - or looking for 
unknown option [invalid signature!] [invalid signature!]

Hi,

not smtpd ;-) smtp client

> Am 16.01.2017 um 15:08 schrieb Sebastian Nielsen <sebast...@sebbe.eu>:
> 
> It do log from=.
> Default config from debian:
> 
> root@linuxlite-desktop:/var/log# grep NOQUEUE syslog.1 Jan 15 11:12:37 
> linuxlite-desktop postfix/smtpd[31407]: NOQUEUE: reject: RCPT from 
> unknown[202.12.83.69]: 554 5.7.1 <sebast...@sebbe.eu>: Sender address 
> rejected: Access denied; from=<sebast...@sebbe.eu> 
> to=<sebast...@sebbe.eu> proto=ESMTP 
> helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
> Jan 15 11:12:42 linuxlite-desktop postfix/smtpd[31409]: NOQUEUE: 
> reject: RCPT from unknown[202.12.83.69]: 554 5.7.1 
> <sebast...@sebbe.eu>: Sender address rejected: Access denied; 
> from=<sebast...@sebbe.eu> to=<sebast...@sebbe.eu> proto=ESMTP 
> helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
> Jan 15 12:57:05 linuxlite-desktop postfix/smtpd[32440]: NOQUEUE: 
> reject: RCPT from 1-160-42-66.dynamic.hinet.net[1.160.42.66]: 554 
> 5.7.1 <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 15 14:28:40 linuxlite-desktop 
> postfix/smtpd[956]: NOQUEUE: reject: RCPT from unknown[114.130.4.61]: 
> 554 5.7.1 <eax...@yahoo.com>: Relay access denied; from=<x...@ore.net> 
> to=<eax...@yahoo.com> proto=ESMTP helo=<192.168.0.137> Jan 15 16:15:46 
> linuxlite-desktop postfix/smtpd[2263]: NOQUEUE: reject: RCPT from 
> 111-251-109-66.dynamic.hinet.net[111.251.109.66]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 15 19:52:43 linuxlite-desktop 
> postfix/smtpd[4638]: NOQUEUE: reject: RCPT from 
> 1-160-42-242.dynamic.hinet.net[1.160.42.242]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 16 00:16:50 linuxlite-desktop 
> postfix/smtpd[7278]: NOQUEUE: reject: RCPT from 
> 1-162-232-106.dynamic.hinet.net[1.162.232.106]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 16 00:32:10 linuxlite-desktop 
> postfix/smtpd[7443]: NOQUEUE: reject: RCPT from 
> 24-54-48-245.sh.cgocable.ca[24.54.48.245]: 554 5.7.1 
> <eax...@yahoo.com>: Relay access denied; from=<x...@ore.net> 
> to=<eax...@yahoo.com> proto=ESMTP helo=<192.168.0.247> Jan 16 05:50:33 
> linuxlite-desktop postfix/smtpd[11103]: NOQUEUE: reject: RCPT from 
> 111-251-103-173.dynamic.hinet.net[111.251.103.173]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> root@linuxlite-desktop:/var/log#
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] För Christian Ro¨ßner
> Skickat: den 16 januari 2017 14:59
> Till: Postfix users <postfix-users@postfix.org>
> Ämne: [Feature-request for 3.2] log from= in postfix/smtp - or looking 
> for unknown option [invalid signature!]
> 
> Hi,
> 
> I have looked at man 5 postconf, if there exists an option to add the 
> envelope sender to the postfix smtp client, but I didn'T find one.
> 
> If an account gets stolen and this account starts sending lots of mails, it 
> often leads to RBLs. If you try to find the account that was compromised, a 
> first command would be something like:
> 
> grep "postfix/smtp\[" mail.log | grep -i reject
> 
> which will only give you thousands of queue-IDs. But this makes it harder to 
> dive deeper in searching for the compromised account, as you can not simply 
> enhance bash commands and sort for the from= filed (because it does not 
> exist).
> 
> Therefor I ask, if it is possible to add this little feature to 3.2 (if not 
> already frozen code).
> 
> Thanks in advance
> 
> ‌Christian Rößner‌
> --
> Erlenwiese 14, 36304 Alsfeld
> T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
> 
> 


‌Christian Rößner‌
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345




smime.p7s
Description: S/MIME Cryptographic Signature

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!] [invalid signature!]

[Sebastian Nielsen]

Try this:

grep "postfix/smtp\[" LOGFILE | grep -io "\]\:\s[0123456789ABCDEF]*\:" | grep 
-io "[0123456789ABCDEF]*" | grep -f - LOGFILE | grep "postfix/qmgr\[" | grep 
"from="

-Ursprungligt meddelande-
Från: Christian Rößner [mailto:c...@roessner-network-solutions.com] 
Skickat: den 16 januari 2017 15:17
Till: Sebastian Nielsen <sebast...@sebbe.eu>
Kopia: Postfix users <postfix-users@postfix.org>
Ämne: Re: [Feature-request for 3.2] log from= in postfix/smtp - or looking for 
unknown option [invalid signature!] [invalid signature!]

Hi,

not smtpd ;-) smtp client

> Am 16.01.2017 um 15:08 schrieb Sebastian Nielsen <sebast...@sebbe.eu>:
> 
> It do log from=.
> Default config from debian:
> 
> root@linuxlite-desktop:/var/log# grep NOQUEUE syslog.1 Jan 15 11:12:37 
> linuxlite-desktop postfix/smtpd[31407]: NOQUEUE: reject: RCPT from 
> unknown[202.12.83.69]: 554 5.7.1 <sebast...@sebbe.eu>: Sender address 
> rejected: Access denied; from=<sebast...@sebbe.eu> 
> to=<sebast...@sebbe.eu> proto=ESMTP 
> helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
> Jan 15 11:12:42 linuxlite-desktop postfix/smtpd[31409]: NOQUEUE: 
> reject: RCPT from unknown[202.12.83.69]: 554 5.7.1 
> <sebast...@sebbe.eu>: Sender address rejected: Access denied; 
> from=<sebast...@sebbe.eu> to=<sebast...@sebbe.eu> proto=ESMTP 
> helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
> Jan 15 12:57:05 linuxlite-desktop postfix/smtpd[32440]: NOQUEUE: 
> reject: RCPT from 1-160-42-66.dynamic.hinet.net[1.160.42.66]: 554 
> 5.7.1 <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 15 14:28:40 linuxlite-desktop 
> postfix/smtpd[956]: NOQUEUE: reject: RCPT from unknown[114.130.4.61]: 
> 554 5.7.1 <eax...@yahoo.com>: Relay access denied; from=<x...@ore.net> 
> to=<eax...@yahoo.com> proto=ESMTP helo=<192.168.0.137> Jan 15 16:15:46 
> linuxlite-desktop postfix/smtpd[2263]: NOQUEUE: reject: RCPT from 
> 111-251-109-66.dynamic.hinet.net[111.251.109.66]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 15 19:52:43 linuxlite-desktop 
> postfix/smtpd[4638]: NOQUEUE: reject: RCPT from 
> 1-160-42-242.dynamic.hinet.net[1.160.42.242]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 16 00:16:50 linuxlite-desktop 
> postfix/smtpd[7278]: NOQUEUE: reject: RCPT from 
> 1-162-232-106.dynamic.hinet.net[1.162.232.106]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> Jan 16 00:32:10 linuxlite-desktop 
> postfix/smtpd[7443]: NOQUEUE: reject: RCPT from 
> 24-54-48-245.sh.cgocable.ca[24.54.48.245]: 554 5.7.1 
> <eax...@yahoo.com>: Relay access denied; from=<x...@ore.net> 
> to=<eax...@yahoo.com> proto=ESMTP helo=<192.168.0.247> Jan 16 05:50:33 
> linuxlite-desktop postfix/smtpd[11103]: NOQUEUE: reject: RCPT from 
> 111-251-103-173.dynamic.hinet.net[111.251.103.173]: 554 5.7.1 
> <g...@linwayedm.com.tw>: Relay access denied; 
> from=<d...@email.cta.cq.cnt> to=<g...@linwayedm.com.tw> proto=SMTP 
> helo=<46.227.69.210> root@linuxlite-desktop:/var/log#
> 
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] För Christian Ro¨ßner
> Skickat: den 16 januari 2017 14:59
> Till: Postfix users <postfix-users@postfix.org>
> Ämne: [Feature-request for 3.2] log from= in postfix/smtp - or looking 
> for unknown option [invalid signature!]
> 
> Hi,
> 
> I have looked at man 5 postconf, if there exists an option to add the 
> envelope sender to the postfix smtp client, but I didn'T find one.
> 
> If an account gets stolen and this account starts sending lots of mails, it 
> often leads to RBLs. If you try to find the account that was compromised, a 
> first command would be something like:
> 
> grep "postfix/smtp\[" mail.log | grep -i reject
> 
> which will only give you thousands of queue-IDs. But this makes it harder to 
> dive deeper in searching for the compromised account, as you can not simply 
> enhance bash commands and sort for the from= filed (because it does not 
> exist).
> 
> Therefor I ask, if it is possible to add this little feature to 3.2 (if not 
> already frozen code).
> 
> Thanks in advance
> 
> ‌Christian Rößner‌
> --
> Erlenwiese 14, 36304 Alsfeld
> T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
> 
> 


‌Christian Rößner‌
--
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345




smime.p7s
Description: S/MIME Cryptographic Signature

SV: [Feature-request for 3.2] log from= in postfix/smtp - or looking for unknown option [invalid signature!]

[Sebastian Nielsen]

It do log from=.
Default config from debian:

root@linuxlite-desktop:/var/log# grep NOQUEUE syslog.1
Jan 15 11:12:37 linuxlite-desktop postfix/smtpd[31407]: NOQUEUE: reject: RCPT 
from unknown[202.12.83.69]: 554 5.7.1 : Sender address 
rejected: Access denied; from= to= 
proto=ESMTP helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
Jan 15 11:12:42 linuxlite-desktop postfix/smtpd[31409]: NOQUEUE: reject: RCPT 
from unknown[202.12.83.69]: 554 5.7.1 : Sender address 
rejected: Access denied; from= to= 
proto=ESMTP helo=<202-12-83-69-dynamic.mangalore.cscnet.in>
Jan 15 12:57:05 linuxlite-desktop postfix/smtpd[32440]: NOQUEUE: reject: RCPT 
from 1-160-42-66.dynamic.hinet.net[1.160.42.66]: 554 5.7.1 
: Relay access denied; from= 
to= proto=SMTP helo=<46.227.69.210>
Jan 15 14:28:40 linuxlite-desktop postfix/smtpd[956]: NOQUEUE: reject: RCPT 
from unknown[114.130.4.61]: 554 5.7.1 : Relay access denied; 
from= to= proto=ESMTP helo=<192.168.0.137>
Jan 15 16:15:46 linuxlite-desktop postfix/smtpd[2263]: NOQUEUE: reject: RCPT 
from 111-251-109-66.dynamic.hinet.net[111.251.109.66]: 554 5.7.1 
: Relay access denied; from= 
to= proto=SMTP helo=<46.227.69.210>
Jan 15 19:52:43 linuxlite-desktop postfix/smtpd[4638]: NOQUEUE: reject: RCPT 
from 1-160-42-242.dynamic.hinet.net[1.160.42.242]: 554 5.7.1 
: Relay access denied; from= 
to= proto=SMTP helo=<46.227.69.210>
Jan 16 00:16:50 linuxlite-desktop postfix/smtpd[7278]: NOQUEUE: reject: RCPT 
from 1-162-232-106.dynamic.hinet.net[1.162.232.106]: 554 5.7.1 
: Relay access denied; from= 
to= proto=SMTP helo=<46.227.69.210>
Jan 16 00:32:10 linuxlite-desktop postfix/smtpd[7443]: NOQUEUE: reject: RCPT 
from 24-54-48-245.sh.cgocable.ca[24.54.48.245]: 554 5.7.1 : 
Relay access denied; from= to= proto=ESMTP 
helo=<192.168.0.247>
Jan 16 05:50:33 linuxlite-desktop postfix/smtpd[11103]: NOQUEUE: reject: RCPT 
from 111-251-103-173.dynamic.hinet.net[111.251.103.173]: 554 5.7.1 
: Relay access denied; from= 
to= proto=SMTP helo=<46.227.69.210>
root@linuxlite-desktop:/var/log#

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Christian Ro¨ßner
Skickat: den 16 januari 2017 14:59
Till: Postfix users 
Ämne: [Feature-request for 3.2] log from= in postfix/smtp - or looking for 
unknown option [invalid signature!]

Hi,

I have looked at man 5 postconf, if there exists an option to add the envelope 
sender to the postfix smtp client, but I didn'T find one.

If an account gets stolen and this account starts sending lots of mails, it 
often leads to RBLs. If you try to find the account that was compromised, a 
first command would be something like:

grep "postfix/smtp\[" mail.log | grep -i reject

which will only give you thousands of queue-IDs. But this makes it harder to 
dive deeper in searching for the compromised account, as you can not simply 
enhance bash commands and sort for the from= filed (because it does not exist).

Therefor I ask, if it is possible to add this little feature to 3.2 (if not 
already frozen code).

Thanks in advance

‌Christian Rößner‌
-- 
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345




smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF entries for IPv4 & IPv6

[Sebastian Nielsen]

OFC you must specify both unless you have completely disabled sending of 
outgoing mail via IPv6.

Per Thorsheim  skrev: (2 januari 2017 14:16:04 CET)
>If using IP addresses in SPF records, is it necessary to specify both
>IPv4 & IPv6 addresses? Is there currently a risk of unwanted problems
>if
>only IPv4 (or only IPv6) addresses are specified, when a mailserver is
>available using both 4 & 6?
>
>-- 
>Best regards,
>Per Thorsheim
>Twitter: @thorsheim


smime.p7s
Description: S/MIME Cryptographic Signature

SV: Stopping compromised accounts

[Sebastian Nielsen]

This depends on how the accounts are compromised.
First of, you should enforce so the MAIL FROM is locked to their account, eg 
they cannot use another MAIL FROM than they are authorized to use.

Second, it then depends on how the accounts are compromised.
You say "their local desktop using the submission service". Are you sure of 
that? Eg, the IP in the logs indicate that?
The reason I ask, is that its more common that malicious software steals the 
credentials and sends it elsewhere.

If the accounts are simply "stolen" by malicious software and then used by 
spammers at other locations of the world, I would suggest using GeoIP 
restrictions to lock the account to the country/ISP where the user first logged 
on to. If your users/customers are limited to one country (for example, if you 
only sell services inside a certain country), you can also lock access to the 
submission server alltogheter using GeoIP.
(Travelling users then need to pre-apply at your customers service desk to 
enable account for temporary travel).

However, if the accounts are compromised by the malicious software actually 
sending email through the local user's computer, then its not much you can do.
You could use something that restricts account to like 25 messages a day, and 
if that limit is reached, account is blocked until the user goes to the webmail 
and, lets say, enter a one-time code sent via SMS to the user's phone.

I Do not know any "out of the box" software that can do this, I think you have 
to write a own soiftware that counts outgoing messages per user, a CRON script 
that resets the day counters each 00:00, and if any account reach 25 messages, 
its disabled in the system.
And then some webservice where the user can reset the block with a one-time 
code.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Alex
Skickat: den 6 december 2016 02:52
Till: postfix users list 
Ämne: Stopping compromised accounts

Hi,

I have a postfix-3.0.5 system with a few hundred users. They have access to 
submission, webmail, and dovecot to send and receive mail.

On occasion, user's local desktop are compromised, and with it their account on 
this system. This leads to their local desktop using the submission service to 
send hundreds or thousands of spam emails through this compromised account.

They're only stopped after the user receives a ton of bounce messages, or we 
happen to see it somehow while watching logs.

What mechanisms are available to say, control the number of messages sent per 
day or otherwise be made aware of a pattern of messages being sent by an 
account that could be indicative of account compromise?

Thanks,
Alex



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: SV: SV: block emails which pretend to originate from my domain

[Sebastian Nielsen]

Yeah. The OP presumably had his "permit_sasl_authenticated" both in sender
restrictions and relay restrictions. Thats why I gave a example of sender
restrictions where I also said that every instance of
permit_sasl_authenticated need to be replaced (For example, if one is in
recipient restrictions or relay restrictions).

With "policy stack", I didn't mean that the different stages affect each
other.
What I meant is that a policy containing "check_[something]_access" pointing
to something (a table, binary program, whatsoever) that itself return a
policy as reply, will cause the new policy to be "inserted" at the
check_[something]_access location during policy evulation.

This effectively means there is a separate "stack" for each mumble, where
parts of policy may be replaced.

(As different check_[something]_access and different other policies may be
mixed)



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: SV: block emails which pretend to originate from my domain

[Sebastian Nielsen]

Im talking about this:

smtpd_sender_restrictions = check_sender_access hash:/etc/file

/etc/file (before postmap)
mydomain.com permit_sasl_authenticated, reject


The result is that if sender domain is mydomain.com, the policy applied will
be "permit_sasl_authenticated, reject".
This will result in any unauthenticated mail claiming to be from
mydomain.com to be rejected (, reject), even if the destination is
authorized since the policy stack will see a plain "reject" before
"reject_unauth_destination".

BUT, if the sender is NOT mydomain.com, the check_sender_access will return
nothing, thus there will be no "permit_sasl_authenticated" on the policy
stack, thus the mail will be rejected with "Relay access denied" even for
authenticated users, as the policy stack will end up on
"reject_unauth_destination" without seeing any permit_sasl_authenticated.

(Note that this means that every instance of "permit_sasl_authenticated"
need to be replaced with "check_sender_access hash:/etc/file")

You understand the idea now?

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För /dev/rob0
Skickat: den 19 november 2016 19:34
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: block emails which pretend to originate from my domain

On Thu, Nov 17, 2016 at 05:31:43PM +0100, Sebastian Nielsen wrote:
> The advantage with using "permit_sasl_authenticated, reject" as 
> check_sender_access in the global config, is that authenticated 
> senders won't be able to send with a adress outside of your domain 
> either, thus achieving both local spoof prevention for unauthenticated 
> users, but also prevents foregin spoof from authenticated users.

That's not true.

"permit_sasl_authenticated" does exactly what it says, regardless of sender
address.  If the client successfully authenticated, the mail is accepted.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: block emails which pretend to originate from my domain

[Sebastian Nielsen]

The advantage with using "permit_sasl_authenticated, reject" as 
check_sender_access in the global config, is that authenticated senders won't 
be able to send with a adress outside of your domain either, thus achieving 
both local spoof prevention for unauthenticated users, but also prevents 
foregin spoof from authenticated users.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Phil Stracchino
Skickat: den 17 november 2016 17:26
Till: postfix-users@postfix.org
Ämne: Re: SV: block emails which pretend to originate from my domain

On 11/17/16 09:16, Sebastian Nielsen wrote:
> You have your permit_sasl_authenticated inside smtpd_sender_restrictions 
> right?
> Replace that with "check_sender_access hash:/path/to/file"


...Right, never mind, reading too early in the morning.


> Inside the file /path/to/file, you add the following:
> mydomain.com permit_sasl_authenticated, reject
> 
> Essentially, you move your "permit_sasl_authenticated" to the /path/to/file 
> file.
> 
> Or do you already have a check_sender_access containing 
> permit_sasl_authenticated?


I'm actually achieving the same end a different way:


smtpd_recipient_restrictions = ...
   ...
 check_sender_access btree:/etc/postfix/block-local-sender

/etc/postfix/block-local-sender:
caerllewys.net  REJECT Local sender address is not allowed


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485



smime.p7s
Description: S/MIME Cryptographic Signature

SV: block emails which pretend to originate from my domain

[Sebastian Nielsen]

You have your permit_sasl_authenticated inside smtpd_sender_restrictions right?
Replace that with "check_sender_access hash:/path/to/file"

Inside the file /path/to/file, you add the following:
mydomain.com permit_sasl_authenticated, reject

Essentially, you move your "permit_sasl_authenticated" to the /path/to/file 
file.

Or do you already have a check_sender_access containing 
permit_sasl_authenticated?

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Phil Stracchino
Skickat: den 17 november 2016 15:10
Till: postfix-users@postfix.org
Ämne: Re: block emails which pretend to originate from my domain

On 11/17/16 04:47, Sebastian Nielsen wrote:
> Put check_sender_access hash:/path/to/file INSTEAD of 
> permit_sasl_authenticated in global config.
> 
> in "/path/to/file", put mydomain.com permit_sasl_authenticated, reject

In check_sender_access, in smtpd_sender_restrictions, or does it not matter 
which of the two?


--
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485



smime.p7s
Description: S/MIME Cryptographic Signature

Re: block emails which pretend to originate from my domain

[Sebastian Nielsen]

Don't forget postmap:ing /path/to/file, else it won't work.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: block emails which pretend to originate from my domain

[Sebastian Nielsen]

Put check_sender_access hash:/path/to/file INSTEAD of permit_sasl_authenticated 
in global config.

in "/path/to/file", put mydomain.com permit_sasl_authenticated, reject

This will accomplish 2 things:
unauhenticated users can't spoof your domain when sending to you.
Authenticated users cannot spoof someone elses domain (they will get relay 
denied).

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Blocking users sending spam

[Sebastian Nielsen]

I would say that GeoIP would be the best.
And those users that need to travel need to pre-request travelling access 
through a captcha-protected AND geoip restricted web interface prior to 
travelling. (but once opened, they can extend access out-of-country)

And then they need to specify time spent away. (which will be deducted from 
their total)

Also to prevent people from opening travel access without need, make it so they 
can open a maximum lets say TOTAL=30 days per 180 days.

Volker Cordes  skrev: (15 november 2016 14:09:03 CET)
>Hello,
>
>I just stopped our server from sending out spam mails. A password from
>one of our customers was hacked or somehow leaked so that the mails
>were
>sent by an authenticated user. Now I was wondering if it is possible to
>block users that authenticate themselves from a lot of different IP
>addresses in a short timespan or to implement blocking using
>geoip-services (99% of our customers are based in germany).
>
>Thanks,
>Volker


smime.p7s
Description: S/MIME Cryptographic Signature

SV: Let's Encrypt + Postfix TLS + iOS Mail

[Sebastian Nielsen]

You need to be more clear here.

When you say Gmail account on port 587 I don’t entirely understand what you are 
doing. Are you using Gmail as upstream smarthost?

This does not then have any bearing on what clients see or react to, as your 
server acts as a proxy to Gmail.

 

If the iOS mail client complains about certificate being untrusted, its because 
the Let’s encrypt root is not imported or trusted, or that the entire chain 
excluding the root certificate, is not sent.

Note that Let’s encrypt is a pretty new actor so if your iOS device is old, it 
will always untrust. Try visiting a site that has Let’s encrypt deployed. If 
you get cert errors, this is the case.

 

 

Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Steve Jenkins
Skickat: den 15 november 2016 03:08
Till: postfix users 
Ämne: Let's Encrypt + Postfix TLS + iOS Mail

 

I've had TLS working great on my Postfix servers for years, and I recently 
tried switching one of my boxes to a Let's Encrypt certificate. A Gmail test 
account using TLS on port 587 works fine, but the iOS mail client complains 
about the certificate being untrusted. Further digging shows it doesn't like 
the CA.

 

I added the fullchain.pem file to the '/etc/postfix/ssl/cacert.pem' I use for 
'smtpd_tls_CAfile' but that doesn't fix anything.

 

Has anyone been able to get an iOS mail client to use a Postfix SMTP server 
with TLS?

 

Here are my current (working) TLS-related entries in main.cf  :

 

# postconf -n | grep tls

smtp_tls_CAfile = $smtpd_tls_CAfile

smtp_tls_loglevel = 1

smtp_tls_security_level = may

smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem

smtpd_tls_auth_only = yes

smtpd_tls_cert_file = /etc/pki/tls/certs/example.com.crt

smtpd_tls_key_file = /etc/pki/tls/private/example.com.key

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_security_level = may

 

It breaks (on iOS) if I change the smtpd_tls_cert_file and smtpd_tls_key_file 
to the Let's Encrypt cert and key.

 

Thanks,

 

SteveJ



smime.p7s
Description: S/MIME Cryptographic Signature

SV: DKIM not verifying without signature

[Sebastian Nielsen]

You can add "AlwaysAddARHeader yes"
Then opendkim will always add a verification header even if no signature.

There is also also the following options available:
On-BadSignature 
On-Default 
On-DNSError 
On-InternalError 
On-KeyNotFound 
On-NoSignature 
On-Security 
On-SignatureError 

Which can be set if you want to reject or otherwise process mail with
certain signature errors. For example, rejecting mails with no DKIM sig.



Bill Cole: What he is out after, is the "Theres no signature" result.
Not adding a header, could mean a bogus source could insert a fake
"Signature valid" header and pass DKIM validation.
By always adding a verification result, even when no sig is found, a fake
header would mean theres a double result, or (if opendkim is configured to
remove fake headers) only the genuine header, which means it can be easily
detected that somebody is attempting to cheat.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Robert Fitzpatrick
Skickat: den 30 oktober 2016 17:44
Till: Postfix 
Ämne: DKIM not verifying without signature

The opendkim mailing lists seems not available any longer, so thought I'd
try here. I'm trying to get a handle on how to setup DKIM properly on a
gateway server, not even sure if what I'm trying to do is possible. 
This gateway serves as an MX with ClamAV+Amavisd+SA filtering as well as the
smarthost for the subject domain.

I can get opendkim to sign when coming from a entry in the TrustedHosts
file, but it is not verifying unless a signature if present. Does dkim only
verify when a signature is added or can I setup so the domain is verified
with or without a signature? It would be ideal to get the
'Authentication-Results' header to use in SA scoring and reject as needed. I
do have an SA rule now that gives a high kill score when a message hits
SPF_FAIL without hitting DKIM_VALID as well. But, it seems SPF is not enough
these days.

 From what I understand from the opendkim man page is the 'Mode' default is
'sv' to sign and verify. Didn't think 'On-BadSignature' should be used since
there is no signature. Here is my opendkim.conf:

LogWhy  yes
Syslog  yes
SyslogSuccess   yes
Canonicalizationrelaxed/simple
KeyTable/usr/local/etc/opendkim/KeyTable
SigningTable/usr/local/etc/opendkim/SigningTable
ExternalIgnoreList  /usr/local/etc/opendkim/TrustedHosts
InternalHosts   /usr/local/etc/opendkim/TrustedHosts
Socket  inet:8891@localhost
ReportAddress   postmas...@webtent.net
SendReports yes

And the contents of my TrustedHosts file:

#127.0.0.1
#localhost
208.38.145.0/26
216.139.202.0/27

I commented out the localhost portions because it was signing twice, both
after the initial Received header and then again after received by the
filter. The latter two networks are internal network sources I do not want
to verify, only sign.

I send a message hoping to be rejected and it is not, the resulting headers
show nothing dkim related:

> Return-Path: 
> Received: from mx2.webtent.net (mx2.webtent.net [216.139.202.4])
>   by www1.webtent.net (8.13.8/8.13.8) with ESMTP id u9UFtNwo025106
>   for ; Sun, 30 Oct 2016 11:55:23 -0400
> Received: from localhost (localhost [127.0.0.1])
>   by mx2.webtent.net (WebTent ESMTP Postfix Internet Mail Exchange)
with ESMTP id 5991AD7E50
>   for ; Sun, 30 Oct 2016 11:55:23 -0400 (EDT)
> Received: from mx2.webtent.net ([127.0.0.1])  by localhost 
> (mx2.webtent.net [127.0.0.1]) (maiad, port 10024) with ESMTP  id 
> 08148-06 for ; Sun, 30 Oct 2016 11:55:21 -0400 (EDT)
> Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
> client-ip=96.254.71.164; helo=[192.168.1.110]; 
> envelope-from=administra...@subjectdomain.com; 
> receiver=rob...@rfitz.com
> Received: from [192.168.1.110] (media.rfitz.com [96.254.71.164])
>   by mx2.webtent.net (WebTent ESMTP Postfix Internet Mail Exchange)
with ESMTP id A11D7D7E46
>   for ; Sun, 30 Oct 2016 11:55:21 -0400 (EDT)
> Message-ID: <581617e9.5080...@subjectdomain.com>
> Date: Sun, 30 Oct 2016 11:55:21 -0400
> From: MRI Tampa 
> User-Agent: Postbox 4.0.8 (Windows/20151105)
> MIME-Version: 1.0
> To: Rob Fitzpatrick 
> Subject: Test DKIM with no auth
> References: <58161558.2090...@subjectdomain.com> 
> <58161684.7010...@subjectdomain.com>
> In-Reply-To: <58161684.7010...@subjectdomain.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> X-Virus-Scanned: WebTent Mailguard 1.0.3
> X-Spam-Status: No, hits=-1.901 tagged_above=-999 required=5  
> tests=BAYES_00=-1.9, SPF_PASS=-0.001

And the log entries show:

> root@mx2:/usr/local/etc # grep A11D7D7E46 /var/log/maillog Oct 

SV: (Semi OT) RBL shakedown

[Sebastian Nielsen]

Agreed, they even list AS23456 , which is a reserved AS used for BGP32
routers to annouce themselves to BGP16 routers. (the BGP32 ASN is then
embedded in the payload of the BGP16 packet, which result that when this
BGP16 router then further annouce themselves to a BGP32 router, the real 32
bit ASN will unfold itself).

UCEprotect then list this reserved ASN, instead of unfolding the packet and
looking at the real payload, causing every BGP32 network which annouce BGP16
compatibility, to be listed in UCEPROTECT L3.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För li...@lazygranch.com
Skickat: den 24 oktober 2016 22:20
Till: postfix-users@postfix.org
Ämne: (Semi OT) RBL shakedown

If you use the uceprotect RBL, note that they are involved in a shakedown to
solicit money to be removed from their list. Much like spamrl, I'd suggest
not using them since they have an obvious false positive problem. 

http://www.uceprotect.net/en/rblcheck.php?ipr=107.170.248.198
Their own system shows my domain is not the same as the spammers domain.

Plenty of good RBLs out there. No uses feeding the criminals
(uceprotect) or the incompetent (spamrl).



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: Open relay

[Sebastian Nielsen]

Yeah, in this situation it might be a bad idea as the problem is not really
HELO 127.0.0.1, but rather that a account is compromised.
I would rather limit the relay so authorized accounts can only be used from
authorized IP adresses, like the local branch.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För /dev/rob0
Skickat: den 22 oktober 2016 18:29
Till: postfix-users@postfix.org
Ämne: Re: SV: Open relay

On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
> Or even better: Accept the mail, but toss it away. Eg use, DISCARD 
> instead.

Oh, ugh, definitely not.  This is terrible advice.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Open relay

[Sebastian Nielsen]

Or even better: Accept the mail, but toss it away. Eg use, DISCARD instead.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Paul Schmehl
Skickat: den 22 oktober 2016 18:20
Till: Paul van der Vlis ; postfix-users@postfix.org
Ämne: Re: Open relay

--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
 wrote:

> Op 22-10-16 om 04:32 schreef Bill Cole:
>> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:
>
>>> 
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>>> [87.92.55.206])
>>> (Authenticated sender: p...@puk.nl)
>>> by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>> Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> 
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi 
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and 
>> proceeded to authenticate as the user whose name you've replaced with 
>> p...@puk.nl.
>>
>> As a stopgap, you could add a directive like this to
>> smtpd_helo_restrictions:
>>
>>check_helo_access pcre:/etc/postfix/helo_checks
>>
>> And in that helo_checks file;
>>
>> /127\.0\.0\.1/REJECT you are not me
>
> Thanks, a great idea to have standard in most cases.

I would make one suggestion.  I would reject the attempt silently.  No sense
in tipping off the spammer to what he needs to do to work around it. 
Just use REJECT with no explanation.

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl (pschm...@tx.rr.com)
Independent Researcher



smime.p7s
Description: S/MIME Cryptographic Signature

Route mails containing only digits in user parts differently

[Sebastian Nielsen]

I currently have this postfix server.

 

What I want to do now, is to route all mails containing only digits in the
user part, for example: 12345...@sebbe.eu <mailto:12345...@sebbe.eu>  or
63232535...@sebbe.eu <mailto:63232535...@sebbe.eu> 

To a application, namely smsq.

 

So basically, for any mail arriving at {DIGITS}@sebbe.eu
<mailto:%7bdigits...@sebbe.eu>  , I want to cut out the first 150 characters
of the plaintext body, and then send it to the following command:

smsq --motx=SIP/074094@cellip --da {DIGITS} --ud
{TRUNCATED_PLAINTEXT_BODY}

 

And of course, sending to these adresses should be considered relay, eg if
you aren't permitted to relay through the server, any mail to a adress whose
user-part contains only digits, should be rejected, for obvious security
reasons.

 

Best regards, Sebastian Nielsen



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is my server mail account being attacted?

[Sebastian Nielsen]

No, fail2ban would also block legitimate users where the user may have flaky 
connection and doing one or more connections and not authenticating.

The SSL attempts for http could be blocked with fail2ban.

The other SSL attempts attempting to negotiate a old version, may block 
legitimate users trying to auth with an old client.

I would say, the best way to block these types of attacks is to terminate your 
SSL in your firewall, and just block anything not up to standards. Not ban, but 
just block the single transactuion by disconnecting the user. And anything OK 
you just fwd to your mail server unencrypted. Then the firewall takes the bang 
and your mail server receives only clean traffic.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Is my server mail account being attacted?

[Sebastian Nielsen]

Looks rather like a scanning attack (finding vulnerabilities). I think they are 
trying to do a SSL type of attack like HEARTBLEED but your server isn't 
vulnerable.
Looks also like they are sending HTTP requests (encapsulated in SSL/TLS) to a 
mail server, which seems to be a extremely stupid bot scanner.

Its clear from the log, the attacker isn't even attemping to authenticate (0 
attempts). The attacker hasn't propably not even realized he is connecting to a 
mail server.

smime.p7s
Description: S/MIME Cryptographic Signature

SV: Restriction question

[Sebastian Nielsen]

Yes exactly, provided that the server is authoriative for that domain, eg is
listed as MX, listed in mydestinations and can receive mail from the
internet.

Note that you still need to remove permit_authenticated from your
restrictions list, else leaked username/password from the production server
can be misused.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Mark Holmes
Skickat: den 18 oktober 2016 21:54
Till: 'Sebastian Nielsen' <sebast...@sebbe.eu>; postfix-users@postfix.org
Ämne: RE: Restriction question

Great, thanks - so, just to confirm - with that config, dev and test will
still be able to email our 'internal' domain eg eu.biworldwide.com, but
nothing else?


-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: 18 October 2016 20:51
To: postfix-users@postfix.org
Subject: SV: Restriction question

Set mynetworks to only contain the IPs or networks of the production server.
You can use /32 to list single IPs.
Like:
mynetworks = 123.123.123.123/32, 222.222.222.222/32

etc

Thus, the server will automatically only permit mail to mydestination (eg,
the domain that the server is authorative for) since the dev and test server
will then look like "external" users.

Note that you will have to remove "permit_authenticated" from your relay
restrictions.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Mark Holmes
Skickat: den 18 oktober 2016 21:46
Till: 'postfix-users@postfix.org' <postfix-users@postfix.org>
Ämne: Restriction question

Hi list,

I'd like to configure Postfix such that I can prevent certain IP's/networks
from sending email to 'external' recipients. I'm basically trying to set it
so that our dev and test web application servers can't email any domains
other than our own - so developers can test email functionality without the
risk of sending email out to 'real' addresses by mistake. 

So I need something that says 'if the server is from this IP/network then
only allow mail to mydomain.net'. Or more likely, something which says
'these internal networks can only send to internal recipients, with the
exception of these IP's which can also send to external recipients' 

I've done some Googling but can't quite figure the best way to achieve this.
Grateful for any pointers!

Many thanks,

Mark


This e-mail message is being sent solely for use by the intended
recipient(s) and may contain confidential information.  Any unauthorized
review, use, disclosure or distribution is prohibited.  If you are not the
intended recipient, please contact the sender by phone or reply by e-mail,
delete the original message and destroy all copies. Thank you.

This e-mail message is being sent solely for use by the intended
recipient(s) and may contain confidential information.  Any unauthorized
review, use, disclosure or distribution is prohibited.  If you are not the
intended recipient, please contact the sender by phone or reply by e-mail,
delete the original message and destroy all copies. Thank you.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: said: 421-4.7.0 This message does not have authentication information

[Sebastian Nielsen]

You need to set up either SPF or DKIM, so GMAIL can detect spoofed mail. I
would recommend SPF, its easiest.

 

Just add the following to your DNS:

@ IN TXT ”v=spf1 ip4: -all”

(repeat the ip4 command if you have multiple servers, ip6 is for IPv6)

 

Or:

@ IN TXT ”v=spf1 mx -all”

 

If your incoming server(s) is same as your outgoing.

 

Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Motty Cruz
Skickat: den 30 september 2016 00:49
Till: postfix-users@postfix.org
Ämne: said: 421-4.7.0 This message does not have authentication information

 

Hello, I see the following errors on SMTP server logs: 

 

E7AA017645  556 Thu Sep 29 15:43:13  us...@fqdn.com
 

(host alt1.gmail-smtp-in.l.google.com[74.125.69.27] said: 421-4.7.0 This
message does not have authentication information or fails to pass 421-4.7.0
authentication checks. To best protect our users from spam, the 421-4.7.0
message has been blocked. Please visit 421-4.7.0
https://support.google.com/mail/answer/81126#authentication for more 421
4.7.0 information. o78si810588ita.33 - gsmtp (in reply to end of DATA
command))

 

We are not spammers, we’re legitimate, full qualify domain name. Any ideas? 

 

Thanks,
Motty



smime.p7s
Description: S/MIME Cryptographic Signature

SV: TLD blocking revisited

[Sebastian Nielsen]

I have had other experiences with spammers. I suspect there is different 
spammers out there that spam in different ways.
I once got a very irritating spammer that send a lot of spam, that was 
completely identical, had a identical color in the header and it was really 
obvious this spammer was the same person/company even if he spammed about lots 
of different subjects, everything from auto insurance to pills to earn money. 
Then I blocked his domain (blablabla.tld) in my postfix config, and had it set 
to reject.

Just a day after, he "started" spamming from a new domain, that was very 
similiar to the first. I knew it was the same person/company of the color.
I kept on blocking, and the spammer kept on changing.

Then I changed to DISCARD before blocking his new domain. Bam, that spam gone. 
I got a very few one with the same color in the header (before it was a few 
mails per hour), but eventually, it vanished. My log however, listed a lot of 
discards.

So I suspect that was a spammer that have got some sort of "verified list" (eg, 
those high price adress lists that are known to be valid) and spammed a few, 
propably in the area of hundreds of mails, and had good handling for 
bans/blocklists/ and propably for greylisting too, to keep their head under the 
radar.

So its just a tradeoff. Spam mails are today pretty small just to not trigger 
"huge-mail-alerts" so they consume minimal with bandwith and CPU cycles, but 
causes far much more "damage" in time spent for the user deleting the crap from 
the inbox.

But I agree, that if you get those "regular" spammers that doesn't pay 
attention to RFCs at all, then its better rejecting it.

-Ursprungligt meddelande-
Från: Jim Reid [mailto:j...@rfc1035.com] 
Skickat: den 21 september 2016 03:36
Till: Sebastian Nielsen <sebast...@sebbe.eu>
Kopia: Postfix Users <postfix-users@postfix.org>
Ämne: Re: TLD blocking revisited




smime.p7s
Description: S/MIME Cryptographic Signature

SV: TLD blocking revisited

[Sebastian Nielsen]

I would really suggest using DISCARD instead of "500 This TLD sends spam - g
e t lost.".
Thus the spammer dosen't get to know he got stuck in a spam filter and can
update their tools to bypass it.

DISCARD accepts the mail but throws it into /dev/null

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För li...@lazygranch.com
Skickat: den 21 september 2016 02:23
Till: Jim Reid 
Kopia: Postfix Users 
Ämne: Re: TLD blocking revisited

Tell ya what. Let's hold the suggestions here. This one looks like something
I can handle. (I really need things spelled out.)

BTW, the SpamAssassin enlist trick caught about 20% of this flavor of spam.
But I'm really OK will killing the TLD. 

I did some googling on this and some claim Baracuda has this spam style
licked, but I don't find that to be the case. I do have Baracuda as my first
RBL.

I didn't mention it but the odd thing is this .stream spam goes to one email
account. Perhaps in a daze I clicked unsubscribe. 

Thanks all for the suggestions.



  Original Message
From: Jim Reid
Sent: Tuesday, September 20, 2016 1:56 PM
To: li...@lazygranch.com
Cc: Postfix Users
Subject: Re: TLD blocking revisited


> On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote:
> 
> What is the simplest way to block a TLD?

Put the offending TLD in a map and have that map referenced through
check_sender_access and/or check_client_access.

ie 

in main.cf:


smtpd_client_restrictions = permit_mynetworks 
check_client_access hash:/etc/postfix/spamsources

mtpd_sender_restrictions = permit_mynetworks 
check_sender_access hash:/etc/postfix/spamsources


and in /etc/postfix/spamsources:

xyz 500 This TLD sends spam - get lost.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: TLD blocking revisited

[Sebastian Nielsen]

Im using the following to block TLDs, but not in helo checks, im using sender 
checks instead:

/\.bid$/ DISCARD
/\.top$/ DISCARD
/\.xyz$/ DISCARD
/\.pro$/ DISCARD
/\.date$/ DISCARD
/\.faith$/ DISCARD
/\.download$/ DISCARD

DISCARD blocks the mail without telling the sender the mail was blocked so 
spammers can't retry until they get the crap through.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: advice on securing a transport

[Sebastian Nielsen]

LazyGranch:
I look it at the point of view of the server who are receiving the mail.
So basically, the OP has some email adress like "webapprecei...@example.org"
that receives mail and processes this automatically into a database.

Only authorized users are allowed to send to this specifically crafted email
adress.

Thus, the receiving postfix server, could be configured to add a pass/fail
header of SPF and DKIM authentication.
Then the program acting on transport (eg, the actual /usr/bin program that
is configured as transport destination for webapprecei...@example.org) just
checks this header. If not at least one of them is PASS and the Return-Path:
header matches whats on a authorized list, the program could be configured
to just ignore the received mail in question.

Care needs to be taken so not anyone can fool the validation by inserting a
fraudulent SPF or DKIM header, which would result in a duplicate, one
genuine and one fake header.
This can be accomplished by either checking for duplicate headers and
failing authentication if there is duplicate SPF or DKIM header. (note:
DKIM-header = The header with the validation result, inserted by the local
validator, NOT the actual signature).
Or you can configure the validation process to always purge out any existing
validation headers before inserting its own.

Thus, actually, the postfix server does not need to reject any mail, this
could be coded into the transport program which also does all the
modification to the django app database, to dump all unauthenticated (eg, no
valid SPF or DKIM) and unauthorized (not on authorized list) into /dev/null.


Sean Greenslade:
Thats the responsibility of the server who is authorized to act on behalf of
that domain.




smime.p7s
Description: S/MIME Cryptographic Signature

SV: advice on securing a transport

[Sebastian Nielsen]

No, you're wrong. What the OP should do, is to enforce SPF/DKIM on specific 
RECEIVERS. For example, enforcing SPF/DKIM on for example 
webappad...@example.org.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För li...@lazygranch.com
Skickat: den 5 september 2016 19:20
Till: postfix-users@postfix.org
Ämne: Re: advice on securing a transport

‎First of all, be wary taking advice from a newbie like me. That said, if you 
enforce SPF and DKIM in postfix, you will be rejecting a lot of mail. If there 
is a way to enforce SPF and DKIM on specific senders, that would be another 
story.

But look at this line from the original message :

"What I would really like to do is be
able to send structured emails to the server, and have postfix pass them 
through a transport to the webapp (a Django site), which would parse the emails 
and do CRUD stuff with the database.‎"

Normally we read our email from a delivery agent like dovecot, but this mail 
will, if I understand the objective, with be "machine" read. That step is where 
you want to enforce SPF and DKIM. 


  Original Message
From: Sebastian Nielsen
Sent: Monday, September 5, 2016 9:54 AM
To: postfix-users@postfix.org
Subject: SV: advice on securing a transport

There is possibility to use SPF or DKIM to ensure the sender is not spoofed.
For this particular service, you can run your SPF and/or DKIM validator in 
mandatory mode, eg, a missing SPF record will be treated as -all, and a missing 
DKIM signature is treated as a invalid one.

Then you can actually use a list of authorized email adresses, even for 
third-party operators like GMAIL and such. So if a authorized user, sends a 
mail, using a server that is authorized either per that domain's SPF records or 
DKIM signature, then the mail will get accepted. Else it will be rejected.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Sean Greenslade
Skickat: den 5 september 2016 18:36
Till: Eric Abrahamsen <e...@ericabrahamsen.net>
Kopia: postfix-users@postfix.org
Ämne: Re: advice on securing a transport

On Mon, Sep 05, 2016 at 07:52:02PM +0800, Eric Abrahamsen wrote:
> I have a postfix/dovecot installation on the same server as my 
> company's webapp. This webapp involves a lot of regular data entry, 
> which is a real pain to do using HTML forms. What I would really like 
> to do is be able to send structured emails to the server, and have 
> postfix pass them through a transport to the webapp (a Django site), 
> which would parse the emails and do CRUD stuff with the database.
> 
> I can figure the details out myself, but I'm hoping to get advice on 
> one particular question: security.
> 
> I guess the safest thing would be to require logged-in users: 
> presumably I could find a way to only accept emails from a local 
> account, but that would require everyone who had access to this system 
> to have an account on the server.
> 
> The other option would be to maintain a list of authorized email 
> addresses, and then check incoming messages against this list. This 
> would be preferable, in that I don't have to bother users to create 
> and set up (and remember to use) a separate email account. My question 
> is, is there a truly secure way of only accepting emails from 
> authorized addresses? Or should I just go with option one and require 
> users to have accounts?

Envelope sender / From: field is not to be trusted. Anyone can submit a message 
with any envelope sender to an unauthenticated mail server.

I can see two ways of handling this. One is to implement standard submission 
port authentication / TLS on this machine, possibly with virtual users to 
prevent the need for all users to have local accounts.
The other way is to configure the machine to only accept incoming mail from 
your organization's main mail server(s). That way, your regular mail servers 
will perform the sender authentication, and then you can rely on the envelope 
sender (presuming your main mail servers do not allow sender spoofing).

--Sean





smime.p7s
Description: S/MIME Cryptographic Signature

SV: advice on securing a transport

[Sebastian Nielsen]

There is possibility to use SPF or DKIM to ensure the sender is not spoofed.
For this particular service, you can run your SPF and/or DKIM validator in
mandatory mode, eg, a missing SPF record will be treated as -all, and a
missing DKIM signature is treated as a invalid one.

Then you can actually use a list of authorized email adresses, even for
third-party operators like GMAIL and such. So if a authorized user, sends a
mail, using a server that is authorized either per that domain's SPF records
or DKIM signature, then the mail will get accepted. Else it will be
rejected.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Sean Greenslade
Skickat: den 5 september 2016 18:36
Till: Eric Abrahamsen 
Kopia: postfix-users@postfix.org
Ämne: Re: advice on securing a transport

On Mon, Sep 05, 2016 at 07:52:02PM +0800, Eric Abrahamsen wrote:
> I have a postfix/dovecot installation on the same server as my 
> company's webapp. This webapp involves a lot of regular data entry, 
> which is a real pain to do using HTML forms. What I would really like 
> to do is be able to send structured emails to the server, and have 
> postfix pass them through a transport to the webapp (a Django site), 
> which would parse the emails and do CRUD stuff with the database.
> 
> I can figure the details out myself, but I'm hoping to get advice on 
> one particular question: security.
> 
> I guess the safest thing would be to require logged-in users: 
> presumably I could find a way to only accept emails from a local 
> account, but that would require everyone who had access to this system 
> to have an account on the server.
> 
> The other option would be to maintain a list of authorized email 
> addresses, and then check incoming messages against this list. This 
> would be preferable, in that I don't have to bother users to create 
> and set up (and remember to use) a separate email account. My question 
> is, is there a truly secure way of only accepting emails from 
> authorized addresses? Or should I just go with option one and require 
> users to have accounts?

Envelope sender / From: field is not to be trusted. Anyone can submit a
message with any envelope sender to an unauthenticated mail server.

I can see two ways of handling this. One is to implement standard submission
port authentication / TLS on this machine, possibly with virtual users to
prevent the need for all users to have local accounts.
The other way is to configure the machine to only accept incoming mail from
your organization's main mail server(s). That way, your regular mail servers
will perform the sender authentication, and then you can rely on the
envelope sender (presuming your main mail servers do not allow sender
spoofing).

--Sean




smime.p7s
Description: S/MIME Cryptographic Signature

SV: How to restrict encrypted email

[Sebastian Nielsen]

The problem you got, is that the encrypted content has already travelled the
amateur frequencies even if you block/reject the mail.
Thus the rules are already broken, thus you should deal with those users in
a "AUP" way even if the mail gets blocked. Better might be to block this in
firewall then.
I guess you intend to operate a outgoing mail relay now.

You could use iptables to look for:
"--BEGIN"
"--END"
"/signed"
"/encrypted"
"/pkcs7"
"/pgp"

Anywhere in the packet. In that case, you drop the connection, send  a RST
to source and target, and then you could ban the user account involved.

You can look here how to do with IP-tables, both for blocking encrypted
content, but also triggering some sort of ban.
http://blog.nintechnet.com/how-to-block-w00tw00t-at-isc-sans-dfind-and-other
-web-vulnerability-scanners/
You can also use Fail2Ban for this, and trigger ban based on user account.

(NOTE: Signed content is technically encrypted content too)

-

If you instead operate a incoming mail relay (so internet users can send
messages to amateur radio operators), you said this would only apply to
certain users.
Then its better to block this on IMAP/POP3 level, as the users in question
might connect over public internet. Eg, encrypted mail is received and
stored, but it will never
Be delivered if the user is doing the fetch over radio frequencies (you
could instead send some auto message like "You have 1 new encrypted
message", but if the user happens to fetch over the public internet, then
they get any encrypted content.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Configuration for rate limited Amazon SES relay [invalid signature!]

[Sebastian Nielsen]

I think Amazon will detect this type of behaviour, eg accepting unlimited rate, 
and then "squeezing" it through amazon's rate limit system. Its possible 
because there is timestamps and other information that can be used to deduce if 
a mail has been put through a automatic rate limiter to bypass a manual rate 
limit requirement.

That’s why Amazon doesn't automatically rate-limit your mail themselves like 
many ISP system do. I guess they would limit your account or detect too high 
rate and then outright reject the mail instead. And this means they can even 
detect this type of behavior, by checking timestamps and then see that the 
mails were created with a rate more than 14 per second, but then trickled 
through the rate system.

14 mails per second is a astronomical, extremely high rate. Not even a standard 
password reset system for a fairly popular site wont come up in that types of 
rates. Yeah, a mailing list comes up in these rates naturally, but amazon have 
policies against mailing lists run from their resources too.

I think Amazon wants you to use other limits to prevent producing mails at a 
higher rate than 14 per second. Eg rate limit at the source.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Rohit Shriwas
Skickat: den 30 juni 2016 09:11
Till: postfix-users@postfix.org; postfix-users@postfix.org
Ämne: Configuration for rate limited Amazon SES relay [invalid signature!]

Hello everyone,

I have an account with Amazon SES for use by multiple services. However, Amazon 
requires me to limit the rate at which emails are dispatched to
14 per second. To this end, I've setup an SMTP relay using Postfix with the 
intent of rate limiting email dispatch locally before attempting to connect to 
SES. I _think_ I've got it right but I would really appreciate opinions, and 
possible corrections from the community as well.

Here is the configuration I have right now, I think it should limit outgoing 
mail to 10 per second. Please advise.

# Postfix MTA configuration for Amazon SES relay #

# SMTP Client Configuration
smtp_tls_CAfile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

smtp_tls_ciphers = high
smtp_tls_security_level = verify
smtp_tls_mandatory_ciphers = high

# Amazon SES Relay SASL Auth
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous smtp_sasl_tls_security_options = 
noanonymous relayhost = [email-smtp.us-east-1.amazonaws.com]:587

# Concurrency and rate limits
default_destination_rate_delay = 1s
default_destination_concurrency_failed_cohort_limit = 10 
default_destination_recipient_limit = 1

# SMTPD Server Configuration
smtpd_tls_ciphers = high
smtpd_tls_cert_file = /etc/postfix/ssl/sslcert.__comodo-chain.crt
smtpd_tls_key_file = /etc/postfix/ssl/sslcert.__comodo.key
smtpd_tls_CAfile = $smtp_tls_CAfile
smtpd_tls_security_level = encrypt
smtpd_tls_mandatory_ciphers = high
message_size_limit = 200

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes

smtpd_relay_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_auth_destination,
permit_sasl_authenticated,
reject

smtpd_etrn_restrictions = permit_auth_destination, reject





smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: poor repution work arounds? standby smtp?

[Sebastian Nielsen]

Use:
smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders

in controlled_envelope_senders, specify like:
@domain.tld useraccount, useraccount2, useraccount3
Or:
n...@domain.tld useraccount, useraccount4

The first one allows the listed accounts to send from any user of that 
domain.tld.
The second one is a strict one where you list all useraccounts authorized for 
that specific adress.

Then you use, before permit_sasl_authenticated:
reject_sender_login_mismatch

Note that you need to postmap the file controlled_envelope_senders



When it comes to countries, you as a administrator must not be scared of 
enforcing limitations. Sometimes its neccessary to say "If you travel, and you 
want to send mail, you have to set up a VPN to your home computer, simple as 
that".
Sometimes problems must be solved the "hard way", especially with all these 
spambots and malware stealing and guessing submission accounts for the purpose 
of sending spam.


Best regards, Sebastian Nielsen


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Voytek
Skickat: den 6 juni 2016 15:21
Till: postfix-users@postfix.org
Ämne: Re: SV: poor repution work arounds? standby smtp?

On Mon, June 6, 2016 10:10 pm, Sebastian Nielsen wrote:

Sebastian, thanks


> Second, the problem is that you will only get your backup server 
> blacklisted/poorreputated aswell. I would suggest solving the 
> underlying problem instead, so accounts is harder to compromise, by 
> implementing a few restrictions:

the last two issues I had were caused by single compromised sasl auth senders; 
all users are remote to server, and, since last couple years were offered smtp 
auth (instead of using local isp smtp)
>
> Theres multiple ways to solve the problem.
> 1: If your users belong to a specific office, I would suggest 
> restricting sending email from that office. If some users must have 
> remote access, give such access via a VPN instead. A spammer won't 
> connect to a dialin VPN using compromised credentials and try to find 
> a mailserver there and find compromised credentials to that too, its 
> too much trouble for too little gain.

> 2: If you run a webhosting company or something similiar, restrict 
> logins to the mail server via geoIP to the same country as the account 
> in question was bought and registred from. The country (for example 
> Sweden) they buy and register the account from, will be saved into a 
> db. When a mail is sent through submission server, check that the 
> country they are connecting from, match whatever is stored for their 
> account inside database. This will avoid account compromise as the 
> accounts can only be used in their "home countries".

some users travel, so can be different country

> 3: Needless to say,
> its a good idea to restrict so the accounts can only send from their 
> own email and the domain they either own or the domain your server is 
> authorative for.

how to implement such ? there is around 20 domains on the server





smime.p7s
Description: S/MIME Cryptographic Signature

SV: poor repution work arounds? standby smtp?

[Sebastian Nielsen]

First, most servers cache the blacklist lookup, so it will persist for 1-2 days.

Second, the problem is that you will only get your backup server 
blacklisted/poorreputated aswell.
I would suggest solving the underlying problem instead, so accounts is harder 
to compromise, by implementing a few restrictions:

Theres multiple ways to solve the problem.
1: If your users belong to a specific office, I would suggest restricting 
sending email from that office. If some users must have remote access, give 
such access via a VPN instead. A spammer won't connect to a dialin VPN using 
compromised credentials and try to find a mailserver there and find compromised 
credentials to that too, its too much trouble for too little gain.
2: If you run a webhosting company or something similiar, restrict logins to 
the mail server via geoIP to the same country as the account in question was 
bought and registred from.
The country (for example Sweden) they buy and register the account from, will 
be saved into a db. When a mail is sent through submission server, check that 
the country they are connecting from, match whatever is stored for their 
account inside database.
This will avoid account compromise as the accounts can only be used in their 
"home countries".
3: Needless to say, its a good idea to restrict so the accounts can only send 
from their own email and the domain they either own or the domain your server 
is authorative for.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Voytek
Skickat: den 6 juni 2016 11:33
Till: postfix-users@postfix.org
Ämne: ot: poor repution work arounds? standby smtp?

I have a small Postfix/Dovecot virtual server, low usage every so often a user 
account get compromised and spam sent (like couple of days ago), now I'm seeing 
5 or 6 emails 'stuck' in the queue with like:

(host mail2.abcdef.com[217.xx.xx.xx] refused to talk to me:
554-mail1.abcdef.com 554 Your access to this mail system has been rejected due 
to the sending MTA's poor reputation. If you believe that this failure is in 
error, please contact the intended recipient via alternate means.)

the single rbl has been already contacted, and, removed my IP, mxtoolbox shows 
NO blacklists, I guess 'poor reputation' will persist for a day or more

so, the question is can I set up a 'spare' mail server, in future cases when I 
end up for a day or longer with bad reputation, to switch to an alternate 
outbound smtp server... ? does it make sense..? would it work?
(trying to plan ahead from behind)

thanks for any advice
V





smime.p7s
Description: S/MIME Cryptographic Signature

SV: Different SMTP AUTH options and credentials for different clients

[Sebastian Nielsen]

You would need to use a firewall for this.
Use master.cf to define 3 different SMTP servers, that implements the 3 
different rulesets and different credentials files.
So for example, you set up 3 servers,
One at port 26 that allows relaying without authentication.
One at port 27 that allows AUTH PLAIN using credentialset A
One at port 28 that allows AUTH LOGIN using credentialset B

Then you use firewall to NAT the traffic accordingly, assuming your SMTP server 
is located at 192.168.1.90.
Like:
From: 127.0.0.0/8 : ANY to 127.0.0.1 : 25 NAT to: 192.168.1.90 : 26
From: 192.168.0.0/16 : ANY to 192.168.1.1 : 25 NAT to: 192.168.1.90 : 27
From: 123.123.88.0/24 : ANY to [WAN_IP] : 25 NAT to: 192.168.1.90 : 28

Be careful so you don't create an open relay. Test the rules carefully, and 
enable spoofing prevention in your firewall if you are going to allow something 
without authentication.
You could also combine firewalling with permit_mynetworks in the first server 
on port 26, so you get protection even if your firewall would fail to block 
packets from an incorrect IP. But best way to make sure everything is right is 
to test throughtly.

That’s how I solved so dns1.sebbe.eu and dns2.sebbe.eu does reply correctly in 
its SMTP banner, even if both dns1.sebbe.eu and dns2.sebbe.eu is really the 
very same physical machine.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Rob Maidment
Skickat: den 31 maj 2016 18:05
Till: Postfix users 
Ämne: Different SMTP AUTH options and credentials for different clients

How can I implement this in the Postfix SMTP server?

For certain client IP addresses no authentication is required and the EHLO 
response should not advertise the AUTH option.

For a second set of client IP addresses authentication is required and the EHLO 
response should advertise AUTH PLAIN.

For a third set of client IP addresses authentication is required and the EHLO 
response should advertise AUTH LOGIN.

Clients in the third set must not be able to authenticate using the credentials 
defined for the second set, and vice versa.


Rob



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Telnet auth

[Sebastian Nielsen]

Yeah, it do break forwarding where stupid mailservers (or more correctly,
mailservers configured by stupid admins) just forward the mail verbatim, and
even forge the MAIL FROM to the destination server.

That is the thing that causes SPF to fail when for example:
My server --> Receivers Company server --> Receivers Private address (not
DKIM aware).

And "Receivers Company server" is stupidly configured and forges the MAIL
FROM (instead of replacing it with a own address), and thus the Private
server reject the mail due to a SPF failure, which causes the "Receivers
Company Server" to return a DSN (since it knows that SPF is OK from their
point of view) where private server complains on the SPF. OFCOURSE the
"Receivers Company server" is not authorized to send with my domain as MAIL
FROM according to my SPF record, SPF works exactly as expected.

Same with this policy suggestion with rejecting local forgeries. Its nothing
wrong with such a policy, it’s the forwarding mailserver that are doing
things wrong if the mail gets rejected due to forwarding.

Yes, forwarders could use Sender Rewriting Scheme, but better is to actually
rewrite the mail to be able to pass the SPF policy from their own point of
view,  eg rewrite MAIL FROM to actually contain the address the mail was
originally sent to.
Like a mail sent MAIL FROM sebast...@sebbe.eu to somegr...@mycompany.org
should be forwarded as MAIL FROM somegr...@mycompany.org to
finaldestinat...@privateserver.org 


So if this breaks forwarding in some cases, blame it on the servers who are
forwarding the mail. Have had a few such failures when I send mail due to my
"Reject local forgeries" and SPF policy, then I have wrote a oozing mail to
the postmaster of the forwarding server where I tell them why their server
is so badly misconfigured. In some cases they have fixed the problem, and in
other cases they told me that it would break  here
(for example filter rules).


>Wietse:
The advantage with my example (Where I use permit_mynetworks or
permit_sasl_authenticated inside the sender_access file in addition to
reject), is that authenticated senders cannot spoof the sender domain to
something else either. So if us...@example.com tries to send as
rolexwatc...@watchcompany.com to a remote receiver (relaying), the
permit_sasl_authenticated will never be returned by the sender_access file,
and thus it will not accept the mail.
This can then be combined with the policy that only allows authenticated
senders to send as the same username as they have logged on with, which then
makes a rock solid defense against spambots running on client computers, as
they will be forced to send as the original user, and the problem can be
traced much more easily when abuse happens.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Richard James Salts
Skickat: den 19 maj 2016 01:07
Till: postfix-users@postfix.org
Ämne: Re: Telnet auth

On 19/05/16 00:38, Wietse Venema wrote:
> Wietse Venema:
>> A brief example:
>>
>> /etc/postfix/sender_access:
>>  example.com reject Sender address requires authentication
>>  other.example   reject Sender address requires authentication
>>
>> Do "postmap /etc/postfix/sender_access", then add this to main.cf:
>>
>> smtpd_sender_restrictions =
>>  permit_mynetworks
>>  permit_sasl_authenticated
>>  check_sender_access hash:/etc/postfix/sender_access
>>
>> With this, only senders in a trusted network, or authenticated 
>> senders, can do "MAIL FROM:" etc.
>>
>> This does not restrict the address in the From: message header.
> BTW this means that you have to do your "telnet" tests from a remote 
> IP address!
>
>   Wietse
And it will also break forwarding for your users. e.g. u...@example.com
sends to a mailing list that they're a member of and the mailing list
doesn't alter the envelope sender, or sends to their friend at
user2@alumni.example who has their mail forwarded back to us...@example.com.
A way to allow this but prevent forgeries would be to set up DKIM or BATV
and reject email with an invalid signature for the email or the envelope
sender.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: SV: Telnet auth

[Sebastian Nielsen]

Aah now I see. I tought colon between the key and value was something
specific to hash.
But strangely, it works both with/without colon too.
Maybe its how postmap parses the file.

However, the OPs problem is solved.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Noel Jones
Skickat: den 18 maj 2016 23:28
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: Telnet auth

On 5/18/2016 3:46 PM, Sebastian Nielsen wrote:
> It is actually possible to use multiple results when using the 
> built-in restriction commands (permit_sasl_authentication, 
> permit_mynetworks, reject,
> etc)
> (Eg, words that can be used in the rules chain instead of
> "check_sender_access")
> 
> Then they will be inserted in the rule chain just where the 
> check_sender_access is, Using processing commands like DISCARD can 
> however only be used in single.

This is correct.  Multiple "simple" actions are allowed in an access map
result. (not sure where this is documented)

> 
> And colon is used when using a hash:
> Look in your /etc/aliases and you will see.

Half wrong.  The ":" colon is specific to an alias file, and not used / not
valid for an access table.  This has nothing to do with
hash: table types.
http://www.postfix.org/aliases.5.html


  -- Noel Jones



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: Telnet auth

[Sebastian Nielsen]

It is actually possible to use multiple results when using the built-in
restriction commands (permit_sasl_authentication, permit_mynetworks, reject,
etc)
(Eg, words that can be used in the rules chain instead of
"check_sender_access")

Then they will be inserted in the rule chain just where the
check_sender_access is, 
Using processing commands like DISCARD can however only be used in single.

And colon is used when using a hash:
Look in your /etc/aliases and you will see.

Im using "permit_mynetworks, reject" in my check_sender_access without
problems. And it works exactly as expected, nobody can send a email with a
sender of @sebbe.eu , not even to a local domain, if they aren't inside
mynetworks.
Combined with a couple of DISCARD's for spammy top TLD's like .xyz, .bid,
.date.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För /dev/rob0
Skickat: den 18 maj 2016 22:36
Till: postfix-users@postfix.org
Ämne: Re: SV: Telnet auth



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Telnet auth

[Sebastian Nielsen]

Yes.
Remove permit_sasl_authenticated and permit_mynetworks.
Then add the following rule instead, immediately BEFORE
reject_unauth_destination:
check_sender_access hash:/etc/postfix/relay_auth

Inside the file relay_auth, which must be postmap:ed, you have the
following:

yourdomain.com: permit_sasl_authenticated, reject

This means when a outsider tries to send from lets say t...@yourdomain.com
to someot...@yourdomain.com without authentication, the rule evaluated will
be:
" permit_sasl_authenticated, reject, reject_unauth_destination"
The word "reject" comes before "reject_unauth_destination", thus the mail
will be rejected despite being to a allowed domain.
If you instead tries to send from a non-"yourdomain.com" domain, then the
check_sender_access will be skipped, and you will be allowed to send mail to
local accounts.

This also have another advantage: authenticated accounts CANNOT send from
another domain than your domain.

You can try for yourself. Try telnetting to this server: dns2.sebbe.eu which
is my mail server.
Then try to see if you can send spoofed mail originating from some account
inside @sebbe.eu to sebast...@sebbe.eu

(I however use IP authentication, eg only mynetworks are allowed to relay,
instead of account authentication)

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Catalin Badirca
Skickat: den 18 maj 2016 20:53
Till: D'Arcy J.M. Cain 
Kopia: postfix-users@postfix.org
Ämne: Re: Telnet auth

I will try to be more specific. Create an test account that can send emails
from postfix. Telnet on the postfix machine on port 25. Now send an email
from that test account to any other valid email on your domain. You will see
that you are allowed to do so without authentication. The whole world can do
that. 
I don't think you will want emails to be sent on your user's behalf inside
your domain. 

Is there any way postfix can stop that ?


> On 18 May 2016, at 14:08, D'Arcy J.M. Cain  wrote:
> 
> On Wed, 18 May 2016 13:22:49 +0300
> Catalin Badirca  wrote:
>> I've tried your suggestion and the issue remains. Someone could 
>> telnet into postfix and would be allowed to send mails from a valid 
>> address to another valid address in mydomain without authentication.
>> 
>> Is there any way I can stop potential spam for mydomain ?
> 
> What do you mean by "telnet into postfix"?  Are you saying that valid 
> users on your system are spamming your other users?  All you can do 
> there is monitor your own house and slap anyone who does that.  It 
> doesn't matter whether they spam their fellow users or the whole world.
> your users are your responsibility but that's not a technical issue.
> 
> If you mean that someone can connect to your port 25 and send your 
> users spam then yes, welcome to the twenty-first century and the spam 
> problem that everyone is fighting.  That's the daily fight we all 
> have.  There are a number of spam mitigation techniques that you can 
> try.  None of them are 100% effective.  You can block known spam 
> sites, use SPF, greylisting and other tools to slow down spam at the 
> SMTP level and spamassassin, bogofilter and other filters after to 
> catch suspected spam after it is accepted.  Look at spam-fighting 
> sites for some ideas.
> 
> If you do find a way to block 100% of all spam please tell us how.
> Better yet, package it and sell it.  You will be a billionaire.
> 
> --
> D'Arcy J.M. Cain
> System Administrator, Vex.Net
> http://www.Vex.Net/ IM:da...@vex.net
> VoIP: sip:da...@vex.net




smime.p7s
Description: S/MIME Cryptographic Signature

SV: domain rewrite/redirect [invalid signature!]

[Sebastian Nielsen]

Simplest way is to add mail.example.com to your mydomains. Then mails both
to t...@mail.example.com   and
t...@example.com   will arrive to the account
“test” on your server. Same is for example recommended to do with domain
literals (IP addresses like test@[123.123.123.123
 ] where 123.123.123.123 is your mailserver
IP)

 

Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Matteo Cazzador
Skickat: den 18 april 2016 12:44
Till: postfix-users@postfix.org
Ämne: domain rewrite/redirect [invalid signature!]

 

Hi, i 've a question, which is the better way to do this please:

i've a virtual domain "example.com" on this server i receive mail too from
mail.example.com

An example

any mail receive from t...@mail.example.com 
must redirect to t...@example.com  

I try with canonical maps but i obtain relay access denied when i receive
mail from t...@mail.example.com  

Can someone help me please.

Thanks





-- 
 
Rispetta l'ambiente: se non ti è necessario,  non stampare questa mail. 
 
 
Le informazioni contenute in questa e-mail e nei files eventualmente 
allegati sono destinate unicamente ai destinatari della stessa 
e sono da considerarsi strettamente riservate. 
E' proibito copiare, salvare, utilizzare,  inoltrare a terzi e diffondere 
il contenuto della presente senza il preventivo consenso, ai sensi 
dell'articolo 616 c.p. e della Legge n. 196/2003. 
Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo 
immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto 
senza procedere ad ulteriore o differente trattamento.
 
 
**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it  
Web: http://www.netlite.it
**


smime.p7s
Description: S/MIME Cryptographic Signature

SV: Special method required for Gmail dkim/spf verification

[Sebastian Nielsen]

I have noticed this aswell, when badly configured forwarding servers don't
forward their mails correctly.

For example, take a example that:
someu...@somecorporation.com
is forwarded to
some.u...@somefreewebmail.com

You send a mail to someu...@somecorporation.com
Later on, you get a DSN (because SPF validated from somecorporation.com's
point of view) that the "somefreewebmail.com" server rejected the mail due
to a SPF failure.

This is because some people don't know how to propely configure their
forwarding mail servers.
If you are going to forward a mail to a end-user specified server, you ought
to either:

Rewrite the original sender to match the mail its originally sent to, so the
mail appear as sent by "someu...@somecorporation.com", eg
A mail from "u...@example.org" to "someu...@somecorporation.com" is
forwarded as from "someu...@somecorporation.com" to
"some.u...@somefreewebmail.com"
This is not RFC compatible, and to avoid being catched in spam filters, you
also have to change the From: header in the same way.
For the receiver to correctly identify the sender and be able to reply, you
would have to include the sender email adress in the body or subject.
The reply button in this scenario then gets broken, so a replyer has to
reply manually.

Another way, that is the preferred RFC way to do it, is to encapsulate the
mail in a new message/rfc822 container, and adding Fwd: to the original
subject of the outside container.
(This is how most mail clients "forward" a message)
To reply to a message, you would have to reply to the "inner" message.

So a mail like:
From: u...@example.org
To: someu...@somecorporation.com
Subject: test
Content-Type: text/plain

Is forwarded as:

From: someu...@somecorporation.com
To: some.u...@somefreewebmail.com
Subject: Fwd: test
Content-Type: message/rfc822

From: u...@example.org
To: someu...@somecorporation.com
Subject: test
Content-Type: text/plain



Same I have noticed with web forms that are badly configured to "spoof" the
sender entered in web form, rather than sending from a "static" adress and
then displaying the original sender in the subject or body of message.


I don't know if theres a possibility to encapsulate a message in a new
message/rfc822 container in postfix, but anyways it should be possible to do
with a milter, if you want to set up a forwarding postfix server.



-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För li...@lazygranch.com
Skickat: den 14 april 2016 03:11
Till: postfix-users@postfix.org
Ämne: Re: Special method required for Gmail dkim/spf verification

On Wed, 13 Apr 2016 17:08:57 -0700
li...@lazygranch.com wrote:

> Yesterday's Google report had me passing. Could be related to adding 
> the Google term to DNS.
> 

Hold the presses here. It turns out my domain was spoofed in the report that
failed. The IP address used isn't mine. In the passing report, it was my IP
address, which makes sense since my SPF and DKIM are fine. 

The offending IP address comes back to UC Berkeley. If I ever get an
official answer regarding the event, I will do a follow up.

Needless to say, I think the DMARC quarantine is a good idea. 



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Proposal: SMTP client policy protocol (for STS)

[Sebastian Nielsen]

I would also suggest supporting standard pipes.
Like
smtp_check_tls_policy = pipe:/usr/sbin/some_script.pl

Preferable, for performance, the script will be long-running in a loop and
accept questions on  and spit out responses on 

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Wietse Venema
Skickat: den 22 mars 2016 15:29
Till: Postfix users 
Ämne: Proposal: SMTP client policy protocol (for STS)

In order to protect the stability of the Postfix SMTP client, I propose a
new feature that builds on smtp_tls_policy_maps that allows experimentation
with STS and other features.

The design is similar to the way that Postfix SMTP server policies build on
access maps.

1) An optional smtp_check_tls_policy client in the Postfix SMTP client that
speaks TCP or local IPC just like the SMTP server's check_policy feature.

/etc/postfix/main.cf:
smtp_check_tls_policy = inet:127.0.0.1:12345

2) Each query is a dump of all relevant SMTP client state, one attribute and
value per line:

query:
attribute_1 = value_1
attribute_2 = value_2
...
[empty line]

Q1: What point in time is the call made?

Q2: What attributes to send? E.g., nexthop, recipient, SMTP_SESSION,
SMTP_ITERATOR, what else?

3) The reply is exactly the same as with smtp_tls_policy_maps. The rationale
for this is to simplify implementation, user interface, and documentation
(less code to write and fewer new things to learn).

reply:
policy = [same stuff as in smtp_tls_policy_maps lookup result]
[empty line]

Is this all paractical, or will we be stuck with C code?

Wietse



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Thousands of login attempts

[Sebastian Nielsen]

I would instead suggest the opposite way around, use whitelisting instead.

Whitelisting can be done in many ways:
1: You can either whitelist your customer's IP ranges. So if one customer has 
Telia in Sweden, you tell your firewall to allow 95.196.0.0/14.
And so on for every customer/user.

2: You can geoIP. If you are only serving customers in specific regions, you 
can geoIP these as allowed in the firewall.

3: Or you can completely restrict authentication to only users inside the 
office, eg no outside access is allowed (and those that needs mail-from-home 
instead gets VPN access).

All these methods will heavily cut down on all bruteforce.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: MAIL FROM validiity

[Sebastian Nielsen]

SPF and DKIM is mail tools to prevent spoofing of non-local domains.
OP was out after tools to prevent local spoofing.

One is for example:
1: reject_sender_login_mismatch
2: Other is a check_sender_access table containing "yourdomain.com: 
permit_sasl_authenticated, reject".
3: Another one is reject_unlisted_sender

Of course, all those tools perform a completely different check and they all 
can be used in unison.
1 would prevent all mismatches between login names and MAIL FROM. However, it 
won't prevent a unauthenticated client from sending a spoofed mail from a local 
mailbox X to a local mailbox Y (I think the tables can be setup to enforce this 
for unauthenticated clients too however).
2: This prevents authenticated senders from sending outside the domain the 
server is authorative for, but also prevents any unauthenticated client from 
spoofing the MAIL FROM as a local mailbox when sending mail that is targeted to 
a local mailbox.
3: This is a tool that prevents all unknown local adresses to be used as a 
sender.


Another good thing with check_sender_access as described in 2 is that this can 
be used along with IP-based authentication (permit_mynetworks) to enforce so 
only specific domains can be used, and those domains cannot be used as a sender 
by unauthorized individuals, so even if you have SASL disabled, you can still 
enforce certain domains.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Matthias Fechner
Skickat: den 14 mars 2016 21:05
Till: postfix-users@postfix.org
Ämne: Re: MAIL FROM validiity

Am 14.03.2016 um 12:50 schrieb Pascal Maes:
> I would like that everybody who is sending mail from outside our network and 
> identified with sasl uses the email address corresponding to the uid.
> The mail should be rejected if the uid and the email address do not match.

I think a good start here is SPF and DKIM.
With this you can enforce that now other email server should accept mails thats 
are not delivered over your email servers with your own domains.

Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to build 
bigger and better idiot-proof programs, and the universe trying to produce 
bigger and better idiots. So far, the universe is winning." -- Rich Cook



smime.p7s
Description: S/MIME Cryptographic Signature

SV: MAIL FROM validiity

[Sebastian Nielsen]

The rule is still a good idea to have even if you have a rule to reject a sasl 
mismatch, because the suggested rule also rejects mail which have a spoofed 
local sender destined for a local mailbox.
Something that none of the standard rules can enforce.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Pascal Maes
Skickat: den 14 mars 2016 12:50
Till: postfix-users@postfix.org
Ämne: Re: MAIL FROM validiity


> Le 12 mars 2016 à 17:28, @lbutlr <krem...@kreme.com> a écrit :
> 
> On Mar 10, 2016, at 10:14 AM, Sebastian Nielsen <sebast...@sebbe.eu> wrote:
>> Create a file containing the following (where yourdomain.com is the 
>> domain your authenticated users send from):
>> 
>> yourdomain.com: permit_sasl_authenticated, reject
>> 
>> postmap the file.
>> 
>> Then use:
>>  smtpd_recipient_restrictions =
>>  ...
>>  check_sender_access hash:/path/to/file
>>  ...
>> 
>> Note that permit_sasl_authenticated is removed from the recipient 
>> restrictions, because that is handled by check_sender_access.
>> 
>> This will give two-fold security:
>> Anyone that is authenticated, MUST use your domain to take advantage 
>> of authentication. Eg, if they send a mail from lets say 
>> some...@someotherdomain.com it will be "relay rejected" even if they 
>> authenticate.
>> 
>> Also, the second "reject" in the map file, will force-reject anyone 
>> that attempts to use "yourdomain.com" as sender without 
>> authentication, causes everyone who tries to send a mail with your 
>> domain as sender, into a local mailbox, example:
>> 
>> MAIL FROM: ad...@yourdomain.com
>> RCPT TO: vic...@yourdomain.com
>> 
>> That sender will then be rejected with the reason that the sender 
>> address is invalid, UNLESS they authenticate before.
> 
> Ay comments on the advisability and utility of this method? At first blush it 
> seems a bit too good to be true.
> 
> What’s the catch?
> 

Well, perhaps it's working fine but it's not what I want.


I would like that everybody who is sending mail from outside our network and 
identified with sasl uses the email address corresponding to the uid.
The mail should be rejected if the uid and the email address do not match.


--
Pascal







smime.p7s
Description: S/MIME Cryptographic Signature

SV: MAIL FROM validiity

[Sebastian Nielsen]

Create a file containing the following (where yourdomain.com is the domain
your authenticated users send from):
 
yourdomain.com: permit_sasl_authenticated, reject

postmap the file.

Then use:
   smtpd_recipient_restrictions =
   ...
   check_sender_access hash:/path/to/file
   ...

Note that permit_sasl_authenticated is removed from the recipient
restrictions, because that is handled by check_sender_access.

This will give two-fold security:
Anyone that is authenticated, MUST use your domain to take advantage of
authentication. Eg, if they send a mail from lets say
some...@someotherdomain.com it will be "relay rejected" even if they
authenticate.

Also, the second "reject" in the map file, will force-reject anyone that
attempts to use "yourdomain.com" as sender without authentication, causes
everyone who tries to send a mail with your domain as sender, into a local
mailbox, example:

MAIL FROM: ad...@yourdomain.com
RCPT TO: vic...@yourdomain.com

That sender will then be rejected with the reason that the sender address is
invalid, UNLESS they authenticate before.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Pascal Maes
Skickat: den 10 mars 2016 14:54
Till: postfix-users@postfix.org
Ämne: MAIL FROM validiity

Hello,


>From time to time, one of our users is caught by a phishing attempt.
His account is then used to send spam and generally the MAIL FROM does not
match one of our addresses.

I found this to test the validity of the MAIL FROM

/etc/postfix/main.cf :

   smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders


   smtpd_recipient_restrictions =
   ...
   reject_sender_login_mismatch
   permit_sasl_authenticated
   ...

with /etc/postfix/controlled_envelope_senders (in our case)

email   uid

but that will not be easy to implement here; for example, some addresses are
used by a few people and we don't always know that.


Would it be possible to test only the existence of the MAIL FROM ?


Regards,
-- 
Pascal







smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: Security: How to limit authentication attempts?

[Sebastian Nielsen]

Another way to solve it is to use some tool that is able to manipulate the
state table, and then you prematurely expire the entires for clients that
get banned.
I googled and it seems netfilter are able to manipulate state table.
That will cause packets from banned clients to immediately be dropped after
a ban.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Kiss Gábor
Skickat: den 21 februari 2016 12:11
Till: Sebastian Nielsen <sebast...@sebbe.eu>
Kopia: postfix-users@postfix.org
Ämne: Re: SV: Security: How to limit authentication attempts?

Dear Sebastian,

> To make sure fail2ban breaks the connection, you need to put the 
> fail2ban rules BEFORE any "ESTABLISHED,RELATED" rule.

As I wrote this is what I wish to avoid if possible.
I don't want an unnecessary check against a list of banned addresses on
_every_ IP packet.

Regards

Gabor



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Security: How to limit authentication attempts?

[Sebastian Nielsen]

To make sure fail2ban breaks the connection, you need to put the fail2ban rules 
BEFORE any "ESTABLISHED,RELATED" rule.
Then it will simply drop the packets regardless of if the connection is in the 
firewall's state table or not.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: SV: SV: Blocking TLDs

[Sebastian Nielsen]

I readed that on wikipedia, and readed the sources, and one thing I can say,
is that the source is heavily misinterpreted. They refer to physical mail,
and telecommunication, where a set of rules apply to physical mail, and some
other set apply to telecommunication.
Of course, you are not allowed to tamper with third-party communication, but
if you run a mail server, then you are "in the loop" and are permitted to do
whatever you want. Nobody forces you to accept whatever you don't want into
your network. If you want to toss all HTML mail destined for your company
into /dev/null, its up to you.
This provided that you didn't unauthorizedly insert yourself into the loop.
If a end user select to use you as mail service, they have to abide by your
rules, including that some mails might get tossed away. But if you force
somebody, which aren't using your network, to use your mail service, for
example via ARP spoofing or fake Wifi AP's, then its computer intrusion.

Also, the law does not make any difference on reject or discard, either you
are allowed to block, and then it will apply to both reject and discard, or
you are not allowed to block, and then it apply to both reject and discard.
Theres no difference in rejecting or discarding, its still considered
distruption, if you do it in the wrong situation.

If I receive a call from somebody asking me to forward information to person
D, even if I say "yes, I will do", its not illegal to ignore that and not
forward the phone call. Its my phone, if someone calls my phone, they have
to abide to my rules.

Note the wording "electronic communication", which also apply to website
traffic and such. The ruling is more aiming on hackers, for example
"distrupting communications between 2 parties" is meant to target DoS, not
someone blocking certain email traffic into their network.

What I have understand, E-mail does not have any special catering, not
either in german law or swedish law. Maybe some single EU country does pay
special attention to E-mails, but normally, E-mail is same as website
traffic is same as for example Skype, and is just TCP/IP packets over the
internet. And TCP/IP packets its up to you if you want to accept, reject, or
drop packets destined for your network.

Simple as this: The mail server you run for a company, or for some user or
whatever, can be seen as your post-box outside the house. Of course, even if
you receive physical mail for other people in same house, you are fully
permitted to regulate that mail and toss mail you don't want, even if its
adressed to someone else at that adress. Compare with for example a parent
that toss away porn magazines adressed for their child, without telling
either the magazine company or the child.


Of course, a ISP mailserver is bound by much more strict rules, and here it
might be regulation prohibiting when you are allowed to reject's/discard's,
but I suspect none on this mailing list are running a ISP mailserver. (An
ISP is defined as someone who runs a access network of a specific minimum
size, wired, wireless or cellular, that people can access for a fee, where
no prior internet access is required - so VPNs don't count. A hotel wifi
wont count, it must be something larger, and being a ISP requires a special
license from the government, like a bank, because being a ISP is a community
service and must meet some minimum quality standards)


So to put it short, if you block mail in the wrong situation, it don't
matter if its reject or discard. Either you may block, then reject=allowed,
discard=allowed, or you may not block, and then reject=prohibited,
discard=prohibited.
Unless the country in question have special rules for SMTP traffic, which I
find unlikely. SMTP is TCP/IP like website traffic, IRC traffic, Skype
traffic, DNS traffic or whatever.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Robert Schetterer
Skickat: den 20 februari 2016 13:49
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: SV: Blocking TLDs

Am 20.02.2016 um 12:01 schrieb Sebastian Nielsen:
> Why are you people so negative against DISCARD, and wants to use 
> REJECT

Silent discard mail is not allowed in many EU countries, youre the postman
you dont have to deliver bombs ( virus ), you may react on marketing letters
(spam ) by sort them or simply reject at the start when you recieve it, and
only if  your customer ordered you to do so but in general you are not
allowed to burn otherones letters


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



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: SV: Blocking TLDs

[Sebastian Nielsen]

What I meant with REJECT vs DISCARD, is that with REJECT, the spammers just
switch to a new domain. And new domain, and new domain.
Like they have some script or API that instantly purchases a new domain once
their current domain gets banned in spam filters. (And yes, they do really
have valid addresses because they often write in the payload like "Reply to
sign up" and so on), and the links inside spam goes to the domain listed
after @.
That’s the bad thing with registrars that allow domain purchasing via a API.

I have witnessed it in realtime, when I continually added banned domains to
my banfile and the spammer just, nearly instant on the second I reloaded
files, switched to some new domain that was similar to the banned. And in
the log file I saw the reject, so I understood the spammer was adapting to
the spam filter. After like 5-6 domains I got fed up, changed everything
into DISCARD, and once that, all the spam from that particular source have
vanished, while I can see in logfiles that the spammer still thinks they get
something through when they really don't. 

Either they are using some domain generator algoritm, or they are just
randoming domains up using some dictionary. They also seem to know when to
change TLD, like when they got rejected on like X different banned domains
without getting a single piece through.

If everyone would use DISCARD on all the static spam filters (where you are
sure not getting false positives), then spammers will never know if they get
their spam delivered, and will not be able to optimize when to
"instant-purchase a new domain and switch to that" to maximize effectiveness
of spam campaign.

But you make a valid point about the payload. Only way to completely get rid
of payload is to use greylisting on all senders, so the spammer can't find a
"valid" domain that aren't banned, eg every domain will result in a
temporary reject.
But greylisting also delays legitimate mail.

Why are you people so negative against DISCARD, and wants to use REJECT, if
we disregard that the payload goes through the wire? Because most spams are
pretty small to not trigger through scans, so its just a few kilobytes.


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Benny Pedersen
Skickat: den 20 februari 2016 10:40
Till: postfix-users@postfix.org
Ämne: Re: SV: SV: Blocking TLDs

On 2016-02-20 00:52, Sebastian Nielsen wrote:
> 1: REJECT tells the spammer "Hey, your spam got stuck in the spam 
> filter. Wanna try again?".

if thay do, so what ?, its not possible for spammers to make remote
administoring on postfix this would be in vain anyway, and the point on
discard is accepting more payloads on recieved data, where reject stop the
payloads

> Better to DISCARD it so the spammer think they got the spam through, 
> then they won't switch to a new domain.

fair, but read above

> I don't think anyone ever will receive legitimate mail from any of 
> those spammy TLDs listed in the rules file I gave.

this  is another problem



smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: access permissions 101

[Sebastian Nielsen]

I understand fully what the reasoning is here, where you want average security 
from the ground up into the core of the server.

When I set up servers or systems, I rather prefer a really tough and hard shell 
around the network/system in question, and pretty sloppy security inside.
Like a nut. Very tough to get in, but once you´re in, theres almost no security.
That makes it a whole lot easier to administrate, since then I can easily 
integrate software more tightly in each other (for example DNS integrated with 
HTTP and SMTP and filters and everything), while I can concentrate on tight 
security at the perimeter.

Think like a apartment. Your outer door is of course closed and locked, but 
your inner doors are always open.

So I set up pretty restrictive firewall rules, and have filters, proxies and 
rules at the perimeter protection, to prevent any bad guys from getting in at 
all. On my servers, user's aren't even getting IMAP or SMTP relay access from 
the outside, since I think it’s a security risk. If they need that type of 
access, they have to use webmail, since that can be set up more securely with 
IP authorization, OTP codes and captcha security.
If I need to separate things for security reasons, I rather put them on 
separate networks in firewall with strict rules in-between, rather than 
fiddling with permissions and getting that things working.

So I think its just another way to administrate a server. Some people prefer 
average security everywhere, and some other prefer tough and restrictive 
security at the perimeter and then loose security inside. That’s why I 666's 
files to make it easier to administrate.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Martin Skjöldebrand
Skickat: den 20 februari 2016 10:26
Till: postfix-users@postfix.org
Ämne: Re: SV: access permissions 101

On 20/02/16 02:05, Sebastian Nielsen wrote:
> Everytime I need multiple processes to access the very same file and those 
> processes has interlocks that prevent them from running as the same user or 
> same group, I just "fix" the problem with 666.
>
> That is a thing I ONLY do if I get a permission error when trying to do 
> something I want to do with some software. So for example, when I want to 
> edit something from my admin panel on http://www.sebbe.eu , I just 666 that 
> file to be able to access it from the admin panel.
>
> Same, I needed to get arp working so HTTP could execute arp for detecting 
> which MAC addresses users of a captive portal had. I simply 777'd arp 
> command, because not even 755 worked for some reason, the arp command 
> required whoever that had execute permission to also have write permission.
Apologies for butting in on this discussion. The above reasoning seems to me 
deeply flawed and something I was guilty of as a Linux newbie back in the late 
90s. It is a tempting easy way out.

Rather than addressing the cause of a problem, you are attacking the symptoms 
and in the process creating unnecessary vulnerabilities in the system. At least 
that is how I read your brief description.

The problem with this, to my mind, is that it introduces sloppyness and this 
can influence future actions and sub-par "solutions" permanenting potentially 
harmful workarounds. On my own home gaming box, it's one thing, on a company or 
client server on the other hand ...

/Martin S
>
> Yeah, I agree that actually, only 644 is required on that config file. But 
> why get so angry when someone 666's a file to just get things working?
> Its not like a list of banned spam domains is something super-sensitive.
>
>
> -Ursprungligt meddelande-
> Från: Jim Reid [mailto:j...@rfc1035.com]
> Skickat: den 20 februari 2016 01:40
> Till: Sebastian Nielsen <sebast...@sebbe.eu>
> Kopia: postfix-users@postfix.org
> Ämne: access permissions 101
>
>
>> On 19 Feb 2016, at 23:52, Sebastian Nielsen <sebast...@sebbe.eu> wrote:
>>
>> but if you're hosting for example a mail server for a company, and only you 
>> as a sysadmin has shell access to the server, its no danger 666'ing files 
>> that throw permission errors. Then the file isn't really "world writable", 
>> since only you have a account on the server anyways.
> This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
> wrong. Very, very wrong.
>
> One of the fundamental principles of security is least privilege. Things get 
> the minimum permissions/access rights/whatever that are needed for the task 
> they have to perform.
>
> So for postfix only some postfix processes need to have write access from 
> time to time to specific files and directories. Almost nothing should ever 
> need write access to postfix's configuration files, except for maybe postmap 
> whe

SV: access permissions 101

[Sebastian Nielsen]

Everytime I need multiple processes to access the very same file and those 
processes has interlocks that prevent them from running as the same user or 
same group, I just "fix" the problem with 666.

That is a thing I ONLY do if I get a permission error when trying to do 
something I want to do with some software. So for example, when I want to edit 
something from my admin panel on http://www.sebbe.eu , I just 666 that file to 
be able to access it from the admin panel.

Same, I needed to get arp working so HTTP could execute arp for detecting which 
MAC addresses users of a captive portal had. I simply 777'd arp command, 
because not even 755 worked for some reason, the arp command required whoever 
that had execute permission to also have write permission.

Yeah, I agree that actually, only 644 is required on that config file. But why 
get so angry when someone 666's a file to just get things working?
Its not like a list of banned spam domains is something super-sensitive.


-Ursprungligt meddelande-
Från: Jim Reid [mailto:j...@rfc1035.com] 
Skickat: den 20 februari 2016 01:40
Till: Sebastian Nielsen <sebast...@sebbe.eu>
Kopia: postfix-users@postfix.org
Ämne: access permissions 101


> On 19 Feb 2016, at 23:52, Sebastian Nielsen <sebast...@sebbe.eu> wrote:
> 
> but if you're hosting for example a mail server for a company, and only you 
> as a sysadmin has shell access to the server, its no danger 666'ing files 
> that throw permission errors. Then the file isn't really "world writable", 
> since only you have a account on the server anyways.

This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
wrong. Very, very wrong.

One of the fundamental principles of security is least privilege. Things get 
the minimum permissions/access rights/whatever that are needed for the task 
they have to perform.

So for postfix only some postfix processes need to have write access from time 
to time to specific files and directories. Almost nothing should ever need 
write access to postfix's configuration files, except for maybe postmap when 
rebuilding hash tables. So postfix's config files shouldn’t be writable by 
anyone, not even the postfix user.

Your starting assumption is also deeply flawed. A world-writable file can be 
written to by anything, not just the UIDs who have shell accounts. There will 
be other (or should be) UIDs and GIDs allocated to other services that run on 
the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man pages, 
TeX, FTP, etc, etc. That way if one of these things has a security leak, it can 
only write to that UID’s writable files (if there are any). The breakage can’t 
contaminate anything else. But if someone is stupid enough to intentionally 
make config files world-writable, these can be damaged by a security problem in 
a rogue application. This is why the TeX user (say) doesn’t get write access to 
the DNS or mail or MySQl or configuration. That UID doesn’t need those 
privileges. So it doesn’t get them. At least, not on any sensibly managed 
computer system.

The logical extension of your approach is to make the password file, kernel, 
shared library, etc world-writable. After all, you’re the only one who has 
shell access. And you never, ever make mistakes and no software vulnerabilities 
of any sort ever occur on the servers you manage - right?

If you were hosting mail for my business and I found out you’d *deliberately* 
set 666 permissions on the mail configuration files my company depended on, I’d 
sue you for gross negligence. And win.





smime.p7s
Description: S/MIME Cryptographic Signature

SV: SV: Blocking TLDs

[Sebastian Nielsen]

1: REJECT tells the spammer "Hey, your spam got stuck in the spam filter. Wanna 
try again?".
Better to DISCARD it so the spammer think they got the spam through, then they 
won't switch to a new domain.

I don't think anyone ever will receive legitimate mail from any of those spammy 
TLDs listed in the rules file I gave.

2: Its just a habit, everytime some process complains of not able to access a 
file, "666" is the universal solution. Of course, this isn't recommended in a 
web hosting setup, but if you're hosting for example a mail server for a 
company, and only you as a sysadmin has shell access to the server, its no 
danger 666'ing files that throw permission errors. Then the file isn't really 
"world writable", since only you have a account on the server anyways.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För A. Schulze
Skickat: den 19 februari 2016 23:52
Till: postfix-users@postfix.org
Ämne: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
  - I would not suggest DISCARD but REJECT
  - mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' <sebast...@sebbe.eu>; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> <mailto:owner-postfix-us...@postfix.org>
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> <mailto:owner-postfix-us...@postfix.org>
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix.  
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?






smime.p7s
Description: S/MIME Cryptographic Signature

SV: Blocking TLDs

[Sebastian Nielsen]

First add check_sender_access pcre:/etc/postfix/banned_tlds into
smtpd_sender_restrictions in main.cf

 

Then paste all the DISCARD lines into a new file called
/etc/postfix/banned_tlds (and also add some own TLDs there, its just to copy
paste one line and then change the TLD), and also remove lines for TLDs you
don’t want to block.

Chmod the banned_tlds file to 666 to ensure the postfix process can read it.


 

Then do “service postfix restart”

Then you should be all set.

 

Test the permission by sending a email using a spoofed address in your email
software, to yourself. The mail will always be successfully sent, but:

If all goes well, you should see in the logs that “DISCARD” action was
triggered, which means the mail will be tossed in the dustbin without
delivering it to you.

Remember to return your email client to non-spoofed state after that, for
obvious reasons.

 

Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org] 
Skickat: den 19 februari 2016 23:19
Till: 'Sebastian Nielsen' <sebast...@sebbe.eu>; postfix-users@postfix.org
Ämne: RE: Blocking TLDs

 

Just copy and passed the DISCARD contents into banned_tlds?

 

From: owner-postfix-us...@postfix.org
<mailto:owner-postfix-us...@postfix.org>
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org <mailto:postfix-users@postfix.org> 
Subject: SV: Blocking TLDs

 

smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org
<mailto:owner-postfix-us...@postfix.org>
[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org <mailto:postfix-users@postfix.org> 
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Blocking TLDs

[Sebastian Nielsen]

smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Can this sort of spam be easily and safely blocked in postfix [signed]

[Sebastian Nielsen]

Oops, I meant 123.123.123.72
Just a bit tired here in the morning.

But what I wanted to say is that Microsoft is a extremely large internet
corporation, actually the largest, I think they own most IP-adresses too, so
what they do need to scale well.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Sebastian Nielsen
Skickat: den 15 februari 2016 10:53
Till: 'postfix users' <postfix-users@postfix.org>
Ämne: SV: Can this sort of spam be easily and safely blocked in postfix
[signed]

Yes, there is a reason.
If they have a large amount of virtualized servers set up using wildcarding,
like:
*.123.123.123.in-addr.arpa IN PTR mailservers.office365.com

Its of course not possible to add the corresponding forward record, because
that would create a pretty large forward zone, especially if Microsoft does
this with a large amount of IP-adresses.

Dynamically assigning reverse/forward, like *.123.123.123.in-addr.arpa IN
PTR *.mailservers.office365.com, so a server like 72.123.123.123 has a PTR
of 72.mailservers.office365.com, would require specialised name server
software, same with the forward zone, if you don't want unneccesarly large
zones.

You could however check which ASN's microsoft has, and then whitelist these
in a rule file so these IPs will be let through without any spam checking.
(Be careful however, so you don't put the whitelist too early and let
through mails you don't want to let through at all)

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Karel
Skickat: den 15 februari 2016 10:19
Till: postfix users <postfix-users@postfix.org>
Ämne: Re: Can this sort of spam be easily and safely blocked in postfix

> On 2016-02-14 18:34, Bill Cole wrote:
>
>> are there any legitimate (non-spam) senders, that would be blocked by 
>> reject_unknown_client_hostname ?
> 
> Do you consider Microsoft's Office365 to be "legitimate?"
> 
> They send substantial non-spam, yet many of their output IPs have PTR 
> addresses which yield addresses which do not resolve back to the 
> original IPs.

sorry for keep dwelling on this, but is there any reason why a legitimate
sender (ie Microsoft) would not use corresponding IP -> hostname -> IP ?

Is there some technical limitation that prevents them from doing it?




smime.p7s
Description: S/MIME Cryptographic Signature

SV: Can this sort of spam be easily and safely blocked in postfix

[Sebastian Nielsen]

Yes, there is a reason.
If they have a large amount of virtualized servers set up using wildcarding,
like:
*.123.123.123.in-addr.arpa IN PTR mailservers.office365.com

Its of course not possible to add the corresponding forward record, because
that would create a pretty large forward zone, especially if Microsoft does
this with a large amount of IP-adresses.

Dynamically assigning reverse/forward, like *.123.123.123.in-addr.arpa IN
PTR *.mailservers.office365.com, so a server like 72.123.123.123 has a PTR
of 72.mailservers.office365.com, would require specialised name server
software, same with the forward zone, if you don't want unneccesarly large
zones.

You could however check which ASN's microsoft has, and then whitelist these
in a rule file so these IPs will be let through without any spam checking.
(Be careful however, so you don't put the whitelist too early and let
through mails you don't want to let through at all)

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Karel
Skickat: den 15 februari 2016 10:19
Till: postfix users 
Ämne: Re: Can this sort of spam be easily and safely blocked in postfix

> On 2016-02-14 18:34, Bill Cole wrote:
>
>> are there any legitimate (non-spam) senders, that would be blocked by 
>> reject_unknown_client_hostname ?
> 
> Do you consider Microsoft's Office365 to be "legitimate?"
> 
> They send substantial non-spam, yet many of their output IPs have PTR 
> addresses which yield addresses which do not resolve back to the 
> original IPs.

sorry for keep dwelling on this, but is there any reason why a legitimate
sender (ie Microsoft) would not use corresponding IP -> hostname -> IP ?

Is there some technical limitation that prevents them from doing it?



smime.p7s
Description: S/MIME Cryptographic Signature

Discard all emails containing the text "#364811"?

[Sebastian Nielsen]

Is it anyway I can in postfix, use a simple rule to DISCARD all email
containing the text " #364811"?

(Its a HTML color being used in a lot (>95%) of spams currently arriving in
my server, and that color do not change).



smime.p7s
Description: S/MIME Cryptographic Signature

SV: Deliver all mail from one domain to two servers [invalid signature!]

[Sebastian Nielsen]

Try a recipient_bcc_maps using pcre:
Eg, something like this:
/^([^\@]*)\@yourdomain\.com$/ $1...@new.server.com

(first part is "match anything that does not contain a @", second is a literal 
@, and the final part is the external domain that your border server receives 
mail on)
(Note, test around with the map on a test server  connected to 2 other test 
server instances to "simulate" your setup before deploying this to a production 
server)

And then you use a transport map to deliver the new domain to the new server.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Stuart Longland
Skickat: den 9 februari 2016 06:32
Till: postfix-users@postfix.org
Ämne: Deliver all mail from one domain to two servers [invalid signature!]

Hi all,

I did a search but didn't turn up any answers.  We've got a border router that 
runs Postfix (on Ubuntu 14.04) and accepts email for a couple of domains, all 
of which gets passed to a server inside our corporate network, which is 
configured using the relay_domains and transport_maps keys.

We are in the process of commissioning a new server that will ultimately 
replace the first one.

So we'll have two servers, the existing one (with Postfix + Zarafa 6.40, Ubuntu 
10.04) and the new one (with Postfix + Dovecot, Ubuntu 14.04) both responsible 
for the same domains.

We want to have our email go to both servers simultaneously, so that we can 
flip back and forth between the two hosts as need requires.  i.e. if things go 
really pear shaped, we can switch back and we've lost no incoming email.  (We 
might need to cherry-pick some sent mail out of the new server, but that should 
be an easier job.)

Is it possible to nominate both servers as being the destinations for both 
domains so that a single email sent to user@domain is sent to both internal 
servers?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.




smime.p7s
Description: S/MIME Cryptographic Signature

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 <sebast...@sebbe.eu>
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 <sebast...@sebbe.eu>:
> 
> 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: <bou...@e42.1jour1news.fr>
> Delivered-To: sebast...@wolfgarten.com
> Received: from waldfest (localhost [127.0.0.1])
>   by waldfest.wolfgarten.com (Postfix) with ESMTP id 4154D704B9
>   for <sebast...@wolfgarten.com>; 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 <sebast...@wolfgarten.com>;
>   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 <sebast...@wolfgarten.com>; 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+ltGllwY3hZ

SV: Adding a noreply address

[Sebastian Nielsen]

I would suggest against this, since there is a risk that servers aren't 
supporting this, and might deny the mail, discard it (send it to /dev/null, 
which I do with obvious spam), quarantine it or sort it to the end user's spam 
folder.

Its better to set up a nore...@yourdomain.tld adress set to DISCARD. Doing this 
will also "circumvent" sender adress verification, which some (un-serious) mail 
systems do.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Darac Marjal
Skickat: den 27 januari 2016 11:26
Till: postfix-users@postfix.org
Ämne: Re: Adding a noreply address [Invalid]

On Tue, Jan 26, 2016 at 03:54:51PM +, Matt Bayliss wrote:
> 
>
>I'm trying to find the correct/best practice method for setting up a 
>black hole email address for such items as "noreply" addresses when 
>sending alerts from monitoring devices etc.

RFC 6854 adds the ability to use "Group Addresses" in the sender fields.  
That is, similar to how you can have "undisclosed recipients", you can have 
"undisclosed sender". So:

From: Promotional Mail Bot:;
To: Bob 
Subject: Buy More Widgets!
Date: 12th of Never

Hi Bob,

Don't forget to buy more widgets from us!

WidgetCo

The list of people in the group is optional, so you could also do:

From: Doctors Surgery:drn...@example.org,drhibb...@example.org;
...

Mind you, I've never actually seen RFC6854-syntax in the wild.

>
>I have come across a couple of tutorials which has instructions such as:
>
>
>
>" edit the /etc/postfix/aliases file and add there as bottom line:
>
>devnull: /dev/null
>
>- rebuild the aliases.db file with the command:
>
>newaliases
>
>- edit the /etc/postfix/virtual file and add as bottom line (replace 
>the [1] example.com domain with your main virtual domain):
>
>[2]blackh...@example.com devnull
>
>- rebuild virtual.db file with the command:
>
>postmap /etc/postfix/virtual
>
> 
>
>Now create a mail user or alias that is forwarded to [3]blackh...@example.com 
>... that's all!"
>
>
>
>So I don't really want to create a user on the system unless its really 
>necessary so how would I alias it, is that not already done when 
>editing /etc/ postfix/aliases.p, all I really want is a specific 
>address in the mail domain to silently accept and drop any mail sent to it.
>
>Error in log isRecipient address rejected: User unknown in local 
>recipient table; from=<> to=[4]nore...@domain.com
>
>Thanks,
>
> 
>
>
>References:
>
>[1] http://example.com/
>[2] mailto:blackh...@example.com
>[3] mailto:blackh...@example.com
>[4] mailto:nore...@domain.com

--
For more information, please reread.



smime.p7s
Description: S/MIME Cryptographic Signature

SV: 53% of Postfix servers are black-listed (DNSBL)

[Sebastian Nielsen]

I don't agree on your opinions about accepting bad email.
Accepting RFC-incompliant or spam email for local delivery is no wrong, because 
then it won't hurt someone else. Eg, if you accept spam to yourself or your own 
users, who is it gonna hurt on the internet?
Its when you are RELAYING RFC-incompliant, or even RFC-compliant email, for 
unauthorized people, that creates problems.

Also another common problem is that the default configuration (ubuntu .deb) 
allows SASL authenticated users to relay anywhere from any email. So if someone 
decides to only accept email from the outside, not relay outgoing email, and 
still some hacker out there starts a password hacker program (often called 
dictionary or brute force), which goes through all possible passwords, and then 
"u=root p=root Access Granted!" and then those details end up in some "list of 
open SMTP servers" and the servers are quickly ending up on DNSBLs.

Personally, I think the default config should be that SASL should be turned off.
Or that SASL should only be permitted for local hosts, so the only way to relay 
is to be in mynetworks AND have a valid account, and that mynetworks default 
should always be 127.0.0.0/8 and nothing else.

Another thing that you need to be aware of, is that certain DNSBLs for Open 
Relay, does not propely test open-relayness of the server. Some Open Relay 
tests just try to send a email through the server, and then bail out after RCPT 
TO, and if the server didnt reject RCPT TO, then server is listed.
This causes 3 types of servers to be listed. Those that are configured for 
global catchall, eg *@*.* is delivered to a local mailbox, certain webmail 
systems are configured this way, and those that reject unauthorized relay in 
the DATA stage, and those that DISCARD's unauthorized relay email instead of 
REJECT'ing them.

The proper way to test for relay is that the DNSBL should attempt to relay to a 
email that the DNSBL is in control of, and then programmatically checking the 
inbox of that email if the relay goes through.
This also allow the DNSBL to list the outgoing server, and not the incoming 
server, of a misconfigured open relays that uses different inbound and outbound 
servers.

When it comes to spam fighting, I have resorted to DISCARD'ing specific 
domains. Kills like 90 % of the spam.
(REJECTing won't work, spammer instantly just switch to a new domain, but 
DISCARD works perfectly, the spammer won't notice the mail got rejected).

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För sb
Skickat: den 29 december 2015 13:02
Till: majord...@cloud9.net; postfix users <postfix-users@postfix.org>
Ämne: 53% of Postfix servers are black-listed (DNSBL)


90% of global e-mail is SPAM.
91% of targeted attacks start with e-mail.

What is Postfix's share of SPAM?


A recent survey of 2.8M SMTP servers shows the following.

- 53% of Postfix servers are black-listed (DNSBL)
   http://www.mailradar.com/mailstat/mta/Postfix.html

- 44% of open relays are Postfix servers
   http://www.mailradar.com/mailstat/open-relay/

- 35% of Postfix servers are hosted in the USA
   http://www.mailradar.com/mailstat/mta/Postfix.html

Who makes Postfix?
--

   Wietse Venema
   IBM T.J. Watson Research
   P.O. Box 704
   Yorktown Heights, NY 10598, USA

What is Postfix's share of the SMTP server market?
--

A recent survey of 2.3M SMTP servers shows the following.

#1: 53.25% EXIM
#2: 32.64% POSTFIX
#3: 6.66%  SENDMAIL
http://www.securityspace.com/s_survey/data/man.201511/mxsurvey.html

What is wrong with Postfix?
---

Suppose you are a school/SME/you-name-it, you want a secure server, and you run 
Postfix. The following is what you get in your inbox.

> Date: Thu, 17 Dec 2015 15:6:1

> From: paulnoah@

> Message-ID: <8038f16fe88ca0b6a66649d005c232e9@localhost.localdomain>

> Received: from 1-160-101-156.dynamic.hinet.net ([1.160.101.156]:52001
> helo=uwtir.com) by seth.lunarpages.com with esmtpsa [...]

> Received: from localhost (localhost.localdomain [127.0.0.1]) by 
> zimbra.baycix.de (Postfix) with ESMTP id E7078416A85 [...]

> Received: from [127.0.0.1] by omp1062.mail.bf1.yahoo.com with NNFMP;
25 Dec 2015 23:24:21 -

> Received: from uhosp.example.com ([37.230.116.83])

> Received: [...]
>...
> Message-ID: [...] <---
> Delivered-To: [...]
> Received: [...]
> Received: [...]

[anonymised]
> To: <y...@your-domain.com>
>...
> Reply-To: <y...@your-domain.com>

There are more examples, and the all reduce to Postfix accepting incoming 
e-mail whose origin and envelope are not RFC compliant.

In fact, the task of writing PCRE parsers and policies is delegated to the 
user, that is you, as part of your own c

SV: allow by IP?

[Sebastian Nielsen]

You could use smtpd_client_restrictions = check_client_access
cidr:/etc/postfix/access , and then use DUNNO
For each allowed IP/subnet (note the "cidr" db type)
This will pass on the restriction to next stack.
Then you finalize with 0.0.0.0/0 REJECT

I would suggest putting check_client_access in relay restrictions instead,
because then you can accept mail for the local domain (the domain the
postfix instance handles). If the machine however never accept mail from
outside, you don't need that.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Gomes, Rich
Skickat: den 28 december 2015 22:09
Till: postfix-users@postfix.org
Ämne: allow by IP?

Good day,

I am making the switch from running Sendmail as an internal relay to using
Postfix.
With Sendmail, I can restrict relaying by IP using the /etc/mail/access
file.

I cannot seem to find an equivalent of this in Postfix.

I have read about using
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access

But it only "works" if I specifically say REJECT.
The only method that works is to use 'mynetworks_style = subnet' (test
machine happens to be on same subnet as the postfix server) but that is not
what I want

I want to put all the IPs I want to allow relay in a file and have postfix
only read that.
I don't want to put them all in main.cf, as there will be several hundred
and we do not allow entire subnets, even server-based subnets.


This is an internal relay used by internal applications that will either
pass mail off to our Exchange server (internal users) or to the internet
(external users). 
I won't need any other configuration.



Thank you in advance



Rich






smime.p7s
Description: S/MIME Cryptographic Signature

SV: Sanitizing email sent from webapp

[Sebastian Nielsen]

Now I want to know what you mean with "potential source of spam".
If you are afraid of the site getting hacked, theres nothing you can do, as
with "local postfix", I assume both postfix and the website runs off the
same machine. Regardless of which settings you do on the postfix, a attacker
can then always neutralize those settings.

If you are talking about the website getting misused by spammers to send
your files to users that haven't asked for them, I would suggest this:
Add a captcha. You could use either Google's recaptcha service, or another
good captcha system. This prevents automated spambots to use your service.

Make sure the user is not allowed to upload files that can be later sent via
email. This makes the service useless for advertising of third-party things.
If you have some facility that allows uploading of files and its intended
that users should later be able to mail these files, make sure that files
cannot be selected for sending to email if you as a admin has not approved
the file first.
(This could technically be made by having a "pending" folder and a "email"
folder. Newly uploaded files puts into the "pending" folder. When you as
admin approve a file, you just move it from "pending" to "email" folder.
Only files present in the "email" folder can be selected for sending via
email).
This prevents a spammer from uploading for example a HTML advertisement or a
JPEG containing advertisement, or a virus, and then use your service to
distribute the files.

Needless to say, the user shouldn't be able to in any way customize the text
in the email, and only one file and email address should be able to be
specified at a time.

Only allow one email per IP and E-mail address per day. This lock should be
able to be released, see later about this. So if either IP or email address
match a time-limited lock, the email is rejected.

Add 2 links in the email. First link is "I approve this email. Release the
lock". Second link is "I don't approve this email. Unsubscribe or block.".
When the user clicks the first link, the email address will be added to a
"whitelist", and the IP-lock is removed. Any email that is in the whitelist
Will not cause the client to get a 24 hour IP-lock. The link is one-use
only. Any emails sent to a whitelisted address should NOT have the approve
link.
This is then a "confirmed opt-in" so the user can send unlimited files to
himself, without getting IP-locked.
If the user sends email to address he don't control, he have to wait 24 hour
before sending a new email. Even if he first sends a email to his own
address and clicks the link, the person
Will not gain any advantage of this, since he only unlocks his own address.
The second link, does not have any timelimit, and unlimited number of uses,
will remove the email address from any whitelist. If the email was NOT on
whitelist, the user in question will be permanently IP-banned, and the email
is then put on a blacklist so it cannot receive email from your site
anymore.
(This means that if you want to go straight from whitelist to blacklist, you
have to click the link 2 times, this allows the user to unsubscribe without
getting banned)

By having this "double-opt-in" of each email, you basically make the service
useless to a spammer since he can only send one email per day to email
addresses he don't control, and unlimited
Emails to addresses he control (but then its not spam).


-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Eric Abrahamsen
Skickat: den 20 december 2015 06:59
Till: postfix-users@postfix.org
Ämne: Sanitizing email sent from webapp

I have a server with postfix running my personal and work emails, alongside
my company's website, which is written in Python/Django. The website has
some "send an email through the webapp" functionality. Back when my work
email was hosted as a Google App this was fine, I just used Google's SMTP
settings.

Now email runs through the local postfix, and I shut off several of the
functions until I had time to learn to set it up properly. I'm hoping
someone here can give some pointers so that I can avoid turning the site
into a potential source of spam.

Right now the only functionality I've left running is automatic error
emails, as that can only be sent to my address. Currently, the default SMTP
settings in the Django site look like this:

SERVER_EMAIL = post...@mycompany.com
EMAIL_HOST = "localhost"
EMAIL_HOST_USER = None
EMAIL_HOST_PASSWORD = None
DEFAULT_FROM_EMAIL = "My Company "

I don't think the above is an especially good idea, but given the
circumstances it didn't seem too risky. Here's what I hope will be all the
relevant postfix settings:

myorigin = /etc/mailname
append_dot_mydomain = no
smtpd_use_tls = yes

myhostname = mail.ericabrahamsen.net
mydomain = mail.ericabrahamsen.net
mydestination = localhost.ericabrahamsen.net, mail.ericabrahamsen.net,
 localhost, mail.mycompany.com, 

SV: non-existent users submitting email qmgr as localhost

[Sebastian Nielsen]

Then you have some local process that is compromised.

Areas to check:

Do you have a password reminder sending service?

Do you have other automated email facilies?

Check if some user on your server has became rogue

Check if some process on the server are abusing sendmail

Do you have a mailing list on the server? Check that the mailing list software 
isn’t compromised.

 

Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För Ben Greenfield
Skickat: den 17 december 2015 22:02
Till: postfix-users@postfix.org
Ämne: non-existent users submitting email qmgr as localhost

 

Hey All,

 

I’m truly lost on this.

 

I suddenly I’m receiving email at my qmgr delivered by localhost 127.0.0.1. The 
email all end in cogs.com   but none of them addresses are 
ours.

 

Search the message ID of the spoofed email and the first appearance in the log 
is always qmgr and the mail was received by localhost 127.0.0.1

 

Any ideas appreciated.

 

Ben

 

This server is on version 2.5.14

 

lex:spool root# postconf -n
alias_maps = hash:/etc/aliases,hash:/var/mailman/data/aliases
biff = no
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
enable_server_options = yes
header_checks = pcre:/etc/postfix/custom_header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mail_owner = _postfix
mailbox_size_limit = 0
mailbox_transport = dovecot
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains = 
message_size_limit = 0
mydestination = $myhostname, localhost.$mydomain,localhost, cogs.com 
 ,  mail.rowerprojectoffice.com 
 , $mydomain
mydomain = cogs.com  
mydomain_fallback = localhost
myhostname = plex.cogs.com  
mynetworks = 192.168.1.18,108.12.137.159,72.43.160.26,72.43.6.86
newaliases_path = /usr/bin/newaliases
owner_request_special = no
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
recipient_delimiter = +
relay_domains = $mydestination
relayhost = 
sample_directory = /usr/share/doc/postfix/examples
sender_bcc_maps = hash:/etc/postfix/sender_bcc
sendmail_path = /usr/sbin/sendmail
setgid_group = _postdrop
smtp_sasl_password_maps = 
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated 
hash:/etc/postfix/smtpdreject cidr:/etc/postfix/smtpdreject.cidr 
reject_rbl_client sbl.spamhaus.org   reject_rbl_client 
xbl.spamhaus.org   permit
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname 
reject_non_fqdn_helo_hostname
smtpd_pw_server_security_options = gssapi,cram-md5
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks 
check_sender_access hash:/etc/postfix/sender_access reject_unauth_destination 
check_policy_service unix:private/policy permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_tls_CAfile = /etc/certificates/mail.cogs.com  
.349E00BE0E1D924321C26D3DF0030E0CDADD6C6A.chain.pem
smtpd_tls_cert_file = /etc/certificates/mail.cogs.com  
.349E00BE0E1D924321C26D3DF0030E0CDADD6C6A.cert.pem
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_key_file = /etc/certificates/mail.cogs.com  
.349E00BE0E1D924321C26D3DF0030E0CDADD6C6A.key.pem
smtpd_tls_loglevel = 0
smtpd_use_pw_server = yes
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps hash:/etc/postfix/virtual_domains
virtual_alias_maps = hash:/etc/postfix/virtual
plex:spool root#



smime.p7s
Description: S/MIME Cryptographic Signature

Re: postfix and multiple TLS certificates (SNI support?)

[Sebastian Nielsen]

The certificate is normally validated against the MX name, not recipient domain.

Example:
emailservice1.com MX smtp1.example.org
emailservice2.com MX smtp1.example.org

Certificate is issued to smtp1.example.org

Also even if you use SNI, imagine you send a mail to a user at emailservice1 
AND also emailservice2, and you understand why not even SNI would work.

"Michael Ströder"  skrev: (15 december 2015 10:12:56 CET)
>Viktor Dukhovni wrote:
>> So, we've managed to hold off on offering SNI support for a decade
>> since TLS was integrated into Postfix 2.2.  I just wanted to see
>> whether anyone still wanted it in Postfix, but perhaps if they
>> really did they've moved on to other solutions.
>
>SNI is a prerequisite for implementing something like [1] if a host is
>MX for
>more than one recipient domain.
>
>Ciao, Michael.
>
>[1] https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: postfix and multiple TLS certificates (SNI support?)

[Sebastian Nielsen]

Yes.
Its just a draft.

The problem I see is if you send the following (assuming the following MX 
setup:)

Example:
emailservice1.com MX smtp1.example.org
emailservice2.com MX smtp1.example.org

Example SMTP transaction:

220 smtp1.example.org SMTP server ready
EHLO senderdomain.com
250-senderdomain.com hello
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-STARTTLS
250-AUTH
250 HELP
STARTTLS
(encrypted transaction follows)
MAIL FROM:<ad...@senderdomain.com>
250 Sender is okay
RCPT TO:<recipie...@emailservice1.com>
250 Recipient accepted
RCPT TO:<recipie...@emailservice2.com>
250 Recipient accepted
DATA
354 Send message data, end with a .
blah blah
.
250 Message queued for delivery
QUIT
250 Goodbye
Disconnected from host.



Which certificate should the server use for the encrypted transaction, even 
if we use SNI?

emailservice1.com or emailservice2.com?

So there is the problem, and why there is a need to use the MX identity to 
tie the certificate to the server. To protect against modified MX data, 
DNSSEC has to be used instead.


-Ursprungligt meddelande- 
From: Michael Ströder

Sent: Tuesday, December 15, 2015 10:51 AM
To: Sebastian Nielsen ; postfix-users@postfix.org
Subject: Re: postfix and multiple TLS certificates (SNI support?) [Signed]

Sebastian Nielsen wrote:
The certificate is normally validated against the MX name, not recipient 
domain.


Did you read the referenced I-D before replying?

https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs-00#section-4.1.4.1

Ciao, Michael.

"Michael Ströder" <mich...@stroeder.com> skrev: (15 december 2015 10:12:56 
CET)

Viktor Dukhovni wrote:

So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2.  I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.


SNI is a prerequisite for implementing something like [1] if a host is
MX for
more than one recipient domain.

Ciao, Michael.

[1] https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs




smime.p7s
Description: S/MIME Cryptographic Signature

SV: Is this a correct way to define PCRE lists?

[Sebastian Nielsen]

Thank you.
The reason I do use DISCARD is that REJECT simply doesn't work. I tried, if
I use REJECT, the spammer just switch to a new domain.
I noticed I got a large amount of spam from, for example *@mediablueinc.ga,
put a reject rule, then they started spamming from *@mediablueinc.com,
And so on. I then changed into DISCARD and that actually works, the spam
ceased, because the spammer won't notice they get blocked and switch to a
new domain.

Yes, im using it in main.cf. It was just that I wanted to be sure that I
didn't do something wrong so I block too much or too little.
I had a hash: list before, but now I noticed they started spamming from
certain TLD so I had to change into a pcre:.

Best regards, Sebastian Nielsen

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] För Bill Shirley
Skickat: den 13 december 2015 05:58
Till: postfix-users@postfix.org
Ämne: Re: Is this a correct way to define PCRE lists?

I don't see anything "wrong".  The default for .pcre is case independence.

I use "REJECT Spam not allowed." instead of DISCARD.

You're not escaping your period (\.com).

You can combine some of these into a single rule:
/mediablueinc\.(cf|com|ga)$/REJECT Spam not allowed (1).
/\.(top|ninja|download)$/   REJECT Spam not allowed (2).
If you number them you'll see in the log file which rule matched.


You have to use the table in main.cf.  Something like:
smtpd_recipient_restrictions =
 permit_mynetworks
 permit_sasl_authenticated
 check_sender_access pcre:/etc/postfix/my.tables/sender_access.pcre
 reject_rbl_client zen.spamhaus.org
 reject_rbl_client dnsbl.sorbs.net


Bill


On 12/12/2015 2:47 PM, Sebastian Nielsen wrote:
> I have a check_sender_access to weed out spam from spam domains.
>
> The check_sender_access is a pcre: list.
>
> And the pcre list is:
>
> /mediablueinc.cf$/i DISCARD
>
> /mediablueinc.com$/i DISCARD
>
> /mediablueinc.ga$/i DISCARD
>
> /abstreeltg.eu$/i DISCARD
>
> /\.top$/i DISCARD
>
> (Yeah, the .top domain is a spam hole. Got over 100 spam mails from 
> that TLD with random words in the domain like psoraris-doctor.top and 
> so on, and I will never get a legit mail from that spam hole)
>
> Or are im doing something wrong?
>



smime.p7s
Description: S/MIME Cryptographic Signature

Is this a correct way to define PCRE lists?

[Sebastian Nielsen]

I have a check_sender_access to weed out spam from spam domains.

 

The check_sender_access is a pcre: list.

 

And the pcre list is:

 

/mediablueinc.cf$/i DISCARD

/mediablueinc.com$/i DISCARD

/mediablueinc.ga$/i DISCARD

/abstreeltg.eu$/i DISCARD

/\.top$/i DISCARD

 

(Yeah, the .top domain is a spam hole. Got over 100 spam mails from that TLD
with random words in the domain like psoraris-doctor.top and so on, and I
will never get a legit mail from that spam hole)

Or are im doing something wrong?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Conditional Greylisting

[Sebastian Nielsen]

I think he is out after doing a temporary fail after the DATA stage, thus 
avoiding the chicken and egg problem.


-Ursprungligt meddelande- 
From: Wietse Venema

Sent: Friday, September 18, 2015 7:50 PM
To: Postfix users
Subject: Re: Conditional Greylisting

Bruce Marriner:

I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
to completely bypass greylisting.  However, if it soft-fails those
checks then I want it to greylist next.


You have a chicken and egg problem. DKIM signature verification
requires that Postfix receives the email message.  Greylisting
happens BEFORE Postfix receives the email message.

Wietse 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

Its the SPF checking that is configured to check against From: header.
The reason it says "envelope-from" is that I use a ready-made library 
(Mail::SPF) to do the dirty work, while I feed it with the "From:" header 
value as the adress to do the check against.
But you are right about the real MAIL FROM that is set to "Return-Path: 
<owner-postfix-us...@postfix.org>"


-Ursprungligt meddelande- 
From: Wietse Venema

Sent: Friday, September 18, 2015 7:43 PM
To: Postfix users
Subject: Re: Forward rejected by yahoo

Sebastian Nielsen:

Yeah, all the list mail from postfix fails SPF, at my server:
X-SPF-Signature: fail (junc.eu: Sender is not authorized by default to use
'm...@junc.eu' in 'mfrom' identity (mechanism '-all' matched))
receiver=server-desktop; identity=mailfrom; envelope-from="m...@junc.eu";
client-ip="2604:8d00:0:1::7"


That is not right. Mail from the postfix-users list has an envelope
sender "owner-postfix-us...@postfix.org", not your email address.
Otherwise, you would receive the bounces from failed mailing list
deliveries.

Wietse



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

Thats exactly what im talking about, this DMARC Strict Identity Alignment.
If a host only publishes a SPF record (no DKIM record), and sets up DMARC 
with Strict Identity Alignment, then you will need to rewrite or encapsulate 
the From: & MAIL FROM adress on any forwarded email to match your own server 
instead.


The best thing to do as I said, is to encapsulate the mail in a new 
message/rfc822 container, where the outer container will have your domain 
and your DKIM signature, while the inner container contains the original 
email, and where the outer subject contains "Fwd:" in addition to the 
original subject.

Just like you pressed "Forward" in your email client.

By doing so, you have covered so your service can forward any email, with 
any SPF/DKIM/DMARC configuration, without any problems. 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

Yeah, all the list mail from postfix fails SPF, at my server:
X-SPF-Signature: fail (junc.eu: Sender is not authorized by default to use 
'm...@junc.eu' in 'mfrom' identity (mechanism '-all' matched)) 
receiver=server-desktop; identity=mailfrom; envelope-from="m...@junc.eu"; 
client-ip="2604:8d00:0:1::7"


But I have decided to not reject SPF failing email, instead I just tag it, 
so I know, that incase my bank mails me and ask for my details, I know if 
the mail is genuine or not by looking at the SPF flag.


To cope with all sorts of misconfigurations, its better to encapsulate email 
like you press "Forward" in your mail client.


-Ursprungligt meddelande- 
From: Benny Pedersen

Sent: Friday, September 18, 2015 6:23 PM
To: Sebastian Nielsen ; postfix-users@postfix.org
Subject: Re: Forward rejected by yahoo

On September 18, 2015 4:40:52 AM "Sebastian Nielsen" <sebast...@sebbe.eu>
wrote:


If the domain has strict identity alignment set up, then From: body must
match MAIL FROM, which must match the SPF record.


postfix.org have no spf record, not my fault


Thats why you need to replace or encapsulate the From: aswell, incase the
sender domain has strict identity aligment set up.


no no no and no, cc to you so you see your error 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

No.
SPF is designed to be secure, eg you cannot add some header to bypass the 
authentication, then every phisher would add such a header.

What you need to do, is to rewrite the FROM adress or encapsulate the email.
Rewriting FROM adress can be as simple as rewriting yourn...@yahoo.com to 
yourn...@yourserver.tld , or even yourname.yahoo@yourserver.tld
Then you host a own SPF record.
The disadvantage of this method, is that it will not be possible to reply or 
answer on emails from your google account. You could however, since you know 
the domain and username, manually write the correct @yahoo.com adress in the 
“to” field when replying to a email.

Another way, is to encapsulate the email in a new message/rfc822 container, 
where the outer container contains like From: forwar...@yourserver.tld To: 
somen...@gmail.com , Subject: Fwd: Original Subject
And then the inner container contains:
From: yourn...@yahoo.com
To: yourn...@yourserver.tld
Subject: Original Subject

The advantage with this method is that you can reply to the email by replying 
to the inner container. This is how most email clients forward email, by 
encapsulating them.
In most cases, a email client will either show a iframe showing the original 
content, a button to open the mail in a new window, or a attached file that can 
be opened to show the mail.

Of course, its important that you do publish a own SPF record.
And also, its a bad idea to forward spoofed email, since this could get your 
domain “blacklisted” at google, thus its a good idea to SPF and/or DKIM check 
any incoming email on your forwarder adress before forwarding them.

From: Il Neofita 
Sent: Thursday, September 17, 2015 7:40 PM
To: postfix-users@postfix.org 
Subject: Forward rejected by yahoo

Hi,

I have the following problem if I forward an email received from yahoo to an 
other yahoo account the message is rejected.

If I send a message from yahoo -> my server and forwarded to a google account 
the message is marked as spam, since is considered a spoofed.


Can I fixed this adding some header?


Thank you


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

The best thing here is to set up a header filter that replaces first From: 
header with your adress, and first To: header with the destination gmail adress.
To prevent that any spam blacklisted adresses appear, discard every to: and cc: 
header after this.
Then you ensure the MAIL FROM in the SMTP communication with gmail, states your 
adress and not Yahoo’s. Add a SPF record to your domain, and then you are done.

If you want to go the encapsulation way, it gets a little bit more complicated, 
and you need some sort of milter or post-processing filter to encapsulate the 
email.

From: Il Neofita 
Sent: Thursday, September 17, 2015 8:12 PM
To: Sebastian Nielsen 
Cc: postfix-users@postfix.org 
Subject: Re: Forward rejected by yahoo

Thank you very much for the fast reply.

I was looking on sieve or postfix and I do not find how I can do it.

Since I believe that will be the best way to do it.

Can you help me out?


Thank you



On Thu, Sep 17, 2015 at 1:51 PM, Sebastian Nielsen <sebast...@sebbe.eu> wrote:

  No.
  SPF is designed to be secure, eg you cannot add some header to bypass the 
authentication, then every phisher would add such a header.

  What you need to do, is to rewrite the FROM adress or encapsulate the email.
  Rewriting FROM adress can be as simple as rewriting yourn...@yahoo.com to 
yourn...@yourserver.tld , or even yourname.yahoo@yourserver.tld
  Then you host a own SPF record.
  The disadvantage of this method, is that it will not be possible to reply or 
answer on emails from your google account. You could however, since you know 
the domain and username, manually write the correct @yahoo.com adress in the 
“to” field when replying to a email.

  Another way, is to encapsulate the email in a new message/rfc822 container, 
where the outer container contains like From: forwar...@yourserver.tld To: 
somen...@gmail.com , Subject: Fwd: Original Subject
  And then the inner container contains:
  From: yourn...@yahoo.com
  To: yourn...@yourserver.tld
  Subject: Original Subject

  The advantage with this method is that you can reply to the email by replying 
to the inner container. This is how most email clients forward email, by 
encapsulating them.
  In most cases, a email client will either show a iframe showing the original 
content, a button to open the mail in a new window, or a attached file that can 
be opened to show the mail.

  Of course, its important that you do publish a own SPF record.
  And also, its a bad idea to forward spoofed email, since this could get your 
domain “blacklisted” at google, thus its a good idea to SPF and/or DKIM check 
any incoming email on your forwarder adress before forwarding them.

  From: Il Neofita 
  Sent: Thursday, September 17, 2015 7:40 PM
  To: postfix-users@postfix.org 
  Subject: Forward rejected by yahoo

  Hi,

  I have the following problem if I forward an email received from yahoo to an 
other yahoo account the message is rejected.

  If I send a message from yahoo -> my server and forwarded to a google account 
the message is marked as spam, since is considered a spoofed.


  Can I fixed this adding some header?


  Thank you



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Forward rejected by yahoo

[Sebastian Nielsen]

If the domain has strict identity alignment set up, then From: body must 
match MAIL FROM, which must match the SPF record.
Thats why you need to replace or encapsulate the From: aswell, incase the 
sender domain has strict identity aligment set up.


-Ursprungligt meddelande- 
From: Benny Pedersen

Sent: Thursday, September 17, 2015 11:26 PM
To: postfix-users@postfix.org
Subject: Re: Forward rejected by yahoo

Sebastian Nielsen skrev den 2015-09-17 19:51:


Then you host a own SPF record.


no no no no and no

SPF is not From: body header

do you think about SenderID ?

sid-milter test both, SenderID is depricated with a replacement of DKIM 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: keeping off brute force password attempts

[Sebastian Nielsen]

My suggestion is instead extending the logic to prevent bruteforce instead.

For example:
If you run a webhosting company, use geoIP to disable logins to accounts 
that do not originate from the same country as their payment method.
Since this rule are set up account-wise, you can still easily target the 
whole world, since a USA customer will only be able to login from USA and a 
Sweden customer will only be able to login from Sweden.


Another way, is for example to restrict logins to the only very same range 
that they used first to login. This allows dynamic users to use your 
mailservice, while HEAVILY cutting down on bruteforce. For example, if I 
login today to your mail service with IP 94.185.86.58, the login will be 
restricted to 94.185.80.0 - 94.185.87.255 (even if the above IP in fact is a 
static IP, I just gave a example how you could make sure dynamic users are 
not constantly locked out when their IP change)
This can be easily checked in the whois. And the whois lookup only needs to 
be done when a login to the control panel or webmail is done from a new IP 
location.

This will cut down on bruteforce extremely much.

To allow a customer to bypass this restriction, you could have some control 
panel, of course protected with Captcha and relevent web anti-bruteforce 
techniques, where they can access a control panel and add/remove ranges 
and/or countries as wish, if they for example is going for travel or needs 
to login from a new location.
To make it easier for the customer, you could easily have such as when they 
login to webmail or control panel with valid Captcha and username/password, 
the IP range or country of the remote host is automatically added as 
authorized.


-Ursprungligt meddelande- 
From: Ram

Sent: Saturday, September 12, 2015 8:55 PM
To: Postfix users
Subject: keeping off brute force password attempts

I am seeing a surge in the number of password attempts both at my
postfix smtp servers as well as imap servers
These attacks seem to be targetted since the attempts are made at
correct userids

At one instance I have seen mails being sent impersonating a valid
sender asking for money to be transferred for some service. This makes
it very risky.

I tried implementing banip and blocked a few ips but that did not work
for long. Many customers are behind a single gateway and when someone
has an old account configured on some device the number of failed
attempts cross threshold easily. So I end up blocking a good ip address



I guess this must a common problem. Is there a standard "good practices"
list to keep these scammers/spammers off 



smime.p7s
Description: S/MIME Cryptographic Signature

Problem filtering broken PGP mail with body_checks

[Sebastian Nielsen]

Im trying to filter broken PGP mail into usable mail with body checks.
I have selected to use pcre: when defining body_checks.

The problem is that certain PGP useragents, inserts a \r charachter, a tab, 
space, or any other whitespace char immediately before or after the “-BEGIN 
PGP MESSAGE-“ header.

So the rule is as follows:
/[ \t\r\f]*-(BEGIN|END)([^-]*)-[ \t\r\f]*/ REPLACE -$1$2-

The problem with this, is that this removed the whole body of the mail except 
for the -BEGIN PGP MESSAGE- line.

What are im doing wrong? I have tried with different flags like /s or /si and 
such, but still it removes the whole body.
I want it to scan line for line and process it.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problem filtering broken PGP mail with body_checks

[Sebastian Nielsen]

Yep. On top of that: ([^-]*) means any charachter except for -, so it 
shouldn't match any -, and thus $2 cannot contain the charachter "-" at all.


I suspect that postfix in some way matches the whole message in once, and 
when the REPLACE word is given, the whole message, even including parts of 
message that does not match the regexp, are replaced by the "REPLACE". But I 
tried with (.*) before and after, and added $1 to the beginning and $4 to 
the end, and also changed $1$2 to $2$3, but that didnt help.


-Ursprungligt meddelande- 
From: Stuart Longland

Sent: Saturday, September 12, 2015 12:29 AM
To: postfix-users@postfix.org
Subject: Re: Problem filtering broken PGP mail with body_checks [Invalid]

On 12/09/15 08:24, Stuart Longland wrote:

This is just a wild guess on my part, but could that possibly be matching:


> -BEGIN BLAH-

   ^^^

> yadda yadda yadda

  ^

> -END BLAH-

  ^

and giving you: $1="BEGIN", $2=" BLAH-\r\nyadda yadda
yadda\r\n-END BLAH"?


And as most wild guesses, they can be wildly inaccurate.  Just realised
what the substitution would look like in that case.  Apologies for the
noise.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
 ...it's backed up on a tape somewhere.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: SPF and forwarding

[Sebastian Nielsen]

No. Thats whats SPF is designed to prevent. Else every phisher would claim 
they forwarded the email, to bypass the whole SPF security system.


There is two options here, except for disabling forwarding altogether and 
require gmail owners to fetch instead:


Either, you replace the MAIL FROM and the From: altogheter with a mail 
adress on your system. It could be something like 
someuser@somedomain.invalid is rewritten to 
someuser.somedomain.inva...@example.org where example.org is the domain 
your server is authorative for.
This is however incompatible with RFC. But it will atleast solve any SPF 
problems since the SPF will be validated against your domain. Remember to 
set up a own SPF record AND also check SPF on incoming mails.


Or you encapsulate the old mail in a new message/rfc822-container. This is 
the RFC way to do it.
When you encapsulate, embed the original mail in a new message/rfc822 
container, Containing the following headers:
From: forwar...@example.org (This is a mail adress on your system, 
preferable the email adress the mail was originally sent to)

To: [target gmail adress mail is forwarded to]
Subject: Fwd: [Original Subject]
Content-Type: message/rfc822; boundary=xyz

(This is how a mail client forwards a email when you ask the mail client to 
forward the original email as-is)
In gmail, they will get the inner container as a .eml attachment inside the 
gmail web viewer, that can be opened to read the mail inside with Cloud EML 
Viewer, or viewed locally on computer with their local email application. 
Some mail clients will show the inner container like a iframe, some email 
clients will show a button that will expand or open the inner container.



-Ursprungligt meddelande- 
From: Alex

Sent: Sunday, July 26, 2015 3:04 AM
To: postfix users list
Subject: SPF and forwarding

Hi,

I have a postfix-2.10.5 server on fedora, and have several users that
forward their mail through to gmail. This is apparently enough to
break SPF and make gmail think I'm the originator of the email,
instead of the actual sender. Consequently, gmail considers it spam
and moves it to a spam folder.

Is there anything I can do, including somehow rewriting the email, to
get gmail (and others, for that matter) to accept these forwarded
emails without considering them spam?

Can they be rewritten using our SPF information, somehow?

I've included the header (modified user/IP addresses) in case it's helpful.

Delivered-To: origu...@gmail.com
Received: by 10.13.203.214 with SMTP id n205csp587551ywd;
   Sat, 25 Jul 2015 06:39:29 -0700 (PDT)
X-Received: by 10.55.25.131 with SMTP id 3mr28553330qkz.85.1437831569919;
   Sat, 25 Jul 2015 06:39:29 -0700 (PDT)
Return-Path: earl.ma...@example1.com
Received: from orion.example.com (orion.example.com. [68.111.111.42])
   by mx.google.com with ESMTPS id 
f79si14214872qki.10.2015.07.25.06.39.29

   for exam...@gmail.com
   (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
   Sat, 25 Jul 2015 06:39:29 -0700 (PDT)
Received-SPF: neutral (google.com: 68.111.111.42 is neither permitted
nor denied by best guess record for domain of earl.ma...@example1.com)
client-ip=68.111.111.42;
Authentication-Results: mx.google.com;
  spf=neutral (google.com: 68.111.111.42 is neither permitted nor
denied by best guess record for domain of earl.ma...@example1.com)
smtp.mail=earl.ma...@example.com
Received: by orion.example.com (Postfix)
   id 4DC19A60368; Sat, 25 Jul 2015 09:39:29 -0400 (EDT)
Delivered-To: supp...@example.com
Received: from localhost (localhost [127.0.0.1])
   by juggernaut.example.com (Postfix) with ESMTP id CB94A181A9E
   for supp...@example.com; Sat, 25 Jul 2015 09:39:28 -0400 (EDT)
X-ActualMessageSizeBytes: 41474
X-ActualMessageSize:
X-Virus-Scanned: amavisd-new at example.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level:
X-Spam-Status: No, score=-0.399 tagged_above=-200 required=5
   tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOC_CDIS_INLINE=0.1,
   LOC_IMGSPAM=0.1, RDNS_NONE=0.8, RELAYCOUNTRY_LOW=0.5]
   autolearn=no autolearn_force=no
Received: from relay.example1.com (relay2.example1.com [206.111.111.44])
   (using TLSv1 with cipher AES128-SHA (128/128 bits))
   (No client certificate requested)
   by juggernaut.example.com (Postfix) with ESMTPS id 71AC0180271
   for supp...@example.com; Sat, 25 Jul 2015 09:39:21 -0400 (EDT)
Received: from HQXCHA402.example1.com ([fe80::e4d8::53e5:e9d2]) by
HQXCHA401.example.com ([fe80::7199::b314:a497%25]) with mapi id
14.03.0224.002; Sat, 25 Jul 2015 06:39:19 -0700
From: Operations o...@example1.com
To: Support supp...@example.com
CC: Operations o...@example1.com
Subject: User List Request
Thread-Index: AdDG30D3+GNpY2bR+6PMmxGK/70Bw==
Sender: Marsh, Earl earl.ma...@example1.com
Date: Sat, 25 Jul 2015 13:39:19 +
Message-ID: 68fcc58030b4164e802bb27ff159fe0535e6b...@hqxcha402.example.com
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes

Re: Question about DSN

[Sebastian Nielsen]

As the subcodes say that transformation was required for delivery, it 
sounds like the mail was converted across formats, or content was omitted. 
This can happen if a server decides to strip all attachments or the mail did 
contain something unparseable that the server decided to pass along without 
touching or omitting the unparseable content altogether.


Note how it says X.6.0, where for example 5.6.0 would indicate unsuccessful 
delivery due to undefined media error, while 2.6.0 would indicate that it 
was a successful delivery despite the error.


-Ursprungligt meddelande- 
From: Michael Peter

Sent: Thursday, July 02, 2015 6:36 PM
To: postfix-users@postfix.org
Subject: Question about DSN

Hi,

for postfix log file /var/log/maillog, we notice that following line

1198B1E111: to=u...@example.com,
relay=mail.example.com[XXX.XXX.XXX.XXX]:25, delay=20,
delays=4.3/0.01/1.8/14, dsn=2.6.0, status=sent (250 2.6.0 Queued mail for
delivery)

The DSN is 2.6.0 INSTEAD of 2.0.0,

is DSN is 2.6.0 is considered successful delivery? because according to
the rfc3463

rfc3463:

2.XXX.XXX   Success

Success specifies that the DSN is reporting a positive delivery
action.  Detail sub-codes may provide notification of
transformations required for delivery.

X.6.0   Other or undefined media error

Something about the content of a message caused it to be
considered undeliverable and the problem cannot be well
expressed with any of the other provided detail codes.


So this means that 2.XXX.XXX is considered delivered without problems..
but in the same RFC is says that 2.6.0 means undelivered error...

So i am confused  if DSN=2.6.0 means that the email is accepted without
problems? and why the receipt mail server is giving 2.6.0INSTEAD of 2.0.0
?? why receipt server would give DSN2.6.0 ?

I appreciate your feedback.

Thanks

Michael Peter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: encrypt incoming emails with my public gpg key

[Sebastian Nielsen]

I would suggest using Ciphermail / Djigzo for this.
But I think you are solving your problem in a very incorrect way. Since the 
hosting company do have access to the VM, they could easy listen on the 
memory before the mail is encrypted, just after it has been decrypted by the 
TLS handler.


If you only are worried by backups or other copies that might come in the 
wrong hands, and not someone directly accessing the server, I would suggest 
setting up a encrypted storage in the server. Since VPS/VM in many times 
give you root access, you could easily set your virtual machine to be 
encrypted with LUKS, and then you have to type a password each time the VM 
boot.

Any backups made of the VM will then be encrypted.

-Ursprungligt meddelande- 
From: Thomas Keller

Sent: Wednesday, June 03, 2015 12:48 AM
To: Postfix users
Subject: encrypt incoming emails with my public gpg key

Hello,

my Postfix server is running as a VM in a hosted (untrusted)
environment. In theory, the data on the server (i.e. my emails) could be
on some backup tape, or copies could be lying around in the datacenter.

Some of my emails are encrypted (people send me encrypted emails) but
most are not.

Would it be possible / what would be the best way to set up some filter
in Postfix, so that all plaintext emails would be encrypted upon
delivery with my gpg public key. In effect, if would like like all
people send me encrypted emails.

What would be the best way to achieve this ? 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: encrypt incoming emails with my public gpg key

[Sebastian Nielsen]

Thats why its important to define which security goal your setup has.

If you really want to PGP-encrypt your mails at receive, you can do it with 
Ciphermail:

https://www.ciphermail.com/
Ciphermail is implemented as a SMTP proxy, so you just feed postfix's 
smtp-client into ciphermail and then have a localhost-only listening smtpd 
which delivers to local storage.


But to your points:
1: If your WM is remotely manageable via SSH, you will also have access to 
its boot over SSH/IPMI or whatever remote interface your hosting company 
uses.
2: Yes agree. But one thing to consider, is that if you have hosting with 
VM's or VPS:es, its common that they make a backup of your machine, eg they 
backup your machine as-is. This means that when your hosting company takes 
the backup, it will still be encrypted.
Eg, even if they take the backup while the machine is in running state, it 
will still be a backup of the offline image of machine, which will 
represent how the machine will look if it was turned off and then turned on 
right now, since LUKS never write plaintext to the disk drive. RAM contents 
of the VM is usually not written to disk or backuped at all since it can 
contain sensitive data.
3: Yes thats true. But that is true for any non-encrypted mail that is 
received on your server, since they could, if they were dishonest, tap the 
mail from the RAM of the server, like they could with the LUKS key. No 
on-server encryption is going to solve if your hosting company is rogue.
In your first mail, you described the hosting company for being untrusted 
because they were reckless and unresponsible with backups and copies of 
offline-data that could linger around in the datacenter and fall into the 
wrong hands.


If the hosting company is completely untrusted with not just lazy/reckless 
employees, insead just dishonest employees that could itself be rogue, 
theres only 2 options:
A: Encrypt the mail before it reach the hosting company. For example 
receiving mails in a another server, encrypting them with ciphermail and 
then forwarding the encrypted mails to the hosting company.

B: Change hosting company to a more trusted one.

-Ursprungligt meddelande- 
From: Thomas Keller

Sent: Wednesday, June 03, 2015 1:32 AM
To: postfix-users@postfix.org
Subject: Re: encrypt incoming emails with my public gpg key

On 2015-06-03 01:16, Sebastian Nielsen wrote:


If you only are worried by backups or other copies that might come in
the wrong hands, and not someone directly accessing the server, I would
suggest setting up a encrypted storage in the server. Since VPS/VM in
many times give you root access, you could easily set your virtual
machine to be encrypted with LUKS, and then you have to type a password
each time the VM boot.


using LUKS has some disadvantages here:
1) somebody has to type remotely the password every time the machine
boots. This is very impractical

2) LUKS is only effective when the machine is turned off. Once LUKS is
mounted (decrypted) data can be read and encryption key recovered

3) if ever, somebody gains access to the decryption key (see 2) all
emails ever received are accessible.

Besides, for the sake of argument, we can assume that I already have
LUKS, but want to have another layer. These two things are not mutually
exlusive. 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Need advice from SPF/DKIM/DMARC experts

[Sebastian Nielsen]

I would suggest explicity null:ing the SPF signature instead of passing it, 
for list mail.

This is done with v=spf1 ?all

A null SPF signature is same as no signature at all (same as if the SPF 
record didnt exist at all), which will pass your mail into your mailsystem, 
but the mail will not be explicity marked as genuine.
A even better idea for your list subdomain is to make the SPF record 
low-TTL, and then use a script/webinterface or whatever to update the list 
of authorized IPs everytime you subscribe to a new mailing list.


Then you don't risk that your list subdomain become a phishing source due to 
that it allows fraudulent source adresses. Another thing is that your domain 
(not IP) risk getting on spam blocklists (RBL) if spam is found
out to have a authorized SPF signature, which can happen if someone spoof 
your email domain.


-Ursprungligt meddelande- 
From: Robert Senger

Sent: Monday, May 25, 2015 3:50 PM
To: postfix-users@postfix.org
Subject: Need advice from SPF/DKIM/DMARC experts

Hi all,

this is not a Postfix specific question, but I hope I'll find some
experts on that topic here ;)

A long time ago I've implemented SPF/DKIM/DMARC signing/checking for the
two domains served by my Postfix instance. As everything seemed to work
fine, I recently moved from permissive to strict policies.

I know that this breaks interoperability with most mailing list agents,
and thus I've set up a subdomain with its own SPF/DKIM/DMARC settings
which I want to use especially for mailing lists (like
postfix-users@postfix.org). In fact, this email is a first test of my
new setup ;)


These are my new DNS settings for one of the domains and its subdomain:



$ORIGIN microscopium.de.
; SMTP SPF
   IN TXT  v=spf1 +ip4:88.217.187.146 
+ip6:2001:470:6d:976::1 -all
   IN SPF  v=spf1 +ip4:88.217.187.146 
+ip6:2001:470:6d:976::1 -all

; SMTP DMARC
_dmarc  IN TXT  v=DMARC1; p=reject; sp=none; 
rua=mailto:postmas...@microscopium.de; 
ruf=mailto:postmas...@microscopium.de;;

; SMTP DKIM
_domainkey  IN TXT  o=-; r=postmas...@microscopium.de
mail._domainkey IN TXT  v=DKIM1; k=rsa; 
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6mbWGI0yAXY0IoxIvV1L5GXdGAErO7W9ZIqa+cFgTJSNz3sYb5dYFVlI32igQGbDmegFrpUOhApwhe59K+WPONoxggQ/kaJWQ3vkVET/z9zV4PWRwYqOWnJZzoWsS8H6N3775TYo47QI/Ie3X/FGX0D99wymhCwMDhU+G8st9Q+8PIgGQp38NuAx+ 
hmuOKVBNAX6sVv7Ip3Lw6QNgRfKCFYbNFro982myjqnNEVQFim5+XCv7WRDuYOKnQM1ZXsHpjew96XmdeDMK6mhHz2R0K4RGnR1+GFS3DoXiodfMvp4CKTAL96Pi7TtyPSBYnth2I989Zbs6CWNxNiGnFqVKwIDAQAB

_adsp._domainkeyIN TXT  dkim=discardable



$ORIGIN lists.microscopium.de.
; SMTP SPF
   IN TXT  v=spf1 +all
   IN SPF  v=spf1 +all
; SMTP DMARC
_dmarc  IN TXT  v=DMARC1; p=reject; 
rua=mailto:postmas...@microscopium.de; 
ruf=mailto:postmas...@microscopium.de;;

; SMTP DKIM
_domainkey  IN TXT  o=-; r=postmas...@microscopium.de
mail._domainkey IN TXT  v=DKIM1; k=rsa;  
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Sw5pD8imtRZ3HzKPMbT99BPW2fCqWCTMAEwl5UMYAefgpDS8xzI0f8BX3eY2mgHNid9B18fujUtIPhykuEwMq2XVcoC+5uljr2jmLuaQwIPth2A/A4mtSMABvZmR/2wS96iY6oshHRaAciXtsS0G3vw3BU+8ga5OWg30C6C6H/8QbDjfczQZMaN+qVTYh3xPldTKQaFOIMPS7 
/eIBrQGXUXw1uV5DcAZX3OKqrBbD54vc9lBdGdcg/qAANZQWWn+EjZq7mQ6Szcq0jHKdAId4clcE6QRUfZOJHlbIQteo0ngOJ5gCrsyPO+GxAgQhql91xJMg3S9W9KIen/GYWB6wIDAQAB

_adsp._domainkeyIN TXT  dkim=discardable



In my understanding, for mail sent from the subdomain to a mailing list,
any final recipients DKIM check should result in pass (as the original
DKIM signature is still present), and SPF check should also result in
pass as the SPF v=spf1 +all statement allows any ip (which now is
the ip of the mailing list MTA, not mine) as sender for the subdomain.
But I am a bit uncertain about how the SPF/DKIM/DMARC settings of the
parent domain impact the subdomain.

Is that a good/working/safe setup, or am I doing anything stupid/nasty
here?

Thanks for help,

Robert


--
Robert Senger




smime.p7s
Description: S/MIME Cryptographic Signature

Re: problem with spam

[Sebastian Nielsen]

I suspect any of your authenticated users are compromised, eg that a 
dictionary-attacking or brute-forcing bot managed to figure out the password 
for one of your accounts. I had authentication enabled on my server once, 
and you know, the logs were HUGE with 'bots' trying to authenticate with 
a invalid password to the 'postmaster' and 'root' account. Guess these bots 
were running some sort of dictionary attack on my server.


You can use master.cf and a firewall, to ensure that SASL authentication is 
disabled (eg no relaying allowed) if the user is not from a valid IP range.
Eg, for the port 25 server, you disable sasl authentication. If you have 
permit_sasl_authenticated in your relay security settings, then it will 
completely disable relaying for the port 25 server.
Then for the port 587 server (submission) that still have SASL enabled, you 
add a firewall rule topmost, that is, lets say your authenticated users mail 
from 80.216.0.0/16, then add a rule as following:


Source: NOT 80.216.0.0/16
Source port: Any
Target: Your server IP
Target port: 587
Action: Drop

Then it will easily weed out all pass-cracking spambots, they wont even be 
able to connect.
The above suggestion, will enforce so your server will BOTH require a 
correct username/password *AND* that the user is coming from a authorized 
source IP.


However, remember to tell your users that they will no longer be able to 
send email while they are not on your premises/authorized locations. The 
users will however be able to receive email as before, so
they can easily use a private gmail/hotmail account to reply to email that 
they get while off-premises.



-Ursprungligt meddelande- 
From: Christos Chatzaras

Sent: Sunday, May 24, 2015 12:32 PM
To: postfix-users@postfix.org
Subject: problem with spam

Μy server with IP 178.63.64.86 is blacklisted at http://cbl.abuseat.org for 
stealrat spambot. My mail server is configured to send only e-mail from 
authenticated users. Also local users (from shell) can't send e-mail and 
also mail() php function is disabled too. I got this e-mail from hotmail ( 
http://pastebin.com/raw.php?i=D6fFDUYH ) that shows that my mail server send 
e-mail from marcella_sha...@akrogiali-restaurant.gr to sir...@hotmail.com , 
but on the logs there is no entry that e-mail sent to sir...@hotmail.com . 
Any idea what may be the problem ? 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: problem with spam

[Sebastian Nielsen]

Aaah, then its a bit worser problem.
Are all your customers from a specific country?
Then you can add a geoIP block to your firewall so customers can only send 
email from their country.

Else:
My suggestion is then that you open up a web interface (I guess you already 
have a web interface where your customers can manage their account).

Then you provide a function, where the customer can specify up to X IP-ranges, 
that is allowed to authenticate on SMTP level on their account, and those 
ranges must at least be /8, to prevent customers from specifying 0.0.0.0/0 and 
allowing the whole world.

You can propably use a policy server or some maps to ensure certain accounts 
only can authenticate from specific IP ranges.
So each customer do have their own authorization list.

Note that your web interface can also be hacked, so ensure its protected with a 
captcha and make accounts locked down to the customer’s billing country, or 
employ 2FA authentication.
From: Christos Chatzaras 
Sent: Sunday, May 24, 2015 1:01 PM
To: Sebastian Nielsen 
Cc: postfix-users@postfix.org 
Subject: Re: problem with spam

I do shared hosting, so users should be able to use any ISP to connect.

postconf -Mf :

smtp   inet  n   -   n   -   -   smtpd
submission inet  n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=may
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING
smtps  inet  n   -   n   -   -   smtpd
   -o smtpd_tls_wrappermode=yes
   -o smtpd_sasl_auth_enable=yes
   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
   -o milter_macro_daemon_name=ORIGINATING
pickup fifo  n   -   n   60  1   pickup
cleanupunix  n   -   n   -   0   cleanup
qmgr   fifo  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewriteunix  -   -   n   -   -   trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
   -o smtp_fallback_relay=
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discardunix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache

postconf -nf:

authorized_submit_users = root, creta
body_checks = regexp:/usr/local/etc/postfix/body_checks
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb
   $daemon_directory/$process_name $process_id  sleep 5
default_destination_concurrency_limit = 2
default_destination_rate_delay = 1s
default_extra_recipient_limit = 10
header_checks = regexp:/usr/local/etc/postfix/header_checks
html_directory = /usr/local/share/doc/postfix
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 2560
myhostname = server8.cretaforce.gr
mynetworks_style = host
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
sample_directory = /usr/local/etc/postfix
sender_dependent_relayhost_maps = hash:/usr/local/etc/postfix/sender_transport
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_bind_address = 178.63.64.86
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 1s
smtp_extra_recipient_limit = 10
smtp_tls_CAfile = /etc/ssl/certs/cacert.crt
smtp_tls_cert_file = /etc/ssl/certs/server8.pem
smtp_tls_key_file = /etc/ssl/private/server8.pem
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache
smtpd_banner = $myhostname
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
   reject_non_fqdn_hostname, reject_invalid_hostname, permit

Re: problem with spam

[Sebastian Nielsen]

Are you entirely sure that no user credentials are hacked? Note that a 
dictionary-attacked or bruteforced password is undetectable, and could have 
happened months ago. Eg, a bot could have cracked the password, saved it 
into a database, and then the owner of that bot sold the accounts to a 
spammer or whatever.
So you wont see in the log that the password was cracked, unless you rummage 
through months of log history.


-Ursprungligt meddelande- 
From: Christos Chatzaras

Sent: Sunday, May 24, 2015 1:10 PM
To: postfix-users@postfix.org
Subject: Re: problem with spam

What I try to find out is how spam is sent out if only users that 
authenticate can send e-mail and when no user e-mail accounts credentials 
are hacked. 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: proof-of-work principle applied to mail sending protocol(s) - spams

[Sebastian Nielsen]

Hashcash does already work on protocol level, but for a widely deployment to 
happen, senders must start using it at own initiative, before receivers 
can start enforcing them.
Once senders have adopted the system, receivers can simply start enforcing 
hashcash.


Enforcing hashcash means rejecting all mails that have less than a certain 
bits on the hashcash stamp. (or no hashcash stamp)


So basically, its the chicken-and-egg problem.
Senders wont start using it before receivers do enforce it.
Receivers cant start enforcing it before senders start using it.
(same can be seen with chip'n'pin, you can't simply start enforcing chip 
cards because theres lots of issuers who use magstripe cards, thus all card 
readers today still have magstripe reader - and same with pin, theres lots 
of card readers who dont have a pinpad, thus you cannot enforce pin on the 
issuer side, you have to accept signature transactions too - and theres 
lots of readers without chip slot, thus issuers have to issue chip+magstripe 
cards, not chip-only cards)


So this is a problem that exist everywhere, once a system is widely adopted, 
its hard to change the system without either adding backwards compatibility 
or breaking the system.


Even if you implement hashcash on the SMTP protocol level, you cannot simply 
upgrade your system because then you will start rejecting all mail from 
old systems. This still means that regardless on how you implement it, 
senders must start using the system at own initiative before receivers can 
start requiring it.
Just look at STARTTLS. Even if most mailservers do support it, theres still 
mailservers out there that wont support STARTTLS, thus you cannot require 
encryption.
Another thing to watch out for, is that lists, like this (postfix list) 
would have to generate *LOTS* of proof-of-work to be able to send mail to 
its users.
If lists would get whitelisted in a hashcash-mandatory system, and the 
list itself would require hashcash, then spammers would simply use the 
list as a spam amplification system.
Nowadays, lists like postfix users are free of spam, just because its 
easier for spammers to send out spam themselves.


But a thing mail server owners with greylist can do, is to express-lane all 
hashcash-stamped mails with a sufficent bit amount through, eg they dont 
have to negotiate greylist and queue mail for the specified waiting period.

Same can be done for spam filters.

The good thing with hashcash is that it does not require any previous 
negotiation. You just generate a hashcash that is sufficently strong for 
your taste, and then you see if the receiver likes it or not.
This means you can also configure your greylist system to enforce different 
delay periods for different hashcash bit levels, so even weak hashcashes 
are accepted partially.



-Ursprungligt meddelande- 
From: Gergely Debreczeni

Sent: Thursday, May 07, 2015 12:31 AM
To: Sebastian Nielsen ; postfix-users@postfix.org
Subject: RE: proof-of-work principle applied to mail sending protocol(s) - 
spams


Thank you Sebastion ! i'll check on that better !

Though, it does not solve the part of spam generation. Spams are still 
generated but killed on the Receiver side. If all this could be implemented 
on the protocol level and 'on demand' than it would work much better.


Cheers,
Gergely


From: Sebastian Nielsen [sebast...@sebbe.eu]
Sent: 07 May 2015 00:20
To: Gergely Debreczeni; postfix-users@postfix.org
Subject: Re: proof-of-work principle applied to mail sending protocol(s) - 
spams


IT do already exist:
http://www.hashcash.org/

Im already using it.
See this mail, you find this header:
X-Hashcash:
1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb

Thats a proof-of-work system with hashcash. Im currently have a module in my
outgoing mail server that generates such hashcash stamps with the help of
a milter.
Spamassassin in default config should reward such headers with a negative
spam score.

-Ursprungligt meddelande-
From: Gergely Debreczeni
Sent: Thursday, May 07, 2015 12:11 AM
To: postfix-users@postfix.org
Subject: proof-of-work principle applied to mail sending protocol(s) - spams

Dear List,

I was advised to come to this list with the idea below. I apologize if this
is not the right forum, in that case please point be to more appropriate
list. In any case i would appreciate any feedback on the thoughts below,
which I try to explain very densly and can of course eloborate in detail
later in case of interest.

A one liner:
An idea based on the proof-of-work principle to tremendously decrease mail
spam traffic.

A short extract:
The problem:
The problem of spam mails is still existing and current solutions are trying
to cure the issue on the wrong side of the problem. Despite the fact, that
due to state-of-art spam filters spams are not really problems for the end
user, spam mails are still generated, sent

Re: proof-of-work principle applied to mail sending protocol(s) - spams

[Sebastian Nielsen]

IT do already exist:
http://www.hashcash.org/

Im already using it.
See this mail, you find this header:
X-Hashcash: 
1:26:150428:nielsen.sebast...@gmail.com::8G9E5dBe8isoyoyL:07iLtb


Thats a proof-of-work system with hashcash. Im currently have a module in my 
outgoing mail server that generates such hashcash stamps with the help of 
a milter.
Spamassassin in default config should reward such headers with a negative 
spam score.


-Ursprungligt meddelande- 
From: Gergely Debreczeni

Sent: Thursday, May 07, 2015 12:11 AM
To: postfix-users@postfix.org
Subject: proof-of-work principle applied to mail sending protocol(s) - spams

Dear List,

I was advised to come to this list with the idea below. I apologize if this 
is not the right forum, in that case please point be to more appropriate 
list. In any case i would appreciate any feedback on the thoughts below, 
which I try to explain very densly and can of course eloborate in detail 
later in case of interest.


A one liner:
An idea based on the proof-of-work principle to tremendously decrease mail 
spam traffic.


A short extract:
The problem:
The problem of spam mails is still existing and current solutions are trying 
to cure the issue on the wrong side of the problem. Despite the fact, that 
due to state-of-art spam filters spams are not really problems for the end 
user, spam mails are still generated, sent and generating malicious internet 
traffic. This is because a.) it is virtually free for spammers to send the 
mails and b.) spams are treated only after they arrived into their 
destination.


The solution:
While keeping all the good properties of open message/mail sending 
protocols, we need to change a.) and b.) and there is a way to do this in 
one step, which is the following:


Let's imagine the following imaginary mail sending protocol.
1.) Sender contacts the Receiver
2.) Receiver verifies Sender's identity
3a.) If Sender identity is known to Receiver, then Receiver accepts Sender's 
message.
3b.) If Sender's identity not know for the Receiver then Receiver says to 
Sender: I do not know You, but you can still send me a message if you solve 
this problem!

4.) The Receiver gives a computational problem to the Sender which
a.) can be infinitely, trivially (or parallely) generated
b.) can easily be verified
c.) and can be solved only serially, i.e. unparalellizable (so 
as to ensure that it takes more-or less the same time for everybody)

d.) has a well estimable and tunable computational complexity
e.) generated on the spot, has limited lifetime and used only 
once so as to exclude any second or aftermarket of problem solvers and mail 
senders
5.) If the Sender is really serious about to send the message it solves the 
problem, i.e. it dedicates N seconds/minutes of computational time to solve 
the problem and connects back the Receiver with the solution
6.) Having the solution presented to the Receiver the Receiver accepts the 
message, since a proof-of-work was presented.
7.) The user who reads the mail can mark Sender as 'known' so next time 
Sender does not have to perform calculation



What follows:
a.) This way anybody can contact anybody (no whitelist/blacklist) and it it 
only the first contact which is painful.

b.) No human labor intensive captcha solving is involved
c.) No money, 3rd party, administration or any legal regularisation involved 
still working.
d.) Since this way it becomes several order of magnitudes more expensive to 
spammers to contact unknown email adresses for the first time, it becomes 
economically unfeasible to operate and manage spamming botnets or other 
spamming machinery.
e.) Problem requiring can be optional and problem complexity can vary from 
address to address.

f.) Problem can be sent as a 1 liner error message inside SMTP communication
g.) The idea can be implemented organically inside the SMPT protocol.
h.) In this way spams are not even generated and does not generate internet 
traffic so spam issue is treated at the right side of the problem.


There is of course many more little but important details to discuss about, 
this is just the brief overview of the idea.


Would appreciate any feedback and/or volunteer prototype implementation in 
case of interest


Sincerely,
Gergely Debreczeni






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Blocking compromised accounts (outgoing spam) and auth cracking

[Sebastian Nielsen]

I think you are approaching this problem from the wrong end.
Instead of blocking compromised accounts, make sure they cannot be 
compromised.


For example: Configure your server to only accept authentication from valid 
IPs, for example company internal ones, or implement geoIP blocking so if 
your organization is located in Country X, whitelist Country X and then 
disallow every other country to login.
Another thing to implement is IP-range restriction. You could implement this 
as a policy service, where the first login of a new user will record the 
IP-range the user's ISP is using (This can be enumerated by either doing a 
whois lookup against the user's IP,
or doing a ASN lookup against the user's ASN number). This will return a 
range like 94.185.80.0 - 94.185.87.255 for a small ISP or a larger range 
like x.x.0.0 to x.x.255.255 for a larger ISP.
Once a user has logged in for the first time, his account will be locked to 
the ISP he is currently using.


This will cut down on comrpomised accounts and spam very much, since the 
user's username and password is worthless to anyone who don't have the same 
ISP as the account's owner.
If you dont want to restrain your users too much, you can always allow 
receiving of POP3/IMAP mail worldwide without IP restriction, and also allow 
internal mail, but relayed mail is subject to the IP restriction.


-Ursprungligt meddelande- 
From: Chuck Peters

Sent: Saturday, April 18, 2015 8:16 PM
To: postfix-users@postfix.org
Subject: Blocking compromised accounts (outgoing spam) and auth cracking



I'm researching migrating some Exim servers to Postfix and would like to 
implement automatic blocking of compromised and spammers' accounts with 
notifications to staff.  Any suggestions?


On the Exim user list today someone suggested 
https://github.com/Exim/exim/wiki/BlockCracking.


Blocking compromised accounts (outgoing spam) and auth cracking

Nowadays users' passwords often are stolen (with drive-by exploits, Windows 
malware, phishing) and used for spamming. Spam sent with authentication via 
your server causes it to be blacklisted without notice and sometimes no 
appeal. Simple rate limiting authenticated users constrains honest users 
while still allowing spam to trickle through, your server still ends up in 
blacklists. Each server needs automatic detection and blocking of 
compromised accounts (stolen passwords). I amended and implemented (for Exim 
version 4.67 or higher) Andrew Hearn's idea to check not rate of messages or 
all recipients, but rate of attempts to send to nonexistent recipient email 
addresses. Vast majority of spammers never try to validate every recipient 
address. Spammers harvest strings looking like email addresses from webpages 
and disks of trojaned Windowses, then sell huge lists of email addresses to 
each other. These lists contain very much email addresses which don't exist 
anymore or never existed: Message-Ids, corrupted strings in memory and 
files. In short, spammers' lists of email addresses are much dirtier than 
lists honest users send to. Honest users are very unlikely to attempt to 
send to 100 nonexistent email addresses in one hour. Below I explain in 
detail (for novices at Exim) what to change in Exim config for automatic 
blocking of compromised and spammers' accounts, with automatic email 
notification to sysadmin or your abuse or support staff.

...


Thanks,
Chuck 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Blocking compromised accounts (outgoing spam) and auth cracking

[Sebastian Nielsen]

Yes I agree its annoying for your users, but sometimes convience needs to be 
sacrified for security.
As I said, mail could be set up so receiving is allowed, and sending 
internal mail is allowed, but not sending outside, when away from your home 
network.
Its also possible to set up for example VPN accounts and similiar for 
travelling VIP users, so those VIP users can use cellphone mail, but 
regular users have to wait until they're home before replying on mail.
By allowing receiving of mail from worldwide, its possible that a user can 
use a GMAIL account to reply to a mail when they are away.
Webmail to be able to access abroad can be setup too. Preferably with strong 
OTP authentication.


Large mail providers like hotmail, gmail and such, can track user behaviour 
and find out if a known spammer logs into a gmail account, and thus block it 
off. This because they have a fairly large view of the internet and in 
practice
knows most spammer IPs and ISPs, and can request extra verification via SMS 
for example, when a known spammer IP or suspicious country attempts to logon 
to a GMAIL account.


For a small/medium corporation/organization or private mail, such its 
impossible, and thus its better to rely in whitelisting instead. 
Whitelisting countries, whitelisting ISP ranges and such, to ensure the end 
user's account not get compromised.



-Ursprungligt meddelande- 
From: Patrick Domack

Sent: Saturday, April 18, 2015 11:35 PM
To: postfix-users@postfix.org
Subject: Re: Blocking compromised accounts (outgoing spam) and auth cracking

This sounds painfully annoying.

I hope your uses never travel, take a vacation, or go on a work trip.

And it doesn't stop or help if the user gets a virus on their computer
that uses the local saved credentials on that computer, and also will
make cellphone mail completely unusable.


Quoting Sebastian Nielsen sebast...@sebbe.eu:


I think you are approaching this problem from the wrong end.
Instead of blocking compromised accounts, make sure they cannot be 
compromised.


For example: Configure your server to only accept authentication  from 
valid IPs, for example company internal ones, or implement  geoIP blocking 
so if your organization is located in Country X,  whitelist Country X and 
then disallow every other country to login.
Another thing to implement is IP-range restriction. You could  implement 
this as a policy service, where the first login of a new  user will record 
the IP-range the user's ISP is using (This can be  enumerated by either 
doing a whois lookup against the user's IP,
or doing a ASN lookup against the user's ASN number). This will  return a 
range like 94.185.80.0 - 94.185.87.255 for a small ISP or a  larger range 
like x.x.0.0 to x.x.255.255 for a larger ISP.
Once a user has logged in for the first time, his account will be  locked 
to the ISP he is currently using.


This will cut down on comrpomised accounts and spam very much, since  the 
user's username and password is worthless to anyone who don't  have the 
same ISP as the account's owner.
If you dont want to restrain your users too much, you can always  allow 
receiving of POP3/IMAP mail worldwide without IP restriction,  and also 
allow internal mail, but relayed mail is subject to the IP  restriction.


-Ursprungligt meddelande- From: Chuck Peters
Sent: Saturday, April 18, 2015 8:16 PM
To: postfix-users@postfix.org
Subject: Blocking compromised accounts (outgoing spam) and auth cracking



I'm researching migrating some Exim servers to Postfix and would  like to 
implement automatic blocking of compromised and spammers'  accounts with 
notifications to staff.  Any suggestions?


On the Exim user list today someone suggested 
https://github.com/Exim/exim/wiki/BlockCracking.


Blocking compromised accounts (outgoing spam) and auth cracking

Nowadays users' passwords often are stolen (with drive-by exploits, 
Windows malware, phishing) and used for spamming. Spam sent with 
authentication via your server causes it to be blacklisted without  notice 
and sometimes no appeal. Simple rate limiting authenticated  users 
constrains honest users while still allowing spam to trickle  through, 
your server still ends up in blacklists. Each server needs  automatic 
detection and blocking of compromised accounts (stolen  passwords). I 
amended and implemented (for Exim version 4.67 or  higher) Andrew Hearn's 
idea to check not rate of messages or all  recipients, but rate of 
attempts to send to nonexistent recipient  email addresses. Vast majority 
of spammers never try to validate  every recipient address. Spammers 
harvest strings looking like email  addresses from webpages and disks of 
trojaned Windowses, then sell  huge lists of email addresses to each 
other. These lists contain  very much email addresses which don't exist 
anymore or never  existed: Message-Ids, corrupted strings in memory and 
files. In  short, spammers' lists of email addresses are much dirtier than

Re: per-user attachment blocking?

[Sebastian Nielsen]

I would say its better to strip unauthorized attachments instead of blocking 
the whole message. A notice could be appended to message informing about the 
stripped attach. This because some email clients/MTAs insert their own 
attachments, and user cannot control this. The attachments in many cases does 
not matter, could be company logos, vcard's, signatures, AUP's (Yes I have seen 
one company that embedded their TOS/AUP as a pdf attachment, and the customer 
service representative could propably not control or suppress this.).
and similiar, and can be safely stripped off.
Some old versions of outlook express also put the message as a .dat attachment.
So best way here is to strip such things.



@lbutlr krem...@kreme.com skrev: (9 april 2015 11:04:32 CEST)
On Apr 8, 2015, at 12:23 PM, Noel Jones njo...@megan.vbhcs.org wrote:
 Alternately, reconsider blocking all executable attachments as a
 site-wide policy.  That will take care of a lot of problems, and is
 becoming a fairly common policy.

I blocked a long list of dangerous attachment types at least a decade
ago and I’ve never heard a single complaint about it.

-- 
The true measure of a man is how he treats someone who can do him
absolutely no good. ~Samuel Johnson


smime.p7s
Description: S/MIME Cryptographic Signature

Re: per-user attachment blocking?

[Sebastian Nielsen]

We’re not talking about rejecting all attachments, just executable ones. 
Well, I’m not.


Thats a entirely different thing. I tought you were talking about any 
potentially harmful attachment, eg blocking all attachments except a couple 
of 100% safe ones like TXT, PNG and such.
Some providers just block EXE's, COM's and such directly/natively 
executeable formats, which is fine because executeable files are rarely sent 
by mail, unless its a virus.


Other block just everything that CAN happen to contain executeable code, 
even via security holes, like doc/docx (macros), rtf (explots), zip (even if 
the zip does not contain executeable files itself), pdf (exploits), jpg (can 
contain exploits).
A good thing however, is to block everything ending in .xxx.xxx, where x is 
any char [a-z 0-9], and . is a literal dot, not any char. Those are 
always, in 100% of cases, virus.


Since when a email provider or email administrator has set up their system 
to always add a attachment, and the end user has no way to stop it, if your 
system then blocks that attachment with a bounce, then the end user on the 
sending side
will impossibility to send a email to you. The user cannot even make initial 
contact with a user to perhaps contact him via a another way like phone or 
snail-mail.
Thats is why its better to strip the attachment, and possibilty add a notice 
in the email body or headers, that a nonpermitted attachment was stripped. 
Then the, in many cases, worthless attachment (like a company logo 
signature) is simply stripped away, and then the message is still reaching 
the end user.
If the attachment was good and useful, the end user which received the mail 
could simply ask the user to send the attachment like via dropbox or 
similiar.
I actually asked that company why they were attaching a TOS/AUP in every 
mail making the mail like ~100kB. They said that it was to avoid legal 
trouble, because if their support personell would forgot to add the TOS/AUP 
when a customer places a order, they could face legal problems later. Thus 
they put a non-bypassable forced add-attach in their outgoing MTA, thus they 
could prove to a court that the TOS/AUP was always added, even if the 
receiving email system stripped it, thus the customer would be bound by 
agreement anyway.


This is propably why the OP wants to selectively block attachments for 
certain users, so he could either blacklist those reckless users that always 
clicks on greeting cards they get in email, or whitelist those good users
which does maintain a good computer hygiene, thus not inflicting normal 
email communication.


Best regards, Sebastian Nielsen 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: port 25 465 and 587 confusion.

[Sebastian Nielsen]

IMHO I find it better to only allow submission from trusted nets. Better to 
disable authentication completely, and completely disable mail submission 
(relaying) from the outside.

Thus closing 587 completely.
465 can be good to allow old (or misconfigured) SMTPS servers to send 
incoming mail to you.


By disabling authentication and ONLY allowing relaying from the inside, 
you completely close the spam hole.
If theres no possibility to submit mail from the outside at all, then 
theres nothing to run a password cracker or dictionary attack at all on.


If you MUST accept submissions from the outside, I would suggest limiting 
this to a set of permitted IPs/IP ranges by using check_client_access to 
permit_sasl_authenticated, reject_unauth_destination only from authorized 
IP ranges, and reject_unauth_destination from

everyone else.
Then you limit the exposure to password crackers and dictionary-attacking 
relayers pretty much since they then must come from the same ISP or country 
as your authorized users (depending on your authorization list).


-Ursprungligt meddelande- 
From: Peter

Sent: Monday, April 06, 2015 11:18 AM
To: postfix-users@postfix.org
Subject: Re: port 25 465 and 587 confusion.

On 04/06/2015 08:05 PM, Muhammad Yousuf Khan wrote:

By Peter
-

What you should be, at the very least, encouraging is STARTTLS over 
port

587.  Whether you want to support some very old Outlook clients and
offer TLS wrappermode over 465 is up to you but it is unlikely you 
will
find anyone who still needs this old and deprecated form of 
submission.



what do you mean by very least. is there any preferable way then
STARTTLS.


I mean that the very least you should do is encourage your users to use
port 587 with STARTTLS, you could do more by enforcing it.


- is this possible i enforce users/clients to only submit mails on port
587 and i leave 25 for server to server communication only.


Right, you really should not be allowing submission on port 25 at all.


and is this segregation is a good thought of mine or practical?


Yes


isn't 465 is useless and can i close this if yes then how?


That depends on if you have users that have very old versions of Outlook
which don't support STARTTLS.  In this case you should encourage or even
require them to upgrade to a newer email client, but in case you can't
do that then you might have to support port 465 for them.

You close it by commenting out the smtps section in master.cf.


Peter 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: port 25 465 and 587 confusion.

[Sebastian Nielsen]

What I meant is that if your users are on a dynamic IP from a “outside” net, 
you can allow that net *in combination* with authentication.
Thus, you will both need to be from the correct net, but also have a valid 
username and password.

For example, lets say you have a internal company network on 192.168.0.0/16 and 
then all your external users have ISP accounts from Comhem Sweden.
Then you put your internal company network inside “mynetworks” so internal 
users can relay without authentication.

But then, you put the whole Comhem network ( 151.177.0.0/16 ) that 
“permit_sasl_authenticated, reject_unauth_destination” all users inside 
151.177.0.0/16, and does only “reject_unauth_destination” those outside that 
net.
This means that anyone from the comhem network will be able to authenticate  
relay (but not relay without authentication), but those outside comhem network 
wont be able to relay at all, not even as authenticated.
Thus, a spammer hacker that does have a good dictionary list or a decent 
password cracking software, will not gain any success anyways, because it wont 
matter how much good accounts that hacker does have, he will still not be able 
to relay through that server because he must be from 151.177.0.0/16 aswell.

If you know that all your users are from a specific country, you could download 
a GeoIP database and put into the access table.

Basically, you set your server to:
allow relay for internal users (192.168.0.0/16 or similiar) without 
authentication.
allow relay for authenticated users but ONLY if the authenticated users come 
from a specific country or ISP network.

Then you have a good protection against dictionary hackers/bruteforcers.

Many ISPs in sweden do this, they BOTH require authentication, but you aswell 
need to use a IP from that particular ISP.
Users outside that network simply has to use their webmail, which does have 
more protections in form of captchas and such.

From: Muhammad Yousuf Khan 
Sent: Monday, April 06, 2015 2:27 PM
To: Peter 
Cc: Postfix users 
Subject: Re: port 25 465 and 587 confusion.

@Peter

  Right, you really should not be allowing submission on port 25 at all.



   and is this segregation is a good thought of mine or practical?

  Yes

   isn't 465 is useless and can i close this if yes then how?

  That depends on if you have users that have very old versions of Outlook
  which don't support STARTTLS.  In this case you should encourage or even
  require them to upgrade to a newer email client, but in case you can't
  do that then you might have to support port 465 for them.

  You close it by commenting out the smtps section in master.cf.



in light of your above suggestions. i enabled 


smtp  inet  n   -   -   -   -   smtpd
#smtp  inet  n   -   -   -   1   postscreen
#smtpd pass  -   -   -   -   -   smtpd
#dnsblog   unix  -   -   -   -   0   dnsblog
#tlsproxy  unix  -   -   -   -   0   tlsproxy
submission inet n   -   -   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
#smtps inet  n   -   -   -   -   smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

main.cf, i enabled smtpd_tls_security_level=encrypt  (i know master.cf entry 
will override but i set encryption in both files)


by disabling smtps. i disabled the 465 port. and also forced submission by this 
line  submission inet n   -   -   -   -   smtpd


however my clients can still submit emails on port 25. and also on 587 port. 
both work the same.

can you please guide?







@Sebastion Nielsen

IMHO I find it better to only allow submission from trusted nets. Better to 
disable authentication completely, and completely disable mail submission 
(relaying) from the outside.
Thus closing 587 completely.
465 can be good to allow old (or misconfigured) SMTPS servers to send incoming 
mail to you.



Thanks its a good idea i will also read and try to implement this in separate 
environment though i think this approach is applicable when you know your 
client IPs. if they are dynamic and can be anywhere thoughout the word it is a 
headache to note down and allow all the IP. i think simple TLS may do the job. 
i could be wrong but i am very new to mailing thing and this is the point which 
makeing me stop doing it. 





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Add header with original IP?

[Sebastian Nielsen]

Can it be done without a policy service or milter? Eg with some header 
checks? Or maybe a configuration option?


-Ursprungligt meddelande- 
From: Noel Jones

Sent: Monday, March 23, 2015 7:57 PM
To: postfix-users@postfix.org
Subject: Re: Add header with original IP?

On 3/23/2015 1:20 PM, Sebastian Nielsen wrote:

How can I in postfix add a header with the original client IP (like
“X-Original-IP”), such as, it cannot be forged, eg any incoming mail
will have such headers stripped out, before Postfix adds its own.

The intention of this header is to use it at a later processing step
for separating phishing mail from legit mail (using SPF), but the
check must be done after a heavy processing step for technical
reasons, thus I have to “save” the client IP in the header, then
process the mail through the heavy step, and then use the client IP
in authentication. For this reason, any such headers must be
stripped off first, so a fraudulent user cannot add one or more of
such a header to “forge” the SPF check.

Or is there some way in a milter/macro to “read” off the XFORWARD
ip? Im currently using {client_addr} but is there any other macro
that would “display” the XFORWARD ip?
I saw a other suggestion to use XCLIENT, but postfix smtp doesnt
support XCLIENT in client mode.



The client IP is already in the top-most Received: header added by
postfix.  Any header below that may be forged, but the top-most
Received: header is added by your system and cannot be forged.

If you want to add some extra header with that same IP, you'll need
to use a policy service with the PREPEND action.
http://www.postfix.org/SMTPD_POLICY_README.html



 -- Noel Jones 



smime.p7s
Description: S/MIME Cryptographic Signature