IPv6 DNSBL support in Postfix?

[Rich Wales]

Does Postfix support blacklisting / whitelisting for IPv6 addresses?

If so, is there any documentation available to help me with the details?

I'm running Postfix version 2.11.0 on an Ubuntu 14.04.4 LTS system.
-- 
*Rich Wales*
ri...@richw.org

Re: Documentation improvement request (was: RBLs in postscreen AND smtpd_*_restrictions)

[Peter]

On 07/06/16 12:23, Wietse Venema wrote:
>> dnsblog(8) states, "Otherwise it replies with the query arguments plus
>> an empty address list and the reply TTL (-1 if unavailable)."  It is
>> unclear that this references the negative cache TTL as returned by the
>> SOA record included in an NXDOMAIN response.
>>
>> I had to look at the dnsblog.c source code for this to become clear.
> 
> The -1 is not related to caching for negative responses.
> 
> The -1 means there was no reply, or the reply contained no TTL
> information (which happens with an NXDOMAIN response without authority
> records).

Right, I understand that.  I was referring to the part just before that,
the "Otherwise" appears to refer (at least partially) to a negative
response, but there is nothing that actually states that a negative
response returns the negative cache TTL from the SOA header.  As I said,
I had to look to the source code to confirm that this is actually what
happens.


Peter

Re: Documentation improvement request (was: RBLs in postscreen AND smtpd_*_restrictions)

[Wietse Venema]

Peter:
> On 03/06/16 22:20, Wietse Venema wrote:
> > Postscreen has postscreen_dnsbl_ttl (fixed time limit) or it uses
> > the DNS TTL, limited by postscreen_dnsbl_{min,max}_ttl.
> > 
> > Please see Postfix documentatiom, and report a bug if it is incomplete.
> 
> dnsblog(8) states, "Otherwise it replies with the query arguments plus
> an empty address list and the reply TTL (-1 if unavailable)."  It is
> unclear that this references the negative cache TTL as returned by the
> SOA record included in an NXDOMAIN response.
> 
> I had to look at the dnsblog.c source code for this to become clear.

The -1 is not related to caching for negative responses.

The -1 means there was no reply, or the reply contained no TTL
information (which happens with an NXDOMAIN response without authority
records).


Wietse

Re: Documentation improvement request

[Peter]

On 07/06/16 08:49, Peter wrote:
> On 03/06/16 22:20, Wietse Venema wrote:
>> Postscreen has postscreen_dnsbl_ttl (fixed time limit) or it uses
>> the DNS TTL, limited by postscreen_dnsbl_{min,max}_ttl.
>>
>> Please see Postfix documentatiom, and report a bug if it is incomplete.
> 
> dnsblog(8) states, "Otherwise it replies with the query arguments plus
> an empty address list and the reply TTL (-1 if unavailable)."  It is
> unclear that this references the negative cache TTL as returned by the
> SOA record included in an NXDOMAIN response.

...also it would help to reference dnsblog(8) from the
postscreen_dnsbl_*_ttl entries in postconf(5), just to tie that together.


Peter

Re: RBLs in postscreen AND smtpd_*_restrictions

[Peter]

On 07/06/16 01:07, Bill Cole wrote:
> 4. The resolver cache honors (as most do) a DNSBL's negative cache TTL
> which is less than 60 seconds, e.g. Spamcop (0 seconds) or the various
> Spamhaus lists (10) and others.

postscreen (specifically dnsblog(8)) honors this as well, but it's not
made entirely clear in the docs.


Peter

Documentation improvement request (was: RBLs in postscreen AND smtpd_*_restrictions)

[Peter]

On 03/06/16 22:20, Wietse Venema wrote:
> Postscreen has postscreen_dnsbl_ttl (fixed time limit) or it uses
> the DNS TTL, limited by postscreen_dnsbl_{min,max}_ttl.
> 
> Please see Postfix documentatiom, and report a bug if it is incomplete.

dnsblog(8) states, "Otherwise it replies with the query arguments plus
an empty address list and the reply TTL (-1 if unavailable)."  It is
unclear that this references the negative cache TTL as returned by the
SOA record included in an NXDOMAIN response.

I had to look at the dnsblog.c source code for this to become clear.


Peter

Re: Problems with SPF policy service (pypolicyd-spf)

[eNeKuX]

Hello and thank you for your reply.

 

I have followed your suggestions for debugging and please find below this message the results.

I see a general pattern for all the tests, no matter if "smtpd_delay_reject" is set to "no" or "yes", the number of policy calls are not equal to the message rate...

Any ideas why would this happen?

 


# One session per delivery, slowly:
smtp-source -s 1 -m 10 -w 10 -t recipient host:port

### with smtpd_delay_reject=no
cat counter_test1.txt | wc -l --> 5 (expected 10)
### with smtpd_delay_reject=yes
cat counter_test1.txt | wc -l --> 5 (expected 10)


# One session for all deliveries, slowly:
smtp-source -s 1 -m 10 -w 10 -d -t recipient host:port

### with smtpd_delay_reject=no
cat counter_test2.txt | wc -l --> 5 (expected 10)
### with smtpd_delay_reject=yes
cat counter_test2.txt | wc -l --> 5 (expected 10)


# Ten parallel sessions, multiple deliveries per session, slowly:
smtp-source -s 10 -m 100 -w 10 -d -t recipient host:port

### with smtpd_delay_reject=no
cat counter_test3.txt | wc -l --> 92 (expected 100)
### with smtpd_delay_reject=yes
cat counter_test3.txt | wc -l --> 92 (expected 100)


# One session at a time, multiple deliveries per session, fast:
smtp-source -s 1 -m 1000 -d -t recipient host:port

### with smtpd_delay_reject=no
cat counter_test4.txt | wc -l --> 102 (expected 1000)
### with smtpd_delay_reject=yes
cat counter_test4.txt | wc -l --> 108 (expected 1000)


# Ten parallel sessions, multiple deliveries per session, fast:
smtp-source -s 10 -m 1 -d -t recipient host:port

### with smtpd_delay_reject=no
cat counter_test5.txt | wc -l --> 1339 (expected 1)
### with smtpd_delay_reject=yes
cat counter_test5.txt | wc -l --> 1311 (expected 1)



 

eNeKuX

 
 

Sent: Saturday, June 04, 2016 at 11:57 PM
From: "Wietse Venema" 
To: "Postfix users" 
Subject: Re: Problems with SPF policy service (pypolicyd-spf)

eNeKuX:
> Hi there,
>
> we are experiencing an strange behaviour of a SPF policy service
> "pypolicyd-spf" on debian-wheezy (v1.0-2).
>
> We have reported the issue at their side
> (https://bugs.launchpad.net/pypolicyd-spf/+bug/1587173) but they
> are pointing us to report it here.
>
>
> When our server is running in our testing environment with near
> "0" mailflow the SPF policy service kicks-in for every incoming
> email and works as expected. Instead, if we move our server to
> production (same server, same configuration but with different IP)
> where there is a high mailflow, the SPF policy service does not
> kick-in for every incoming email but some is processed every 2 to
> 10 minutes.

You have configured smtpd_delay_reject=no. That completely changes
the way that smtpd_client_restrictions is evaluated. Instead of
once per recipient, it is evaluated only once per SMTP session, and
it is evaluated before Postfix has seen the EHLO, MAIL FROM, and
RCPT TO commands.

To debug, I suggest that you do some experiments in the test machine.
Use a mail generator such as smtp-source to demonstrate that Postfix
makes all expected policy calls at all message rates, whether the
mail arrives in parallel or not.

# One session per delivery, slowly:
smtp-source -s 1 -m 10 -w 10 -t recipient host:port

# One session for all deliveries, slowly:
smtp-source -s 1 -m 10 -w 10 -d -t recipient host:port

# Ten parallel sessions, multiple deliveries per session, slowly:
smtp-source -s 10 -m 100 -w 10 -d -t recipient host:port

# One session at a time, multiple deliveries per session, fast:
smtp-source -s 1 -m 1000 -d -t recipient host:port

# Ten parallel sessions, multiple deliveries per session, fast:
smtp-source -s 10 -m 1 -d -t recipient host:port

smtp-source is part of Postfix source code. It is usually not
installed, because it is an unsupported test program.

Wietse

Re: How to handle mail injected by the system sendmail command with DKIM signing

[Wietse Venema]

Quanah Gibson-Mount:
> Ok.  I may just update our script to submit to port 25 using a normal SMTP 
> session instead.  I guess there is no "non_smtpd_sender_restrictions" I 
> could use. ;)

Indeed. Sometimes I think that Milter configuration could be
simplified by doing this:

/etc/postfix/master.cf:
pickup fifo  n   -   y   60  1   pickup
-o content_filter=smtp:127.0.0.1:25

But I haven't fully examined all the corner cases that might break
when one does so.

Wietse

Re: Test DANE

[Viktor Dukhovni]

On Mon, Jun 06, 2016 at 08:36:09PM +0200, Tom Hendrikx wrote:

> > I did some further research. It seems that validns does not like this
> > construct, because it insists that TLSA records are 'properly prefixed'
> > (i.e. with a port and service prefix, see [1]).
> 
> Insists, as a policy check, which I have enabled (but is off by default)...

There is no requirement for the owner names of TLSA RRsets to take the
form:

_._.host.example.

Tools that implement such constraints are misguided.  Please open
a bug report with the tool designer.

-- 
Viktor.

Re: Test DANE

[Tom Hendrikx]

On 06-06-16 17:46, Viktor Dukhovni wrote:
> On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote:
> 
>> I have been playing around with the dane check tool from sys4 too, and
>> it seems it doesn't support the nice CNAME trick shown in
>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
> 
> In the dane.sys4.de test code CNAMEs in TLSA records are supported
> and work, provided the target of the CNAME is in a signed zone of
> course.  MX hosts that are CNAMEs are deliberately not supported
> as these violate the RFC requirements for MX records.
> 
> For example:
> 
> _25._tcp.gazonk.org.CNAME   _tlsa.gazonk.org.
> _tlsa.gazonk.org.   TLSA3 1 1 
> 2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C
> 
> For which https://dane.sys4.de correctly shows (that this domain
> is misconfigured by promising and then not offering  STARTTLS):
> 
> 42 gazonk.org
>212.247.24.42: STARTTLS not offered
> 
> IP Addresses
>212.247.24.42
> 
> Usable TLSA Records
>3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c
> 

I did some further research. It seems that validns does not like this
construct, because it insists that TLSA records are 'properly prefixed'
(i.e. with a port and service prefix, see [1]).

My dnssec auto-signing setup invalidated the zone because of this, so it
was never published with these records, concluding in the sane tool not
being able to see them. My bad...

[1]
https://github.com/tobez/validns/blob/5a374cf1d629d8d2fecdf6f215aec9b056370868/tlsa.c#L87

Regards,
Tom



signature.asc
Description: OpenPGP digital signature

Re: Test DANE

[Tom Hendrikx]

On 06-06-16 20:26, Tom Hendrikx wrote:
> On 06-06-16 17:46, Viktor Dukhovni wrote:
>> On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote:
>>
>>> I have been playing around with the dane check tool from sys4 too, and
>>> it seems it doesn't support the nice CNAME trick shown in
>>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
>>
>> In the dane.sys4.de test code CNAMEs in TLSA records are supported
>> and work, provided the target of the CNAME is in a signed zone of
>> course.  MX hosts that are CNAMEs are deliberately not supported
>> as these violate the RFC requirements for MX records.
>>
>> For example:
>>
>> _25._tcp.gazonk.org.CNAME   _tlsa.gazonk.org.
>> _tlsa.gazonk.org.   TLSA3 1 1 
>> 2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C
>>
>> For which https://dane.sys4.de correctly shows (that this domain
>> is misconfigured by promising and then not offering  STARTTLS):
>>
>> 42 gazonk.org
>>212.247.24.42: STARTTLS not offered
>>
>> IP Addresses
>>212.247.24.42
>>
>> Usable TLSA Records
>>3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c
>>
> 
> I did some further research. It seems that validns does not like this
> construct, because it insists that TLSA records are 'properly prefixed'
> (i.e. with a port and service prefix, see [1]).

Insists, as a policy check, which I have enabled (but is off by default)...

> 
> My dnssec auto-signing setup invalidated the zone because of this, so it
> was never published with these records, concluding in the sane tool not
> being able to see them. My bad...
> 
> [1]
> https://github.com/tobez/validns/blob/5a374cf1d629d8d2fecdf6f215aec9b056370868/tlsa.c#L87
> 
> Regards,
>   Tom
> 




signature.asc
Description: OpenPGP digital signature

Re: How to handle mail injected by the system sendmail command with DKIM signing

[Quanah Gibson-Mount]

--On Saturday, June 04, 2016 9:34 AM -0400 Wietse Venema 
 wrote:




zimbra@edge02e:~/common/conf$ cat tag_as_originating.re
/^/  FILTER smtp-amavis:[127.0.0.1]:10026



I have no idea what that regexp is about. I do know, however,
how I sign sendmail(1) submission with Postfix and opendkim.


This is something I believe you helped me with a few years ago. ;)  It is 
used in smtpd_sender_restrictions:


smtpd_sender_restrictions = check_sender_access 
lmdb:/opt/zimbra/conf/postfix_reject_sender, check_policy_service 
inet:localhost:10031, check_sender_access 
regexp:/opt/zimbra/common/conf/tag_as_originating.re, permit_mynetworks, 
permit_sasl_authenticated, permit_tls_clientcerts, check_sender_access 
regexp:/opt/zimbra/common/conf/tag_as_foreign.re


to mark items as either originating or foreign.  If they are originating, 
it gets passed off to Amavis and then OpenDKIM.




To sign sendmail(1) submission with a Milter, I have configured
non_smtpd_milters as shown below. That's how this posting got signed.

non_smtpd_milters = inet:127.0.0.1:9998

For sendmail(1) submission, the cleanup server's Milter client
creates a fake SMTP session from localhost/127.0.0.1/AF_INET (sorry,
not yet configurable). In order to enable signing, that IP address
is configured in my opendkim InternalHosts setting.


Ok.  I may just update our script to submit to port 25 using a normal SMTP 
session instead.  I guess there is no "non_smtpd_sender_restrictions" I 
could use. ;)


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc

Re: how did this message make it through?

[Yuval Levy]

Thanks for the help, Bill.

On 16-06-06 10:24 AM, Bill Cole wrote:

> NOTE THAT 454 REPLY!

could it be because I have soft_bounce = yes while trying to understand
the outcome of my rules without losing incoming emails?


> include postconf -n rather than main.cf snippets.

Attached, apology for not following proper procedure.


> "maps_rbl_reject_code"

nowhere in the configuration.


> defer_if_reject

nowhere in the configuration.


> modified package of Postfix

plain vanilla Ubuntu repository.


> 1. Stop inviting spammers to come back later when their DNSBL listing
> has expired. Fix whatever is causing you to send a 454 reply instead of
> the default 554 for Zen listings.

Assuming it is soft_bounce = yes, is there a way to override it for Zen
listings?  Or any other way to be more fine grained about soft bouncing?


> 2. Stop accepting mail AT ALL from IPs that have no PTR records by
> adding reject_unknown_reverse_client_hostname to
> smtpd_recipient_restrictions AFTER  permit_mynetworks and
> permit_sasl_authenticated. reject_unknown_reverse_client_hostname is
> extremely safe, requires no additional DNS lookups, and stops a
> substantial amount of spam.

Added, thanks.

Postconf -n is attached.  I am sure that there is a lot to criticize /
improve.  This personal, low-usage Postfix instance has served me well
for ages.  Last time I changed configuration was to add greylisting with
Postgray, seven years ago.  I was forced to make changes recently
because my wife's university made the (in my view bad) decision to
switch to outlook.office365.com which does not play nicely with
greylisting.  So I am trying to learn about current spam protection to
keep this personal server going.  Any hint/help is much appreciated.

Thanks,
Yuv
alias_maps = hash:/etc/aliases
alibaba = check_reverse_client_hostname_mx_access pcre:/etc/postfix/alibaba.pcre
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
disable_vrfy_command = yes
ebay = check_reverse_client_hostname_mx_access pcre:/etc/postfix/ebay.pcre
html_directory = no
inet_interfaces = all
linkedin = check_reverse_client_hostname_mx_access 
pcre:/etc/postfix/linkedin.pcre
mailbox_size_limit = 0
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination = localhost x2.example.com lists.example.com
myhostname = x2.example.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = inet:localhost:12301
paypal = check_reverse_client_hostname_mx_access pcre:/etc/postfix/paypal.pcre
policy-spf_time_limit = 3600s
readme_directory = no
recipient_delimiter = +
relay_recipient_maps = proxy:mysql:/etc/postfix/sql/alias.cf 
proxy:mysql:/etc/postfix/sql/alias_domain.cf 
proxy:mysql:/etc/postfix/sql/catchall.cf
relayhost =
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_error_sleep_time = 2s
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_milters = inet:localhost:12301
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination reject_invalid_hostname reject_non_fqdn_hostname 
reject_non_fqdn_sender reject_non_fqdn_recipient 
reject_unknown_reverse_client_hostname reject_unknown_sender_domain 
reject_unknown_recipient_domain check_recipient_access 
hash:/etc/postfix/recipients check_client_access 
hash:/etc/postfix/client_checks reject_rbl_client zen.spamhaus.org 
check_policy_service unix:private/policy-spf permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination
smtpd_restriction_classes = ebay linkedin alibaba paypal ultra_strict
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_local_domain =
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 10
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/ssl/example.com.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
ultra_strict = reject
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/alias.cf 
proxy:mysql:/etc/postfix/sql/alias_domain.cf 
proxy:mysql:/etc/postfix/sql/catchall.cf
virtual_gid_maps = static:
virtual_mailbox_base = /home/postino
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/domain.cf
virtual_mailbox_limit = ${message_size_limit}0
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/mailbox.cf 
proxy:mysql:/etc/postfix/sql/alias_domain_mailbox.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_uid_maps = static:

Re: check_sender_regexp - multiple relay IP`s

[Noel Jones]

On 6/6/2016 7:28 AM, Zalezny Niezalezny wrote:
> Hi, 
> 
> I just would like to know if its possible to configure muliple IP`s
> of SMTP servers in this configuration file: 
> 
> check_sender_access regexp:/etc/postfix/check_sender_regexp
> 
> 
> 
> At the moment we are forwarding message with following sender E-mail
> address to one of our MS Exchange servers. 
> 
> 
> /zelezny.niezale...@domain.com/
> FILTER smtp:[192.168.2.100]
> 
> 
> How may I setup in this file some kind of "backup MX" server if
> smtp:[192.168.2.100] will be down. 
> Is it possible to setup for example 3x IP`s ? If yes, how to do it ?
> 
> Single IP address of smtp relay in our high available environment is
> not allowed. I cannot use local domain with MX records because dns
> lookup has been disabled. 
> 
> Maybe somebody will be able to support me here ?
> 
> 
> Thanks in advance for any hints !

It's unfortunate you feel the need to disable DNS lookups, as a
local MX entry is the obvious solution.

You can list the destination name in /etc/hosts with multiple IPs to
load-balance between all the listed IPs.

You can clone the master.cf smtp transport to a different name, with
the option -o smtp_fallback_relay=[other.ip]
http://www.postfix.org/postconf.5.html#smtp_fallback_relay



  -- Noel Jones

Re: Test DANE

[Viktor Dukhovni]

On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote:

> I have been playing around with the dane check tool from sys4 too, and
> it seems it doesn't support the nice CNAME trick shown in
> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

In the dane.sys4.de test code CNAMEs in TLSA records are supported
and work, provided the target of the CNAME is in a signed zone of
course.  MX hosts that are CNAMEs are deliberately not supported
as these violate the RFC requirements for MX records.

For example:

_25._tcp.gazonk.org.CNAME   _tlsa.gazonk.org.
_tlsa.gazonk.org.   TLSA3 1 1 
2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C

For which https://dane.sys4.de correctly shows (that this domain
is misconfigured by promising and then not offering  STARTTLS):

42 gazonk.org
   212.247.24.42: STARTTLS not offered

IP Addresses
   212.247.24.42

Usable TLSA Records
   3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c

-- 
Viktor.

Re: Test DANE

[Alexandre Ellert]

> Le 6 juin 2016 à 16:46, Viktor Dukhovni  a écrit :
> 
> On Mon, Jun 06, 2016 at 03:58:51PM +0200, Alexandre Ellert wrote:
> 
>> I�ve juste enable DANE and https://dane.sys4.de 
>> is green when I test my domain numeezy.com .  Also
>> postfix SMTP client says "Verified TLS connection established to
>> mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"
>> 
>> Maybe some DANE expert here can definitely confirm that my setup is sane.
> 
> Yes, your DANE TLSA records match for both the primary and secondary
> MX hosts.  You've also *not* made the mistake of using the same
> certificate for both the primary and secondary MX hosts, thereby
> risking an outage of both when you replace a single certificate.
> And you're using "3 1 1" records which are stable when you renew
> your certificate with the same private key.  So overall, quite
> good, however you can do even better, see:
> 
>https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
> 
> based on which I would strongly recommend:
> 
>_25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
>_25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
>_25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
>_25._tcp.mail-in-2.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
> The above is based on the below observed DNS records, certificate
> chain and associated matching TLSA records:
> 
>numeezy.com. IN MX 1 mail-in-1.numeezy.com.
>numeezy.fr. IN MX 1 mail-in-1.numeezy.com.
>medialta.com. IN MX 1 mail-in-1.numeezy.com.
>medialta.fr. IN MX 1 mail-in-1.numeezy.com.
>medialta.eu. IN MX 1 mail-in-1.numeezy.com.
>mail-in-1.numeezy.com. IN A 188.165.154.163 ; passed
>_25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48 ; passed at 
> depth=0
>;
>;Depth: actual=0, wire=0
>;Subject = CN=mail-in-1.numeezy.com,O=Numeezy 
> SARL,L=PARIS,ST=Ile-de-France,C=FR
>;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
>;Valid from 2016-05-17T12:16:30Z until 2019-05-17T12:16:30Z
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 1 
> 50f417dbdab3677847eb0107d363044f4166eed1bb333daf6320d6b8daefb70e
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 2 
> 5061dc02e6df14ad409acb5c2bb4992f80e1a5a1cc53faa5d81bd42d644010260e9a94747599c49df6b576981a6c6bf02b86764758c2bf4008ae6387f558a7c4
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 2 
> b7b3d2036ad1d77d6c187e1f3fd9de28fc3f74af725a48c242bebc8eb1c4af56b06747bb1622cb27ef696f8741d09066d640768f9caa944a8981da174752a058
>;
>;Depth: actual=1, wire=1
>;Match = mail-in-1.numeezy.com
>;Subject = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
>;Issuer = CN=StartCom Certification Authority,OU=Secure Digital 
> Certificate Signing,O=StartCom Ltd.,C=IL
>;Valid from 2015-12-16T01:00:05Z until 2030-12-16T01:00:05Z
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 1 
> ea4e5d2b9c99560f13dd094b8121a623bfdd902038dfd6d772ce32ffabec094d
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 2 
> d26da4f0733b1f4af61f9db3c0e5bd6e379022e41038cb2cf7f38e273bdcaf98e0afd9b119e0fd85b090afec3d46020cbaee0158015666360ccc73418a0d3794
>; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 2 
> 6a4bd383b21927f44f09263819d2917edbd8a8ea58d97dac48c26a1e88e5c7062691366f79300705da4b68b5bf9153477241f7603faf4ac03d1cde69abaef328
> 
>numeezy.com. IN MX 5 mail-in-2.numeezy.com.
>numeezy.fr. IN MX 5 mail-in-2.numeezy.com.
>medialta.com. IN MX 5 mail-in-2.numeezy.com.
>medialta.fr. IN MX 5 mail-in-2.numeezy.com.
>medialta.eu. IN MX 5 mail-in-2.numeezy.com.
>mail-in-2.numeezy.com. IN A 37.59.203.174 ; passed
>_25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e ; passed at 
> depth=0
>;
>;Depth: actual=0, wire=0
>;Subject = CN=mail-in-2.numeezy.com,O=Numeezy 
> SARL,L=PARIS,ST=Ile-de-France,C=FR
>;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
>;Valid from 2016-05-17T12:39:52Z until 2019-05-17T12:39:52Z
>; _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
>; 

Re: Test DANE

[Tom Hendrikx]

Hi,

I have been playing around with the dane check tool from sys4 too, and
it seems it doesn't support the nice CNAME trick shown in
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

The tool does not seem to follow the CNAME pointer, and concludes with
the error "No TLSA records." Seems to me a nice imporment if it would
support the CNAME trick ;)

Regards,
Tom

On 06-06-16 16:46, Viktor Dukhovni wrote:
> On Mon, Jun 06, 2016 at 03:58:51PM +0200, Alexandre Ellert wrote:
> 
>> I�ve juste enable DANE and https://dane.sys4.de 
>> is green when I test my domain numeezy.com .  Also
>> postfix SMTP client says "Verified TLS connection established to
>> mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"
>>
>> Maybe some DANE expert here can definitely confirm that my setup is sane.
> 
> Yes, your DANE TLSA records match for both the primary and secondary
> MX hosts.  You've also *not* made the mistake of using the same
> certificate for both the primary and secondary MX hosts, thereby
> risking an outage of both when you replace a single certificate.
> And you're using "3 1 1" records which are stable when you renew
> your certificate with the same private key.  So overall, quite
> good, however you can do even better, see:
> 
> https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
> 
> based on which I would strongly recommend:
> 
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> 
> The above is based on the below observed DNS records, certificate
> chain and associated matching TLSA records:
> 
> numeezy.com. IN MX 1 mail-in-1.numeezy.com.
> numeezy.fr. IN MX 1 mail-in-1.numeezy.com.
> medialta.com. IN MX 1 mail-in-1.numeezy.com.
> medialta.fr. IN MX 1 mail-in-1.numeezy.com.
> medialta.eu. IN MX 1 mail-in-1.numeezy.com.
> mail-in-1.numeezy.com. IN A 188.165.154.163 ; passed
> _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48 ; passed at 
> depth=0
> ;
> ;Depth: actual=0, wire=0
> ;Subject = CN=mail-in-1.numeezy.com,O=Numeezy 
> SARL,L=PARIS,ST=Ile-de-France,C=FR
> ;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
> ;Valid from 2016-05-17T12:16:30Z until 2019-05-17T12:16:30Z
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
> cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 1 
> 50f417dbdab3677847eb0107d363044f4166eed1bb333daf6320d6b8daefb70e
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 2 
> 5061dc02e6df14ad409acb5c2bb4992f80e1a5a1cc53faa5d81bd42d644010260e9a94747599c49df6b576981a6c6bf02b86764758c2bf4008ae6387f558a7c4
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 2 
> b7b3d2036ad1d77d6c187e1f3fd9de28fc3f74af725a48c242bebc8eb1c4af56b06747bb1622cb27ef696f8741d09066d640768f9caa944a8981da174752a058
> ;
> ;Depth: actual=1, wire=1
> ;Match = mail-in-1.numeezy.com
> ;Subject = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
> Authority,O=StartCom Ltd.,C=IL
> ;Issuer = CN=StartCom Certification Authority,OU=Secure Digital 
> Certificate Signing,O=StartCom Ltd.,C=IL
> ;Valid from 2015-12-16T01:00:05Z until 2030-12-16T01:00:05Z
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
> d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 1 
> ea4e5d2b9c99560f13dd094b8121a623bfdd902038dfd6d772ce32ffabec094d
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 2 
> d26da4f0733b1f4af61f9db3c0e5bd6e379022e41038cb2cf7f38e273bdcaf98e0afd9b119e0fd85b090afec3d46020cbaee0158015666360ccc73418a0d3794
> ; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 2 
> 6a4bd383b21927f44f09263819d2917edbd8a8ea58d97dac48c26a1e88e5c7062691366f79300705da4b68b5bf9153477241f7603faf4ac03d1cde69abaef328
> 
> numeezy.com. IN MX 5 mail-in-2.numeezy.com.
> numeezy.fr. IN MX 5 mail-in-2.numeezy.com.
> medialta.com. IN MX 5 mail-in-2.numeezy.com.
> medialta.fr. IN MX 5 mail-in-2.numeezy.com.
> medialta.eu. IN MX 5 mail-in-2.numeezy.com.
> mail-in-2.numeezy.com. IN A 37.59.203.174 ; passed
> _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
> 8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e ; passed at 
> depth=0
> ;
> ;

Re: Test DANE

[Viktor Dukhovni]

On Mon, Jun 06, 2016 at 03:58:51PM +0200, Alexandre Ellert wrote:

> I�ve juste enable DANE and https://dane.sys4.de 
> is green when I test my domain numeezy.com .  Also
> postfix SMTP client says "Verified TLS connection established to
> mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"
> 
> Maybe some DANE expert here can definitely confirm that my setup is sane.

Yes, your DANE TLSA records match for both the primary and secondary
MX hosts.  You've also *not* made the mistake of using the same
certificate for both the primary and secondary MX hosts, thereby
risking an outage of both when you replace a single certificate.
And you're using "3 1 1" records which are stable when you renew
your certificate with the same private key.  So overall, quite
good, however you can do even better, see:

https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

based on which I would strongly recommend:

_25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
_25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166

_25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
_25._tcp.mail-in-2.numeezy.com. IN TLSA 2 1 1 
d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166

The above is based on the below observed DNS records, certificate
chain and associated matching TLSA records:

numeezy.com. IN MX 1 mail-in-1.numeezy.com.
numeezy.fr. IN MX 1 mail-in-1.numeezy.com.
medialta.com. IN MX 1 mail-in-1.numeezy.com.
medialta.fr. IN MX 1 mail-in-1.numeezy.com.
medialta.eu. IN MX 1 mail-in-1.numeezy.com.
mail-in-1.numeezy.com. IN A 188.165.154.163 ; passed
_25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48 ; passed at 
depth=0
;
;Depth: actual=0, wire=0
;Subject = CN=mail-in-1.numeezy.com,O=Numeezy 
SARL,L=PARIS,ST=Ile-de-France,C=FR
;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
Authority,O=StartCom Ltd.,C=IL
;Valid from 2016-05-17T12:16:30Z until 2019-05-17T12:16:30Z
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 1 
cf43899685886c77e6e86d6a063c957df7858e7ea1bc3896b464fc6502685b48
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 1 
50f417dbdab3677847eb0107d363044f4166eed1bb333daf6320d6b8daefb70e
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 1 2 
5061dc02e6df14ad409acb5c2bb4992f80e1a5a1cc53faa5d81bd42d644010260e9a94747599c49df6b576981a6c6bf02b86764758c2bf4008ae6387f558a7c4
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 3 0 2 
b7b3d2036ad1d77d6c187e1f3fd9de28fc3f74af725a48c242bebc8eb1c4af56b06747bb1622cb27ef696f8741d09066d640768f9caa944a8981da174752a058
;
;Depth: actual=1, wire=1
;Match = mail-in-1.numeezy.com
;Subject = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
Authority,O=StartCom Ltd.,C=IL
;Issuer = CN=StartCom Certification Authority,OU=Secure Digital 
Certificate Signing,O=StartCom Ltd.,C=IL
;Valid from 2015-12-16T01:00:05Z until 2030-12-16T01:00:05Z
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 1 
d765efb29fd40114afb1e830dbca8d1283e99086617ff18b07ad4ba58e7b0166
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 1 
ea4e5d2b9c99560f13dd094b8121a623bfdd902038dfd6d772ce32ffabec094d
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 1 2 
d26da4f0733b1f4af61f9db3c0e5bd6e379022e41038cb2cf7f38e273bdcaf98e0afd9b119e0fd85b090afec3d46020cbaee0158015666360ccc73418a0d3794
; _25._tcp.mail-in-1.numeezy.com. IN TLSA 2 0 2 
6a4bd383b21927f44f09263819d2917edbd8a8ea58d97dac48c26a1e88e5c7062691366f79300705da4b68b5bf9153477241f7603faf4ac03d1cde69abaef328

numeezy.com. IN MX 5 mail-in-2.numeezy.com.
numeezy.fr. IN MX 5 mail-in-2.numeezy.com.
medialta.com. IN MX 5 mail-in-2.numeezy.com.
medialta.fr. IN MX 5 mail-in-2.numeezy.com.
medialta.eu. IN MX 5 mail-in-2.numeezy.com.
mail-in-2.numeezy.com. IN A 37.59.203.174 ; passed
_25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e ; passed at 
depth=0
;
;Depth: actual=0, wire=0
;Subject = CN=mail-in-2.numeezy.com,O=Numeezy 
SARL,L=PARIS,ST=Ile-de-France,C=FR
;Issuer = CN=StartCom Class 3 OV Server CA,OU=StartCom Certification 
Authority,O=StartCom Ltd.,C=IL
;Valid from 2016-05-17T12:39:52Z until 2019-05-17T12:39:52Z
; _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 1 
8aee8995fca9c9cb89d0057f40b42cdcf23b1abc037681acd74af8c68b12a41e
; _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 0 1 
c49354b6b553fed27d8b66aa42a7be4f18d8979e5c6260bd62d174051fb58b3a
; _25._tcp.mail-in-2.numeezy.com. IN TLSA 3 1 2 

Re: how did this message make it through?

[Bill Cole]

On 6 Jun 2016, at 0:34, Yuval Levy wrote:


Hello Postfix-Users.  First time poster here, looking for help to
understand what is wrong with my Postfix configuration that has
delivered a message from a blacklisted server.

Log Excerpt
===

Jun  5 09:58:37 x2 postfix/smtpd[8440]: connect from 
unknown[157.52.162.99]

Jun  5 09:58:37 x2 postfix/smtpd[8440]: NOQUEUE: reject: RCPT from
unknown[157.52.162.99]: 454 4.7.1 Service unavailable; Client host
[157.52.162.99] blocked using zen.spamhaus.org;


NOTE THAT 454 REPLY!

from= to= proto=ESMTP 
helo=

Jun  5 09:58:37 x2 postfix/smtpd[8440]: disconnect from
unknown[157.52.162.99]
Jun  5 10:01:57 x2 postfix/anvil[8394]: statistics: max connection 
rate

1/60s for (smtp:198.2.130.200) at Jun  5 09:51:57
Jun  5 10:01:57 x2 postfix/anvil[8394]: statistics: max connection 
count

1 for (smtp:198.2.130.200) at Jun  5 09:51:57
Jun  5 10:01:57 x2 postfix/anvil[8394]: statistics: max cache size 2 
at

Jun  5 09:55:18
Jun  5 10:06:39 x2 postfix/smtpd[8507]: connect from 
unknown[157.52.162.99]

Jun  5 10:06:40 x2 policyd-spf[8513]: None; identity=helo;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Jun  5 10:06:40 x2 policyd-spf[8513]: Pass; identity=mailfrom;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Jun  5 10:06:40 x2 postfix/smtpd[8507]: 49D01C1EDE:
client=unknown[157.52.162.99]
Jun  5 10:06:40 x2 postfix/cleanup[8514]: 49D01C1EDE:
message-id=messageid-3-M3w1NDIzfDU4fDM3ODk3OTR8eWxlYmF5Y2EwNEBzZmluYS5jb218U2F0LCAwNCBKdW4gMjAxNiAwNToxNDowNyAtMDcwMA==
Jun  5 10:06:40 x2 opendkim[1220]: 49D01C1EDE: [157.52.162.99]
[157.52.162.99] not internal
Jun  5 10:06:40 x2 opendkim[1220]: 49D01C1EDE: not authenticated
Jun  5 10:06:43 x2 opendkim[1220]: 49D01C1EDE: no signature data
Jun  5 10:06:43 x2 postfix/qmgr[1337]: 49D01C1EDE:
from=, size=91945, nrcpt=1 (queue active)
Jun  5 10:06:43 x2 postfix/smtpd[8507]: disconnect from
unknown[157.52.162.99]
Jun  5 10:06:43 x2 dovecot: lmtp(8516): Connect from local
Jun  5 10:06:43 x2 dovecot: lmtp(8516, YYY@XXX): 
nhVjEfMxVFdEIQAAzX/GXw:

msgid=messageid-3-M3w1NDIzfDU4fDM3ODk3OTR8eWxlYmF5Y2EwNEBzZmluYS5jb218U2F0LCAwNCBKdW4gMjAxNiAwNToxNDowNyAtMDcwMA==:
saved mail to INBOX
Jun  5 10:06:43 x2 postfix/lmtp[8515]: 49D01C1EDE: to=,
orig_to=, relay=XXX[private/dovecot-lmtp], delay=3.6,
delays=3.5/0.01/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 
nhVjEfMxVFdEIQAAzX/GXw Saved)
Jun  5 10:06:43 x2 dovecot: lmtp(8516): Disconnect from local:
Successful quit
Jun  5 10:06:43 x2 postfix/qmgr[1337]: 49D01C1EDE: removed

Notes about the log
===

@XXX is my server
XXX@XXX is an alias
YYY@XXX is a mailbox

My understanding is that the bad sender [157.52.162.99] has been 
blocked
at 9:58:37 based on zen.spamhaus.org, but 8 minutes later it 
reconnected

and delivered successfully what should have not passed through.


At the moment, the Zen listing for that address is specifically a CSS 
listing with a 60 second TTL, so it is no longer in your cache 8 minutes 
after the first check. Due to how the CSS works, it is not uncommon for 
addresses to "flicker" in and out of the CSS, which targets "snowshoe" 
spammers who cycle their IP sources around a range of addresses to make 
detection harder. CSS is fairly good at hitting its targets, but by 
their nature they work harder than other sorts of spammers to figure out 
how to get addresses listed in CSS for the shortest possible period. 
Given what I've seen of that game playing out in the mail systems I run, 
I believe Spamhaus has been working to counter the snowshoers' tactics, 
but it is an ongoing arms race.



Headers of the mail that should have been rejected
==

Return-Path: 
Delivered-To: 
Received: from XXX
by XXX (Dovecot) with LMTP id nhVjEfMxVFdEIQAAzX/GXw
for ; Sun, 05 Jun 2016 10:06:43 -0400
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
client-ip=157.52.162.99; helo=mr99.dgnmkt.com;
envelope-from=newslet...@vacque.com; receiver=XXX@XXX
Received: from mr99.dgnmkt.com (unknown [157.52.162.99])
by XXX (Postfix) with ESMTP id 49D01C1EDE
for ; Sun,  5 Jun 2016 10:06:39 -0400 (EDT)
Received: from stormmta (unknown [157.52.162.99])
by mr99.dgnmkt.com (Postfix) with ESMTP id DD84AE61F8A
for ; Sun,  5 Jun 2016 08:16:33 -0700 (PDT)
From:=?UTF-8?B?VG1hcnQuY29t?=
To:XXX@XXX

Relevant main.cf options


If you don't know why something isn't working as expected, you can't 
really say what setting are or are not relevant. That is why the 
DEBUG_README file for Postfix says to include postconf -n output here 
rather than main.cf snippets.


One possible contributor to your problem is that you have 

Test DANE

[Alexandre Ellert]

Hello,

I’ve juste enable DANE and https://dane.sys4.de  is 
green when I test my domain numeezy.com .
Also postfix SMTP client says "Verified TLS connection established to 
mail-in-1.numeezy.com[188.165.154.163]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)"

Maybe some DANE expert here can definitely confirm that my setup is sane.

Thanks for your feedback.

Alexandre

Postfix Configure Some Users Not Receive Emails

[mehmet]

Hi,

I am using postfix with latest version for smtp. And for pop3, I am using 
dovecot with Maildir.
Postfix is running on centos.

I have couple of users on the system (I have created users with useradd 
command with nologin). I want to configure some users as can send e-mail but 
can not receive e-mail (because some accounts will be user and some other 
accounts will be just server which does not need to receive e-mail )?
I could find nothing a setting for this. There is  inet_interfaces, but it is 
not doing what I want.

Could you please informe me that is this possible with postfix?


Regards
Mehmet

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

FYI. The UK mirror page of the 3.1.1 source code appear to be broken. 404 Not Found

[Robert Chalmers]

http://mirror.tje.me.uk/pub/mirrors/postfix-release/index.html

Postfix 3.1 Patchlevel 0 Source code 

 |

404 - Not Found





Robert Chalmers
rob...@chalmers.com .au  
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11.  
XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. 
Lower Bay

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

[Voytek]

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

Re: ot: poor repution work arounds? standby smtp?

[Voytek]

On Mon, June 6, 2016 8:27 pm, Wietse Venema wrote:


Wietse, thanks

> Stuck in the queue with a 5xx (hard reject) reply?

yes:

-Queue ID- --Size-- Arrival Time -Sender/Recipient---
78DFF4BEAC   335977 Mon Jun  6 14:59:30  serv...@aa.com
(host mail2.b.com[217.xx.xx.xx] refused to talk to me:
554-mail1.b.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.


> There is smtp_fallback_relay, but that is normally used for delivery
> to slow destinations, not destinations that hard-reject email.

Re: RBLs in postscreen AND smtpd_*_restrictions

[Bill Cole]

On 5 Jun 2016, at 2:30, Peter wrote:


On 05/06/16 17:10, Michael Fox wrote:
Right.  As I mentioned, I understand that part.  My question was 
about v3.1+
where the default for postscreen_dnsbl_min_ttl is only 60s.  And, as 
I
understand it, the defaults for v3.1 would cause both the postscreen 
cache
ttl and the system resolver's cache ttl to be based on the same ttl 
from the
actual DNSBL record, thus rendering the same result for both, and the 
same

timeout for both.

Unless I've got that wrong, no need to respond.


I think you have it mostly right, but there are some cases where the
results could differ between postscreen and smtpd:

1.  There will be a very small window of time (we're talking
milliseconds) between when postscreen checks the expire time and when
smtpd attempts to lookup the record.  The DNS record could expire 
during
this very small window of time and if it has changed since the last 
time

that the resolver fetched the record the result could be different.

2.  The resolver might be broken and not caching the record, or 
caching

it for a shorter or longer period of time than the TTL states.

3.  You could (as is common) have two different resolvers listed in 
your
resolv.conf (or your OSes equivalent) file.  These resolvers could 
have

cached the record at different times, and if the record was updated in
between they could have different results.  It is possible that
postscreen could have randomly hit one resolver and smtpd hits the 
other

thereby giving different results.


4. The resolver cache honors (as most do) a DNSBL's negative cache TTL 
which is less than 60 seconds, e.g. Spamcop (0 seconds) or the various 
Spamhaus lists (10) and others.

check_sender_regexp - multiple relay IP`s

[Zalezny Niezalezny]

Hi,

I just would like to know if its possible to configure muliple IP`s of SMTP
servers in this configuration file:

check_sender_access regexp:/etc/postfix/check_sender_regexp



At the moment we are forwarding message with following sender E-mail
address to one of our MS Exchange servers.


/zelezny.niezale...@domain.com/ FILTER smtp:[192.168.2.100]


How may I setup in this file some kind of "backup MX" server if
smtp:[192.168.2.100] will be down.
Is it possible to setup for example 3x IP`s ? If yes, how to do it ?

Single IP address of smtp relay in our high available environment is not
allowed. I cannot use local domain with MX records because dns lookup has
been disabled.

Maybe somebody will be able to support me here ?


Thanks in advance for any hints !




With kind regards

Zalezny

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

Re: greylist doesn't seem to be working? Setup correctly.

[Chalmers]

I see. A confusion of naming.
The .pl file is the file that comes wigh osx. Pretty much the same as the 
example in the docs.
But as mentioned, I'm going to remive it anyway.
Thanks.


-
From my iPhone.


> On 6 Jun 2016, at 11:16 am, Wietse Venema  wrote:
> 
> Robert Chalmers:
>> I have set up the greylist policy, exactly according to the postfix docs, 
>> but nothing seems to be getting generated in /var/mta - no database that is.
>> 
>> When reloading I get this.
>> 
>> postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter: 
>> greylist_time_limit=3600
> 
> You have no greyLIST service in master.cf.
> 
>> However, the documents say to put it in.
>> 
>> # Greylist policy server
>> #
>> greypolicyunix  -   n   n   -   0   spawn
>>  user=nobody:mail argv=/opt/local/bin/perl 
>> /usr/local/libexec/postfix/greylist.pl
> 
> You have a greyPOLICY service in master.cf.
> 
>> 11 ...
>> 12 # smtpd_policy_service_request_limit 
>>  
>> = 1
>> 
>> But ok, I remove the greylist_time_limit = 3600 and proceed, but there is no 
>> greylist.db being generated?
> 
> What is /usr/local/libexec/postfix/greylist.pl?
> 
>Wietse

Re: ot: poor repution work arounds? standby smtp?

[Wietse Venema]

Voytek:
> 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.)

Stuck in the queue with a 5xx (hard reject) reply?

> 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)

There is smtp_fallback_relay, but that is normally used for delivery
to slow destinations, not destinations that hard-reject email.

Wietse

Re: greylist doesn't seem to be working? Setup correctly.

[Wietse Venema]

Robert Chalmers:
> I have set up the greylist policy, exactly according to the postfix docs, but 
> nothing seems to be getting generated in /var/mta - no database that is.
> 
> When reloading I get this.
> 
> postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter: 
> greylist_time_limit=3600

You have no greyLIST service in master.cf.

> However, the documents say to put it in.
> 
> # Greylist policy server
> #
> greypolicyunix  -   n   n   -   0   spawn
>   user=nobody:mail argv=/opt/local/bin/perl 
> /usr/local/libexec/postfix/greylist.pl

You have a greyPOLICY service in master.cf.

> 11 ...
> 12 # smtpd_policy_service_request_limit 
>  = 
> 1
> 
> But ok, I remove the greylist_time_limit = 3600 and proceed, but there is no 
> greylist.db being generated?

What is /usr/local/libexec/postfix/greylist.pl?

Wietse

Re: greylist doesn't seem to be working? Setup correctly.

[Christian Kivalo]

On 2016-06-06 11:54, Robert Chalmers wrote:

I have set up the greylist policy, exactly according to the postfix
docs, but nothing seems to be getting generated in /var/mta - no
database that is.

When reloading I get this.

postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter:
greylist_time_limit=3600

However, the documents say to put it in.

# Greylist policy server
#
greypolicyunix  -   n   n   -   0   spawn
  user=nobody:mail argv=/opt/local/bin/perl
/usr/local/libexec/postfix/greylist.pl
#

and in main.cf


5 /etc/postfix/main.cf [1]:
6 greylist_time_limit [2] = 3600
7 smtpd_recipient_restrictions [3] =
8 ...
9 reject_unauth_destination [4]
10 check_policy_service [5] unix:private/greylist
11 ...
12 # smtpd_policy_service_request_limit [6] = 1


But ok, I remove the greylist_time_limit = 3600 and proceed, but there
is no greylist.db being generated?

Is greylisting a good thing?


I removed greylilsting from my setup, it needlessly slows things down 
and postscreen does most of the work already. I wouldn't bother setting 
it up.



 What am I doing wrong?
thanks

Robert Chalmers
rob...@chalmers.com.au

Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan
10.11.  XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024
HN-M101MBB. Lower Bay



Links:
--
[1] http://www.postfix.org/postconf.5.html
[2] http://www.postfix.org/postconf.5.html#transport_time_limit
[3] http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
[4] http://www.postfix.org/postconf.5.html#reject_unauth_destination
[5] http://www.postfix.org/postconf.5.html#check_policy_service
[6] 
http://www.postfix.org/postconf.5.html#smtpd_policy_service_request_limit


--
 Christian Kivalo

greylist doesn't seem to be working? Setup correctly.

[Robert Chalmers]

I have set up the greylist policy, exactly according to the postfix docs, but 
nothing seems to be getting generated in /var/mta - no database that is.

When reloading I get this.

postconf: warning: /usr/local/etc/postfix/main.cf: unused parameter: 
greylist_time_limit=3600

However, the documents say to put it in.

# Greylist policy server
#
greypolicyunix  -   n   n   -   0   spawn
  user=nobody:mail argv=/opt/local/bin/perl 
/usr/local/libexec/postfix/greylist.pl
#


and in main.cf

5 /etc/postfix/main.cf :
 6 greylist_time_limit 
 = 3600
 7 smtpd_recipient_restrictions 
 =
 8 ... 
 9 reject_unauth_destination 
 
10 check_policy_service 
 
unix:private/greylist
11 ...
12 # smtpd_policy_service_request_limit 
 = 1

But ok, I remove the greylist_time_limit = 3600 and proceed, but there is no 
greylist.db being generated?

Is greylisting a good thing? 
 What am I doing wrong?
thanks


Robert Chalmers
rob...@chalmers.com .au 
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11.  
XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. 
Lower Bay

ot: poor repution work arounds? standby smtp?

[Voytek]

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