date:20130918

On 9/18/2013 4:27 AM, Emmanuel Fusté wrote:
 Le 18/09/2013 05:40, Viktor Dukhovni a écrit :
 On Wed, Sep 18, 2013 at 01:00:48PM +1000, li...@sbt.net.au wrote:

 Return-Path: bayedfresc...@reuters.com
 ...
 Received: from p2p (unknown [124.11.170.87])
   by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
   for vvv...@domain.tld; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
 Everything below this Received header is fiction.  The EHLO name
 is not an FQDN and the IP address does not have matching forward
 and reverse addresses.

 You could try:

  main.cf:
 # Preferred RE map type:
 RE = pcre:${config_directory}/

 # HELO restrictions for remote clients
 smtpd_helo_required = yes
 smtpd_helo_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated,
 check_helo_access ${RE}helo.re

  helo.re
 # Clients with non-fqdn HELO names MUST have working FCrDNS
 /^[^.]*$/reject_unknown_client_hostname


 [...]
 Hello Viktor,
 
 In an access table, could I use any postfix reject_xxx and
 permit_xxx directive ?
 I did not find it in the documentation. It could be very powerfull.

It's mentioned, sparsely, in access(5):

OTHER ACTIONS
   restriction...
Apply the named UCE restriction(s) (permit, reject,
reject_unauth_destination, and so on).

No, you cannot use any restriction.  You must use only those that
apply to the context of the check_foo_access restriction which targets
the table.  However, if you think clearly about this for a moment,
you'll realize that these nested restrictions using tables are
completely unnecessary.

What Viktor is doing here is suggesting a workaround using a barely
documented trick in an effort to make something work which should
already be working, but is not.  I already stated what I believe the
problem is and the simple solution.  Just because you're seeing
something used in a way you didn't previously know was possible does not
mean it is powerful, nor something you should try to imitate.  And in
fact trying to use this will very likely only cause you additional
problems, while solving none.

-- 
Stan

Re: anlyzing sudden spam flood, how?

Emmanuel Fust?:
 In an access table, could I use any postfix reject_xxx and 
 permit_xxx directive ?
 I did not find it in the documentation. It could be very powerfull.

It *is* documented.

OTHER ACTIONS
   restriction...
  Applythe   named   UCE   restriction(s)   (permit,   reject,
  reject_unauth_destination, and so on).

Wietse

Re: anlyzing sudden spam flood, how?

Wietse Venema:
 Emmanuel Fust?:
  In an access table, could I use any postfix reject_xxx and 
  permit_xxx directive ?
  I did not find it in the documentation. It could be very powerfull.
 
 It *is* documented.
 
 OTHER ACTIONS
restriction...
   Applythe   named   UCE   restriction(s)   (permit,   reject,
   reject_unauth_destination, and so on).

And, this is in fact the supported way to implement per-sender (or
per-client, per-recipient, etc.) access policies. You index the
table with the sender (or client, recipient, etc.) and specify
some policy on the right-hand side. You can use this in the 
middle of a longer access list.

Wietse

cannot get RSA certificate from file

2013-09-18 Thread Florian Lindner

Hello,

since a certificate recreation (new CSR with 2048 key size) STARTTLS with 
postfix seems to have stopped working. Apache SSL works fine, using the same 
certificate.

postfix/tlsmgr[8892]: warning: request to update table 
btree:/var/spool/postfix/smtpd_scache in non-postfix directory 
/var/spool/postfix
postfix/tlsmgr[8892]: warning: redirecting the request to postfix-owned 
data_directory /var/lib/postfix
postfix/tlsmgr[8892]: warning: request to update table 
btree:/var/spool/postfix/smtp_scache in non-postfix directory /var/spool/postfix
postfix/tlsmgr[8892]: warning: redirecting the request to postfix-owned 
data_directory /var/lib/postfix
postfix/smtpd[8890]: warning: cannot get RSA certificate from file 
/etc/ssl/www.cardio-control.de.cert: disabling TLS support
postfix/smtpd[8890]: warning: TLS library problem: 8890:error:0D07209B:asn1 
encoding routines:ASN1_get_object:too long:asn1_lib.c:142:
postfix/smtpd[8890]: warning: TLS library problem: 8890:error:0D068066:asn1 
encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1303:
postfix/smtpd[8890]: warning: TLS library problem: 8890:error:0D07803A:asn1 
encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
error:tasn_dec.c:380:Type=X509_CERT_AUX:
postfix/smtpd[8890]: warning: TLS library problem: 8890:error:0906700D:PEM 
routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83:
postfix/smtpd[8890]: warning: TLS library problem: 8890:error:140DC009:SSL 
routines:SSL_CTX_use_certificate_chain_file:PEM lib:ssl_rsa.c:729:

Distribution is Debian Squeeze with postfix 2.7.1.

main.cf:

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/www.cardio-control.de.cert
smtpd_tls_key_file=/etc/ssl/www.cardio-control.de.key
smtpd_tls_CAfile=/etc/ssl/ca_certificate.crt
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

The path to the certificate file is correct, it looks like

# cat  /etc/ssl/www.cardio-control.de.cert
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

# cat  /etc/ssl/www.cardio-control.de.key 
-BEGIN RSA PRIVATE KEY-
[...]
-END RSA PRIVATE KEY-

What could be wrong here?

Thanks,
Florian

Re: anlyzing sudden spam flood, how?

2013-09-18 Thread Emmanuel Fusté


Le 18/09/2013 12:48, Wietse Venema a écrit :

Wietse Venema:

Emmanuel Fust?:

In an access table, could I use any postfix reject_xxx and
permit_xxx directive ?
I did not find it in the documentation. It could be very powerfull.

It *is* documented.

OTHER ACTIONS
restriction...
   Applythe   named   UCE   restriction(s)   (permit,   reject,
   reject_unauth_destination, and so on).

And, this is in fact the supported way to implement per-sender (or
per-client, per-recipient, etc.) access policies. You index the
table with the sender (or client, recipient, etc.) and specify
some policy on the right-hand side. You can use this in the
middle of a longer access list.

Wietse

Ok, got it, thank you.
I think that it deserve more than just this paragraph.
I was looking how to do better per sender access policy and completely 
overlook this paragraph !

I'm sorry, all my apologies.

Emmanuel.

Re: anlyzing sudden spam flood, how?

2013-09-18 Thread lists

On Wed, September 18, 2013 2:54 pm, Stan Hoeppner wrote:
 On 9/17/2013 10:40 PM, Viktor Dukhovni wrote:

 reject_non_fqdn_sender, reject_non_fqdn_recipient,
 reject_invalid_hostname, reject_non_fqdn_hostname,
 This should have blocked the example message, but did not.  Why?
 He's using Postfix 2.6.6.  The parms in his current config that would
 have triggered are for 2.2 or older, thus ignored I assume.  He should be
 using
 reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
 which should trigger on this.

I've updated the syntax as per above, BUT, my fault was that the address
in question was exempted in recipient_no_checks,
for other users, the old-syntax was working, now updated

thanks again for helping, everyone

-
smtpd_recipient_restrictions =
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/recipient_no_checks,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_invalid_helo_hostname,
 reject_non_fqdn_helo_hostname,
 reject_unknown_sender_domain,
 reject_unknown_reverse_client_hostname,
 reject_unlisted_recipient,
 check_sender_access hash:/etc/postfix/freemail_access,
 check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_client_access hash:/etc/postfix/client_checks,
 check_client_access pcre:/etc/postfix/client_checks.pcre,
 reject_rbl_client zen.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 reject_rbl_client psbl.surriel.com,
 reject_rbl_client bl.spamcop.net,
 reject_rhsbl_sender dsn.rfc-ignorant.org,
 check_policy_service inet:127.0.0.1:10031,
 permit

Re: Reverse DNS unknown

2013-09-18 Thread Dave Jones

On 9/16/2013 5:41 PM, Dave Jones wrote:

 Received: from mail02.corp.ena.net (unknown [96.4.3.90])
  by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
  for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)

 My forward DNS lookup for this host is an internal IP address that
 doesn't not match the public but it has been this way for years.

 You need to do your tests as the postfix user, possibly also
 chrooted.  Turn off the chroot flag in master.cf for testing.

I don't have anything chrooted (all n's in that column of the master.cf).
The dig as the postfix user returns the same result.

  I
 didn't think the unknown above is dependent on FCRDNS.

 but it is. For the conditions postfix will label a host as unknown,
 please see
 http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

I am using reject_unknown_reverse_client_hostname in
smtpd_recipient_restrictions but the server in question is covered by
permit_mynetworks which is before it.

 In the Received: header, the first name is the HELO name given, the
 second is either the FCRDNS or unknown. Postfix will also log a
 warning explaining why the host is unknown.

I see this in the maillog now that you mention it.  It seems more
informational than the cause of the unknown since I am using the
weaker restriction above.

warning: hostname mail02.corp.ena.net does not resolve to address 96.4.3.90

Based on the reasons at
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname,
it shouldn't be unknown with the postfix user being able to resolve
the PTR.

 I don't know if the unknown by itself will trigger the
 SpamAssassin RDNS_NONE rule, but that seems a little strict to me.

On Mon, Sep 16, 2013 at 7:00 PM, Noel Jones njo...@megan.vbhcs.org wrote:
 On 9/16/2013 5:41 PM, Dave Jones wrote:

 Received: from mail02.corp.ena.net (unknown [96.4.3.90])
  by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
  for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)

 My forward DNS lookup for this host is an internal IP address that
 doesn't not match the public but it has been this way for years.

 You need to do your tests as the postfix user, possibly also
 chrooted.  Turn off the chroot flag in master.cf for testing.


  I
 didn't think the unknown above is dependent on FCRDNS.

 but it is. For the conditions postfix will label a host as unknown,
 please see
 http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

 In the Received: header, the first name is the HELO name given, the
 second is either the FCRDNS or unknown. Postfix will also log a
 warning explaining why the host is unknown.

 I don't know if the unknown by itself will trigger the
 SpamAssassin RDNS_NONE rule, but that seems a little strict to me.


   -- Noel Jones

Re: anlyzing sudden spam flood, how?

Emmanuel Fust?:
[ Charset ISO-8859-1 unsupported, converting... ]
 Le 18/09/2013 12:48, Wietse Venema a ?crit :
  Wietse Venema:
  Emmanuel Fust?:
  In an access table, could I use any postfix reject_xxx and
  permit_xxx directive ?
  I did not find it in the documentation. It could be very powerfull.
  It *is* documented.
 
  OTHER ACTIONS
  restriction...
 Applythe   named   UCE   restriction(s)   (permit,   
  reject,
 reject_unauth_destination, and so on).
  And, this is in fact the supported way to implement per-sender (or
  per-client, per-recipient, etc.) access policies. You index the
  table with the sender (or client, recipient, etc.) and specify
  some policy on the right-hand side. You can use this in the
  middle of a longer access list.
 
  Wietse
 Ok, got it, thank you.
 I think that it deserve more than just this paragraph.
 I was looking how to do better per sender access policy and completely 
 overlook this paragraph !
 I'm sorry, all my apologies.

No need to apologize.

The problem is not a shortage of documentation (there even is a
separate document titled Postfix Per-Client/User/etc. Access
Control with examples of per-sender etc. policies).

The problem is that many Postfix mechanisms are designed to be
combined with other Postfix mechanisms. Unfortunateoly, is not
practical to describe in the manpage for feature X (for example,
access map) how it can be combined with other features A, B, and
so on (for example, permit_xx, reject_xx).  That would greatly
expand the documentation, and even fewer people would read it.

Wietse

Wietse

Verification of DANE TLSA MX equivalent RRs

2013-09-18 Thread Stefan Foerster

Hello world,

I'm not sure it this is the right place to ask, so if it's not, feel
free to tell me.

I configured DANE TLSA RRs for incertum.net, port 25 a few days ago,
but until now, the only test I could perform was bootstrapping a
recent Postfix snapshot and the latest OpenSSL and send myself a
message from this test installation - which is by no means a real
interoperability test.

Does someone know of any sites that either provide reflector like
services, verifying the sender's TLSA records, or perhaps a web based
verifier for TLSA RRs?

And while we are at it, one more question, slightly unrelated:
draft-dukhovni-dane-ops-01 does not mention MSAs. Is it commonly
expected that user agents will not support TLSA RRs?


Thanks
Stefan

Re: Reverse DNS unknown

Dave Jones:
 On 9/16/2013 5:41 PM, Dave Jones wrote:
 
  Received: from mail02.corp.ena.net (unknown [96.4.3.90])
   by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
   for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
 
  My forward DNS lookup for this host is an internal IP address that
  doesn't not match the public but it has been this way for years.
 
  You need to do your tests as the postfix user, possibly also
  chrooted.  Turn off the chroot flag in master.cf for testing.
 
 I don't have anything chrooted (all n's in that column of the master.cf).
 The dig as the postfix user returns the same result.

First, I can't fail to notice that the PTR record for 96.4.3.90
says mail02.corp.ena.net., but the A record for mail02.corp.ena.net.
resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
uses the name unknown instead of mail02.corp.ena.net.

Second, Postfix does not query DNS to determine the SMTP client
hostname. Instead, Postfix uses the system library getnameinfo()
and getaddrinfo() routines. Attached are small programs that
you can run to see what result Postfix would get.

Again, if the address-name result is not consistent with the
name-address result, Postfix will use unknown instead.

Wietse
 /*
  * getaddrinfo(3) (name-address lookup) tester.
  * 
  * Compile with:
  * 
  * cc -o getaddrinfo getaddrinfo.c (BSD, Linux)
  * 
  * cc -o getaddrinfo getaddrinfo.c -lsocket -lnsl (SunOS 5.x)
  * 
  * Run as: getaddrinfo hostname
  * 
  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
  * 
  * Author: Wietse Venema, IBM T.J. Watson Research, USA.
  */
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
#include unistd.h
#include string.h
#include stdlib.h

int main(int argc, char **argv)
{
charhostbuf[NI_MAXHOST];/* XXX */
struct addrinfo hints;
struct addrinfo *res0;
struct addrinfo *res;
const char *addr;
int err;

#define NO_SERVICE ((char *) 0)

if (argc != 2) {
fprintf(stderr, usage: %s hostname\n, argv[0]);
exit(1);
}
memset((char *) hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_flags = AI_CANONNAME;
hints.ai_socktype = SOCK_STREAM;
if ((err = getaddrinfo(argv[1], NO_SERVICE, hints, res0)) != 0) {
fprintf(stderr, host %s not found: %s\n, argv[1], gai_strerror(err));
exit(1);
}
printf(Hostname:\t%s\n, res0-ai_canonname);
printf(Addresses:\t);
for (res = res0; res != 0; res = res-ai_next) {
addr = (res-ai_family == AF_INET ?
(char *) ((struct sockaddr_in *) res-ai_addr)-sin_addr :
(char *) ((struct sockaddr_in6 *) res-ai_addr)-sin6_addr);
if (inet_ntop(res-ai_family, addr, hostbuf, sizeof(hostbuf)) == 0) {
perror(inet_ntop:);
exit(1);
}
printf(%s , hostbuf);
}
printf(\n);
freeaddrinfo(res0);
exit(0);
}
 /*
  * getnameinfo(3) (address-name lookup) tester.
  * 
  * Compile with:
  * 
  * cc -o getnameinfo getnameinfo.c (BSD, Linux)
  * 
  * cc -o getnameinfo getnameinfo.c -lsocket -lnsl (SunOS 5.x)
  * 
  * Run as: getnameinfo address
  * 
  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
  * 
  * Author: Wietse Venema, IBM T.J. Watson Research, USA.
  */
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
#include unistd.h
#include string.h
#include stdlib.h

int main(int argc, char **argv)
{
charhostbuf[NI_MAXHOST];/* XXX */
struct addrinfo hints;
struct addrinfo *res0;
struct addrinfo *res;
const char *host;
const char *addr;
int err;

#define NO_SERVICE ((char *) 0)

if (argc != 2) {
fprintf(stderr, usage: %s ipaddres\n, argv[0]);
exit(1);
}

/*
 * Convert address to internal form.
 */
host = argv[1];
memset((char *) hints, 0, sizeof(hints));
hints.ai_family = (strchr(host, ':') ? AF_INET6 : AF_INET);
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags |= AI_NUMERICHOST;
if ((err = getaddrinfo(host, NO_SERVICE, hints, res0)) != 0) {
fprintf(stderr, getaddrinfo %s: %s\n, host, gai_strerror(err));
exit(1);
}

/*
 * Convert host address to name.
 */
for (res = res0; res != 0; res = res-ai_next) {
err = getnameinfo(res-ai_addr, res-ai_addrlen,
  hostbuf, sizeof(hostbuf),
  NO_SERVICE, 0, NI_NAMEREQD);
if (err) {
fprintf(stderr, getnameinfo %s: %s\n, host, gai_strerror(err));
exit(1);
}
printf(Hostname:\t%s\n, hostbuf);
addr = (res-ai_family == AF_INET ?
(char *) ((struct sockaddr_in *) res-ai_addr)-sin_addr :
(char *) ((struct sockaddr_in6

Restrict

2013-09-18 Thread Andre Rodier

Hello everyone,

I have checked on the official postfix documentation, but I have not found any
explanation on how to do what I want. I am sorry if this question has been
asked before.

I am using postfix with virtual users, registered in an LDAP server. So far,
everything is working fine.

However, some users or some programs are sending emails using a From email
address that does not exists in the LDAP server.

I would like to know how to reject emails that came from an email address not
registered in the LDAP server. Obviously, I need to do that only internally,
i.e. on our domain.

Can anyone send me a link to the official documentation, or an example on how
to do this.

Thanks a lot.
Andre Rodier.

Re: anlyzing sudden spam flood, how?

On 9/18/2013 8:09 AM, li...@sbt.net.au wrote:
 On Wed, September 18, 2013 2:54 pm, Stan Hoeppner wrote:
 On 9/17/2013 10:40 PM, Viktor Dukhovni wrote:
 
 reject_non_fqdn_sender, reject_non_fqdn_recipient,
 reject_invalid_hostname, reject_non_fqdn_hostname,
 This should have blocked the example message, but did not.  Why?
 He's using Postfix 2.6.6.  The parms in his current config that would
 have triggered are for 2.2 or older, thus ignored I assume.  He should be
 using
 reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
 which should trigger on this.
 
 I've updated the syntax as per above, BUT, my fault was that the address
 in question was exempted in recipient_no_checks,

I only work with what I can verify.  You didn't provide the contents of
recipient_no_checks.  I try not to guess as that gets you into trouble.
 The only thing verifiably wrong was the syntax of those two restrictions.

 for other users, the old-syntax was working, now updated

That's strange.  Usually when new syntax is introduced the old syntax is
removed and no longer works.  2.3 - 2.6 seems a rather long grace
period.  Does the pre 2.3 syntax still work today?

-- 
Stan

Re: anlyzing sudden spam flood, how?

On Wed, Sep 18, 2013 at 08:54:50AM -0500, Stan Hoeppner wrote:

  This should have blocked the example message, but did not.  Why?
  He's using Postfix 2.6.6.  The parms in his current config that would
  have triggered are for 2.2 or older, thus ignored I assume.  He should be
  using reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
  which should trigger on this.

Stan is wrong, both forms work, the older form is deprecated, but
still works.

 I only work with what I can verify.  You didn't provide the contents of
 recipient_no_checks.  I try not to guess as that gets you into trouble.
  The only thing verifiably wrong was the syntax of those two restrictions.

Those were fine.  You did not read my posts upthread.

  for other users, the old-syntax was working, now updated
 
 That's strange.  Usually when new syntax is introduced the old syntax is
 removed and no longer works.  2.3 - 2.6 seems a rather long grace
 period.  Does the pre 2.3 syntax still work today?

With parameter renames, Postfix introduces backwards compatible defaults:

new_name = $old_name

with restriction class names the old form is left in place.  Incompatible
changes are avoided whenever possible.

-- 
Viktor.

Re: anlyzing sudden spam flood, how?

Stan Hoeppner:
  for other users, the old-syntax was working, now updated
 
 That's strange.  Usually when new syntax is introduced the old syntax is
 removed and no longer works.  2.3 - 2.6 seems a rather long grace
 period.  Does the pre 2.3 syntax still work today?

With Postfix, support for old syntax is removed from documentation,
but usually remains in the code. Examples are reject_unknown_hostname
and the use of an SMTPD access map without check_mumble_access. Old
syntax is removed when maintaining it becomes a problem.

Wietse

Re: Reverse DNS unknown

2013-09-18 Thread Dave Jones

 Dave Jones:
  On 9/16/2013 5:41 PM, Dave Jones wrote:
  
   Received: from mail02.corp.ena.net (unknown [96.4.3.90])
by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
  
   My forward DNS lookup for this host is an internal IP address that
   doesn't not match the public but it has been this way for years.
 
   You need to do your tests as the postfix user, possibly also
   chrooted.  Turn off the chroot flag in master.cf for testing.
 
  I don't have anything chrooted (all n's in that column of the master.cf
).
  The dig as the postfix user returns the same result.

 First, I can't fail to notice that the PTR record for 96.4.3.90
 says mail02.corp.ena.net., but the A record for mail02.corp.ena.net.
 resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
 uses the name unknown instead of mail02.corp.ena.net.

I fixed the A record to match the PTR (external NAT) and now it's showing
up properly:
Received: from mail02.corp.ena.net (mail02.corp.ena.net [96.4.3.90])
 by mr10.mail.ena.net (Postfix) with ESMTP id 5FA9114806F4

So there is no way to get Postfix to just show the PTR value in the headers
without validating anything?  It seems like MTAs should show the PTR value
to the left of the square brackets even when it doesn't match the HELO to
the left of the parenthesis.  If FCRDNS doesn't pass, I would think that
could be an additional string in the headers or something.  In this case,
the message has already been accepted so the reject_unknown_client_hostname
and reject_unknown_reverse_client_hostname logic for determining the
unknown value shouldn't apply and the PTR value should been shown.  In
this case, the PTR was correct in DNS but showed as unknown like it
didn't exist in DNS.

 Second, Postfix does not query DNS to determine the SMTP client
 hostname. Instead, Postfix uses the system library getnameinfo()
 and getaddrinfo() routines. Attached are small programs that
 you can run to see what result Postfix would get.

 Again, if the address-name result is not consistent with the
 name-address result, Postfix will use unknown instead.


On Wed, Sep 18, 2013 at 8:35 AM, Wietse Venema wie...@porcupine.org wrote:

 Dave Jones:
  On 9/16/2013 5:41 PM, Dave Jones wrote:
  
   Received: from mail02.corp.ena.net (unknown [96.4.3.90])
by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)
  
   My forward DNS lookup for this host is an internal IP address that
   doesn't not match the public but it has been this way for years.
 
   You need to do your tests as the postfix user, possibly also
   chrooted.  Turn off the chroot flag in master.cf for testing.
 
  I don't have anything chrooted (all n's in that column of the master.cf
 ).
  The dig as the postfix user returns the same result.

 First, I can't fail to notice that the PTR record for 96.4.3.90
 says mail02.corp.ena.net., but the A record for mail02.corp.ena.net.
 resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
 uses the name unknown instead of mail02.corp.ena.net.

 Second, Postfix does not query DNS to determine the SMTP client
 hostname. Instead, Postfix uses the system library getnameinfo()
 and getaddrinfo() routines. Attached are small programs that
 you can run to see what result Postfix would get.

 Again, if the address-name result is not consistent with the
 name-address result, Postfix will use unknown instead.

 Wietse

Re: Restrict

2013-09-18 Thread Ansgar Wiechers

On 2013-09-18 Andre Rodier wrote:
 However, some users or some programs are sending emails using a From
 email address that does not exists in the LDAP server.
 
 I would like to know how to reject emails that came from an email
 address not registered in the LDAP server. Obviously, I need to do
 that only internally, i.e. on our domain.
 
 Can anyone send me a link to the official documentation, or an example
 on how to do this.

I think reject_sender_login_mismatch is what you're looking for.

http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch

Regards
Ansgar Wiechers
-- 
Abstractions save us time working, but they don't save us time learning.
--Joel Spolsky

Re: Verification of DANE TLSA MX equivalent RRs

On Wed, Sep 18, 2013 at 03:27:14PM +0200, Stefan Foerster wrote:

I'm not sure it this is the right place to ask, so if it's not, feel
free to tell me.

This is Postfix related.

I configured DANE TLSA RRs for incertum.net, port 25 a few days ago,
but until now, the only test I could perform was bootstrapping a
recent Postfix snapshot and the latest OpenSSL and send myself a
message from this test installation - which is by no means a real
interoperability test.

DANE TLSA certificate checks (unlike testing access permissions)
are not depending on the client IP address or other origin-dependent
features. So your test is quite sufficient.

Does someone know of any sites that either provide reflector like
services, verifying the sender's TLSA records, or perhaps a web based
verifier for TLSA RRs?

Ralf's python.org mailing list MTA is DANE TLSA enabled, but it is
definitely not intended to be a test server. If you are subscribed
to one of the python lists, and still receiving email, that's another
data point.

I ran posttls-finger from my laptop, and got:

$ posttls-finger -t30 -T180 -c -L verbose,summary incertum.net
...
posttls-finger: using DANE RR: _25._tcp.mail.incertum.net IN TLSA 3 1 1
BD:52:FE:11:E0:F9:14:00:91:13:40:80:5F:4B:B7:A5:5C:8F:17:17:E8:AD:F2:2A:A0:72:E3:7B:68:33:6B:B6
...
posttls-finger: Verified TLS connection established to
mail.incertum.net[78.47.238.14]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So you're all set.

And while we are at it, one more question, slightly unrelated:
draft-dukhovni-dane-ops-01 does not mention MSAs. Is it commonly
expected that user agents will not support TLSA RRs?

You should be looking at the SMTP draft, not the OPS draft. I
think It is unlikely that MUAs will lead DANE adoption. Once major
MTA and MSA operators field DANE, MUAs may gradually also adopt
DANE, especially once they adopt SRV-record based zeroconf (for
otherwise in this case TLS provides negligible MITM protection).

--
Viktor.

Re: Reverse DNS unknown

Dave Jones:
 Received: from mail02.corp.ena.net (unknown [96.4.3.90])
  by mr11.mail.ena.net (Postfix) with ESMTP id 57C091480688
  for redac...@domain.com; Mon, 16 Sep 2013 16:04:46 -0500 (CDT)

Wietse:
 First, I can't fail to notice that the PTR record for 96.4.3.90
 says mail02.corp.ena.net., but the A record for mail02.corp.ena.net.
 resolves to 172.27.0.25. Therefore, it is no surprise that Postfix
 uses the name unknown instead of mail02.corp.ena.net.

Dave Jones:
 I fixed the A record to match the PTR (external NAT) and now it's showing
 up properly:
 Received: from mail02.corp.ena.net (mail02.corp.ena.net [96.4.3.90])
  by mr10.mail.ena.net (Postfix) with ESMTP id 5FA9114806F4
 
 So there is no way to get Postfix to just show the PTR value in the headers
 without validating anything?

Over my dead body. This name is used for logging and may be used
for access decisions. This is what audit trails and policies rely
on. 

Instead, you can put your mail02.corp.ena.net name and address in
/etc/hosts and then the Postfix SMTP daemon will use that (assuming
that your nsswitch.conf host lookups lists files before dns).

Wietse

Re: Restrict

On Wed, Sep 18, 2013 at 02:41:54PM +0100, Andre Rodier wrote:

 I am using postfix with virtual users, registered in an LDAP server. So far,
 everything is working fine.
 
 However, some users or some programs are sending emails using a From email
 address that does not exists in the LDAP server.
 
 I would like to know how to reject emails that came from an email address not
 registered in the LDAP server. Obviously, I need to do that only internally,
 i.e. on our domain.

http://www.postfix.org/postconf.5.html#reject_unlisted_sender
http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender

Note, this only constraints the message envelope sender, not the
message headers.  With headers you can canonicalize internal forms to
external forms via smtp_generic_maps, but I would strongly recommend
against attempting to reject.

-- 
Viktor.

Re: cannot get RSA certificate from file

On Wed, Sep 18, 2013 at 01:23:13PM +0200, Florian Lindner wrote:

 warning: request to update table btree:/var/spool/postfix/smtp_scache in 
 non-postfix directory /var/spool/postfix
 warning: redirecting the request to postfix-owned data_directory 
 /var/lib/postfix

 smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
 smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache

Change these to use ${data_directory} instead of ${queue_directory}.

-- 
Viktor.

Re: Verification of DANE TLSA MX equivalent RRs

2013-09-18 Thread Stefan Foerster

* Viktor Dukhovni postfix-us...@dukhovni.org:
 I ran posttls-finger from my laptop, and got:
[...]
 So you're all set.

Thanks for taking the time to do this, I appreciate it.

I noticed that posttls-finger is not part of any upstream source I
could find, leading me to github - is that intentional?


Stefan

Re: Verification of DANE TLSA MX equivalent RRs

On Wed, Sep 18, 2013 at 05:49:53PM +0200, Stefan Foerster wrote:

 I noticed that posttls-finger is not part of any upstream source I
 could find, leading me to github - is that intentional?

It is inaccurate.  The posttls-finger utility has been included in
Postfix snapshots since postfix-2.11-20130602.  The best snapshot
for DANE support at this time is:

postfix-2.11-20130825.

What is intentional is that while posttls-finger is compiled by
default, it is not by default installed into $command_directory by
postfix-install (because it is not listed in conf/postfix-files).

I have not yet convinced Wietse that this diagnostic tool should
be part of the required Postfix command set.  One might note that
smtp-sink and smtp-source are likewise not installed by default.

My take is that posttls-finger is more useful on a day-to-day basis
at sites that configure secure-channel TLS policy with peers, and/or
want to diagnose TLS interoperability issues.  Whether this is a
strong enough argument to include posttls-finger in the Postfix
pacakges delivered by O/S releases is a judgement call.

-- 
Viktor.

Re: postscreen postscreen_dnsbl_sites order

2013-09-18 Thread Marko Weber | ZBF


Hi Wietse,

Am 2013-09-04 23:45, schrieb wie...@porcupine.org:

Marko Weber | ZBF:

hello postfix list,

maybe an easy quest for you.
when i use multiple rbls in 'postscreen_dnsbl_sites'


Yes...


postscreen_dnsbl_sites =
   1.list.org
   anotherlist.org
   nsafools.org
   obamaisadrama.org

at example.  are the entries of 'postscreen_dnsbl_sites' used in
order like listed?  or is postscreen using them randomly?


They are searched in parallel. You can mix DNSWLs (with negative
weights) and DNSBLs (with positive weights) and override later
checks with postscreen_dnsbl_whitelist_threshold (Postfix 2.11).


'postscreen_dnsbl_whitelist_threshold' sounds interesting.



Wietse

Re: anlyzing sudden spam flood, how?

On 9/18/2013 9:07 AM, Wietse Venema wrote:
 Stan Hoeppner:
 for other users, the old-syntax was working, now updated

 That's strange.  Usually when new syntax is introduced the old syntax is
 removed and no longer works.  2.3 - 2.6 seems a rather long grace
 period.  Does the pre 2.3 syntax still work today?
 
 With Postfix, support for old syntax is removed from documentation,
 but usually remains in the code. Examples are reject_unknown_hostname
 and the use of an SMTPD access map without check_mumble_access. Old
 syntax is removed when maintaining it becomes a problem.
 
   Wietse


On 9/18/2013 9:06 AM, Viktor Dukhovni wrote:
 With parameter renames, Postfix introduces backwards compatible
 defaults:

   new_name = $old_name

 with restriction class names the old form is left in place.
 Incompatible changes are avoided whenever possible.


Thank you both for the explanation.  I've always updated my syntax soon
after changes are made and never really tested this.  Sorry for adding
noise to the thread.

-- 
Stan

Greylist Based on Error Code and 'org' Domain?

2013-09-18 Thread Christopher Kurtis Koeber

Hello,

 

I am wondering if it is possible to greylist email systems based on:

 

1.   An error code (450 Helo Command Rejected: Host not Found).

2.   If they are a 'org' domain. 

 

I don't want to reject these messages outright but an automatic greylisting
based on the above for these domains is what we are looking for.

 

We are finding that a lot of spam is being blocked based on not accepting
450'ed emails but we are blocking a sizable chunk of otherwise valid
messages.

 

Thank you for your time.

 

Regards,

 

Christopher Kurtis Koeber

Re: anlyzing sudden spam flood, how?

On 9/18/2013 6:50 PM, Voytek wrote:
 Stan Hoeppner s...@hardwarefreak.com wrote:
 On 9/18/2013 9:07 AM, Wietse Venema wrote:
 Stan Hoeppner:
 for other users, the old-syntax was working, now updated

 That's strange.  Usually when new syntax is introduced the old
 syntax is
 removed and no longer works.  2.3 - 2.6 seems a rather long grace
 period.  Does the pre 2.3 syntax still work today?

 With Postfix, support for old syntax is removed from documentation,
 but usually remains in the code. Examples are
 reject_unknown_hostname
 and the use of an SMTPD access map without check_mumble_access. Old
 syntax is removed when maintaining it becomes a problem.

 Wietse


 On 9/18/2013 9:06 AM, Viktor Dukhovni wrote:
 With parameter renames, Postfix introduces backwards compatible
 defaults:

 new_name = $old_name

 with restriction class names the old form is left in place.
 Incompatible changes are avoided whenever possible.


 Thank you both for the explanation.  I've always updated my syntax soon
 after changes are made and never really tested this.  Sorry for adding
 noise to the thread.

 -- 
 Stan
 
 the fact that I have 'old syntax' in the main.cf , does that imply that at 
 some point, instead of upgrading postfix, a new installation was done, and 
 old config files copied across? (which is a distinct possibility when server 
 was 'moved' from physical to vps), just curious.
 
 Thanks for all the help,

Wietse can answer this definitively.  I can only relay my experience,
which is, using the Debian Postfix packages for many years, it does not
appear that the upgrade process walks main.cf and updates syntax.

I do recall that somewhere around 2.9 Wietse added code to check for
some configuration related issues but I don't recall the specifics.
Maybe he can provide a more thorough answer.

-- 
Stan

Re: anlyzing sudden spam flood, how?

Stan Hoeppner:
 the fact that I have 'old syntax' in the main.cf , does that
 imply that at some point, instead of upgrading postfix, a new
 installation was done, and old config files copied across? (which
 is a distinct possibility when server was 'moved' from physical
 to vps), just curious.

Postfix as distributed by me will try to update main.cf as you
upgrade to a newer release, to avoid surprises.

For example, with Postfix 2.9 the inet_protocols default was changed
from ipv4 to all (on platforms where Postfix is built with IPv6
support). The idea is that eventually IPv6 will become mainstream.

However, such a change is problematic when a site has IPv6 support
in the kernel but not in the network infrastructure.  To avoid such
painful updates, the Postfix install/upgrade procedure sets
inet_protocols = ipv4 in main.cf when no explicit setting exists,
so that the change in default does not disrupt operations on sites
that have IPv4 connectivity only.

Of course some distributions don't implement my transitional safety
nets and cause chaos with their users.

Wietse

Re: Greylist Based on Error Code and 'org' Domain?