Re: SSL Certificates

[Richard James Salts]

On 15 February 2017 6:47:31 PM AEDT, Viktor Dukhovni 
 wrote:
>
>> On Feb 15, 2017, at 2:27 AM, Sebastian Nielsen 
>wrote:
>> 
>> In Gmail jargong, means you have to set up SPF, DKIM and DMARC
>records.
>
>Please do not encourage novice users to configure DMARC.  This does
>much
>more harm than good.  DMARC is legitimately for the few likePayPal,
>abusively
>for too big to fail like Yahoo

Although it looks like the abusively too big to fail are doing a great job 
achieving failure. Both Yahoo and AOL continue to be less relevant as time 
passes. 

, and occasionally for experts who might
>know
>to configure it in report mode.  Publishing DMARC policies does not
>improve
>deliverability.

Re: SSL Certificates

[Viktor Dukhovni]

> On Feb 15, 2017, at 2:47 AM, Henry  wrote:
> 
> So you are saying there is no point in securing outbound email in postfix?

I am saying SSL certificates on the sending side have nothing (good)
to do with securing outbound mail.

As for whether DKIM and/or SPF will prove useful to you, that depends.
I steer clear of both, others find them useful.

I don't read most HOWTO guides, it is often hard to know whether the author
has any clue unless you already know enough to not need the guide.

-- 
-- 
Viktor.

Re: SSL Certificates

[Viktor Dukhovni]

> On Feb 15, 2017, at 2:27 AM, Sebastian Nielsen  wrote:
> 
> In Gmail jargong, means you have to set up SPF, DKIM and DMARC records.

Please do not encourage novice users to configure DMARC.  This does much
more harm than good.  DMARC is legitimately for the few likePayPal, abusively
for too big to fail like Yahoo, and occasionally for experts who might know
to configure it in report mode.  Publishing DMARC policies does not improve
deliverability.

-- 
Viktor.

Re: SSL Certificates

[Henry]

thanks Viktor. this is what I was ultimately trying to achieve:
https://kolabsys.com/howtos/secure-kolab-server.html#postfix

So you are saying there is no point in securing outbound email in postfix?

On Wed, Feb 15, 2017 at 6:17 PM, Viktor Dukhovni
 wrote:
>
>> On Feb 15, 2017, at 2:10 AM, Henry  wrote:
>>
>> When I send a message to Gmail I am informed that it could not be
>> authenticated and will probably end in the spam folder.
>
> This is largely misinformation.  Sites that send bulk mail that might
> get classified as junk may benefit from DKIM signing and SPF records
> provided they also enroll in some kind of whitelisting program that
> requires such measures.
>
> Otherwise, since both DKIM and SPF are used as much by spammers as
> by non-spammers, there is no hard requirement to use these.  My
> domain does not use either.
>
> "Authentication" in the context of sending mail means either or both
> of DKIM or SPF.
>
>> I understand
>> the resolution to this is to obtain an SSL certificate and configure
>> postfix to use that certificate.
>
> That simply wrong.  Certificates have no bearing on outbound deliverability.
>
> http://postfix.1071664.n5.nabble.com/Best-way-to-run-Postfix-on-a-single-server-for-multiple-domains-td88720.html#a88811
>
> --
> Viktor.
>

Re: SSL Certificates

[Dominic Raferd]

On 15 February 2017 at 07:27, Sebastian Nielsen  wrote:
> No. That Email copuldn't been authenticated In Gmail jargong, means you have 
> to set up SPF, DKIM and DMARC records.
>
>
> -Ursprungligt meddelande-
> Från: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] För Henry
> Skickat: den 15 februari 2017 08:10
> Till: postfix-users@postfix.org
> Ämne: SSL Certificates
>
> When I send a message to Gmail I am informed that it could not be 
> authenticated and will probably end in the spam folder...

OP, can you tell us exactly what you mean by this? Are you forwarding
incoming mails to your own Gmail box or are these messages that you
send to a 3rd party who uses Gmail? Have you already set up DKIM
and/or SPF and/or DMARC on your domain? Do the emails end up in
Gmail's spam folder? Or are the emails bounced/rejected? Especially
what exactly does the Gmail warning to which you are referring say?

SV: SSL Certificates

[Sebastian Nielsen]

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


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

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

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

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

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

Testing SSL server localhost on port 587

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


My main.cf file is as follows:

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


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

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

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

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

readme_directory = no

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

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

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


# logging
smtpd_tls_loglevel = 1

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

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

# Insist on stronger ciphers
smtpd_tls_ciphers = high
smtp_tls_ciphers = high

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


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

Re: SSL Certificates

[Viktor Dukhovni]

> On Feb 15, 2017, at 2:10 AM, Henry  wrote:
> 
> When I send a message to Gmail I am informed that it could not be
> authenticated and will probably end in the spam folder.

This is largely misinformation.  Sites that send bulk mail that might
get classified as junk may benefit from DKIM signing and SPF records
provided they also enroll in some kind of whitelisting program that
requires such measures.

Otherwise, since both DKIM and SPF are used as much by spammers as
by non-spammers, there is no hard requirement to use these.  My
domain does not use either.

"Authentication" in the context of sending mail means either or both
of DKIM or SPF.

> I understand
> the resolution to this is to obtain an SSL certificate and configure
> postfix to use that certificate.

That simply wrong.  Certificates have no bearing on outbound deliverability.

http://postfix.1071664.n5.nabble.com/Best-way-to-run-Postfix-on-a-single-server-for-multiple-domains-td88720.html#a88811

-- 
Viktor.

SSL Certificates

[Henry]

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

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

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

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

Testing SSL server localhost on port 587

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


My main.cf file is as follows:

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


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

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

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

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

readme_directory = no

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

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

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


# logging
smtpd_tls_loglevel = 1

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

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

# Insist on stronger ciphers
smtpd_tls_ciphers = high
smtp_tls_ciphers = high

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


I am unsure of how to figure the fact that the certificate is for
mail.mydomain.com however the mail server is on our internal LAN
called hermes.mydomain.local

Re: milter macro names

[A. Schulze]

Am 14.02.2017 um 17:54 schrieb Matthias Schneider:
> This broke our milter 

Hello,

could you disclose the milter name and version?
Maybe others could avoid some trouble...

Andreas

Re: milter macro names (potential patch)

[Viktor Dukhovni]

> On Feb 14, 2017, at 4:06 PM, Matthias Schneider  
> wrote:
> 
> This patch works like a charm!
> Any chance to get this back into next stable release?

That's a question for Wietse, he may want to solve this in a different way,
or perhaps not at all (arguably your application should be able to deal with
either "{i}" or "i", as the two are semantically equivalent).

The present patch provides you with a stopgap solution, and serves to confirm
the origin of the symptoms.

If you are able to update the milter to deal with either "{i}" or "i", that
would be a good idea.

-- 
Viktor.

Re: milter macro names (potential patch)

[Viktor Dukhovni]

On Tue, Feb 14, 2017 at 09:43:25PM +0100, Matthias Schneider wrote:
> Hi Viktor,
> 
> i applyed the patch and after connecting to port 25 i'll get:
> 

Yes, sorry, the original patch is buggy, it fails to initialize
"cname" for already canonical (enclosed in {}) multi-char names.
Try this one instead:

diff --git a/src/milter/milter.c b/src/milter/milter.c
index 64836d4..571db7a 100644
--- a/src/milter/milter.c
+++ b/src/milter/milter.c
@@ -333,16 +333,19 @@ static ARGV *milter_macro_lookup(MILTERS *milters, const 
char *macro_names)
 VSTRING *canon_buf = vstring_alloc(20);
 const char *value;
 const char *name;
+const char *cname;
 
 while ((name = mystrtok(, CHARS_COMMA_SP)) != 0) {
if (msg_verbose)
msg_info("%s: \"%s\"", myname, name);
if (*name != '{')   /* } */
-   name = STR(vstring_sprintf(canon_buf, "{%s}", name));
-   if ((value = milters->mac_lookup(name, milters->mac_context)) != 0) {
+   cname = STR(vstring_sprintf(canon_buf, "{%s}", name));
+   else
+   cname = name;
+   if ((value = milters->mac_lookup(cname, milters->mac_context)) != 0) {
if (msg_verbose)
msg_info("%s: result \"%s\"", myname, value);
-   argv_add(argv, name, value, (char *) 0);
+   argv_add(argv, name[1] == '\0' ? name : cname, value, (char *) 0);
} else if (milters->macro_defaults != 0
 && (value = htable_find(milters->macro_defaults, name)) != 0) {
if (msg_verbose)

-- 
Viktor.

Re: milter macro names (potential patch)

[Matthias Schneider]

Hi Viktor,

i applyed the patch and after connecting to port 25 i'll get:

postfix/master[15476]: warning: process /usr/lib/postfix/sbin/smtpd pid 15593 
killed by signal 11
postfix/master[15476]: warning: /usr/lib/postfix/sbin/smtpd: bad command 
startup -- throttling

my code:

 /* milter_macro_lookup - look up macros */

  static ARGV *milter_macro_lookup(MILTERS *milters, const char *macro_names)
  {
  const char *myname = "milter_macro_lookup";
  char   *saved_names = mystrdup(macro_names);
  char   *cp = saved_names;
  ARGV   *argv = argv_alloc(10);
  VSTRING *canon_buf = vstring_alloc(20);
  const char *value;
  const char *name;
  const char *cname;

  while ((name = mystrtok(, CHARS_COMMA_SP)) != 0) {
  if (msg_verbose)
  msg_info("%s: \"%s\"", myname, name);
  if (*name != '{')   /* } */
  cname = STR(vstring_sprintf(canon_buf, "%s", name));
  if ((value = milters->mac_lookup(cname, milters->mac_context)) != 0) {
  if (msg_verbose)
  msg_info("%s: result \"%s\"", myname, value);
  argv_add(argv, name[1] == '\0' ? name : cname, value, (char *) 0);
  } else if (milters->macro_defaults != 0
   && (value = htable_find(milters->macro_defaults, name)) != 0) {
  if (msg_verbose)
  msg_info("%s: using default \"%s\"", myname, value);
  argv_add(argv, name, value, (char *) 0);
  }
  }
  myfree(saved_names);
  vstring_free(canon_buf);
  return (argv);
  }


Thank you,
Matthias Schneider

- Ursprüngliche Mail -
Von: "Viktor Dukhovni" 
An: postfix-users@postfix.org
Gesendet: Dienstag, 14. Februar 2017 20:43:42
Betreff: Re: milter macro names (potential patch)

On Tue, Feb 14, 2017 at 05:54:07PM +0100, Matthias Schneider wrote:

> I just tried to upgrade our postfix instances from 2.11 to 3.1. This broke
> our milter that is expecting macro with name "i" but we got "{i}".
> Could we make this configurable?

It may be simplest to revert to the original (braceless) form of
single-letter macros, I think that's more typically expected.

>From the Sendmail book:

Macros may have single-character names or multicharacter names.
Multicharacter names must always be enclosed in curly braces.
Single-character names may be enclosed in curly braces if you
desire. Prior to V8.7 you could use single characters only
without curly braces.

[ This does suggest that your milter application ought to be
  able to deal with either form, but theory and practice do
  at times differ. ]

Does the patch below resolve your issue?

diff --git a/src/milter/milter.c b/src/milter/milter.c
index 64836d4..bf2760a 100644
--- a/src/milter/milter.c
+++ b/src/milter/milter.c
@@ -333,16 +333,17 @@ static ARGV *milter_macro_lookup(MILTERS *milters, const 
char *macro_names)
 VSTRING *canon_buf = vstring_alloc(20);
 const char *value;
 const char *name;
+const char *cname;
 
 while ((name = mystrtok(, CHARS_COMMA_SP)) != 0) {
if (msg_verbose)
msg_info("%s: \"%s\"", myname, name);
if (*name != '{')   /* } */
-   name = STR(vstring_sprintf(canon_buf, "{%s}", name));
-   if ((value = milters->mac_lookup(name, milters->mac_context)) != 0) {
+   cname = STR(vstring_sprintf(canon_buf, "{%s}", name));
+   if ((value = milters->mac_lookup(cname, milters->mac_context)) != 0) {
if (msg_verbose)
msg_info("%s: result \"%s\"", myname, value);
-   argv_add(argv, name, value, (char *) 0);
+   argv_add(argv, name[1] == '\0' ? name : cname, value, (char *) 0);
} else if (milters->macro_defaults != 0
 && (value = htable_find(milters->macro_defaults, name)) != 0) {
if (msg_verbose)

-- 
Viktor.

Re: dict_ldap_lookup questions

[Viktor Dukhovni]

> On Feb 14, 2017, at 2:55 PM, Gomes, Rich  wrote:
> 
> Here is from a Test machine with very low mail traffic and the suggested 
> config changes:
> 
> real0m51.42s
> user0m0.05s
> sys 0m0.04s

50ms per query is a rather high lookup latency for LDAP.  Around ten years
back I was seeing ~2ms per query.  What's the network latency between the
MTA and the LDAP servers?  Are they too busy serving lookups from internal
interactive users?  Perhaps replica servers exclusively for the MTAs are
needed to isolate the MTAs from high user load and vice versa.

In any case it seems the LDAP server is quite slow.  Test with other filters,
e.g. 'mail=%s' or something similar that definitely hits an indexed attribute.
Perhaps authorization is slow, are there access controls that may be expensive
to evaluate, ...

> And here is from Prod with a high volume of traffic and the original 
> configuration:
> 
> real1m24.74s
> user0m0.05s
> sys 0m0.06s

The difference between 51ms and 85ms is not dramatic.  A performant LDAP
service would be around 1ms (~150km speed of light round-trip time).
Unless your LDAP servers are in a distant city, the performance you're
seeing is much too low.

-- 
Viktor.

RE: dict_ldap_lookup questions

[Gomes, Rich]

Here is from a Test machine with very low mail traffic and the suggested config 
changes:

real0m51.42s
user0m0.05s
sys 0m0.04s


And here is from Prod with a high volume of traffic and the original 
configuration:

real1m24.74s
user0m0.05s
sys 0m0.06s


Still trying to get the application folks to simulate the same volume of 
traffic in Test so we can definitively see if the changes made a difference.





-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Viktor Dukhovni
Sent: Friday, February 10, 2017 2:43 PM
To: Postfix users 
Subject: Re: dict_ldap_lookup questions


> On Feb 10, 2017, at 2:27 PM, Gomes, Rich  wrote:
> 
> The reason the query is setup like that is we have several internal 
> domains and a user may have an alias for one or all of them depending 
> on their employment history.

You've failed to understand my response.  The "proxyAddresses" attribute is 
multi-valued, and returns results of the form "smtp:".
Nothing in Postfix can uses such results, so you're better off returning a 
single-valued attribute such as "mail".

> Since it is working as expected, I'd rather leave it as is, unless you 
> feel it may be a contributor to the issue I am seeing.

The primary recommendation is to use "proxy:ldap:" rather than "ldap:".
You've not yet explained what you're using LDAP for.  Is this a 
relay_recipient_maps table?  Some other table that ignores the RHS value?
Have you tested lookup latency with:

$ domain=example.com # Replace with actual domain
$ i=0; while (( i < 1024 )); do
echo "$i-probe@$domain"
i=$(( i + 1 ))
  done | time postmap -q - ldap:/table/file.cf

The idea is to establish a single connection and then test ~1000 queries for 
distinct addresses (for a domain that matches the domain= constraints in the 
table definition).  The actual addresses need not exist in LDAP.

Report your results.

-- 
Viktor.

milter macro names

[Matthias Schneider]

Hi,

I just tried to upgrade our postfix instances from 2.11 to 3.1. This 
broke our milter that is expecting macro with name "i" but we got "{i}".

Could we make this configurable?

postfix 2.11:

.b...b.rDRi.3vN6Xk4v7ZzDwHS.{rcpt_addr}.matthias.schneider@

postfix 3.1:
6ZH.6ZHkDR{i}.3vN6VP5LlPz24hjY.{rcpt_addr}.matthias.schneider@


Thanks
Matthias Schneider

Re: Postfix 20 years ago

[Miles Fidelman]

Wietse,

Congratulations on the anniversary (or is that birthday).  And thank you 
for all the hard work!


Miles Fidelman

On Feb 12, 2017 21:07, "Wietse Venema" > wrote:


Last month it was 20 years ago that I started writing Postfix code.
After coming to IBM research in November 1996, I spent most of
December and January making notes on paper. I knew that writing a
mail system was more work than any of my prior projects.

The oldest tarball, dated 19970220, contains library functions plus
two early versions of the master daemon. There are 8086 lines of
code, 4204 lines after stripping the comments, and the only
documentation was my pile of hand-written notes.

For comparison, today's Postfix 3.2.0 RC1 release candidate weighs
in at 236533 lines of code, 137257 after stripping comments. The
documentation amounts to 32589 lines of hand-written HTML source,
plus 41878 lines of auto-generated HTML.

Much of today's effort is not visible as new features (thought there
still are enough to make an upgrade worthwhile), but happens behind
the scenes as improvements to internal code, and updated tests to
ensure that future changes won't inadvertantly break something.

Wietse



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Postfix 20 years ago

[Stephen Satchell]

On Feb 12, 2017 21:07, "Wietse Venema"  wrote:
> Last month it was 20 years ago that I started writing Postfix code.
> After coming to IBM research in November 1996, I spent most of
> December and January making notes on paper. I knew that writing a
> mail system was more work than any of my prior projects.
> 
> The oldest tarball, dated 19970220, contains library functions plus
> two early versions of the master daemon. There are 8086 lines of
> code, 4204 lines after stripping the comments, and the only
> documentation was my pile of hand-written notes.

Let me add my thanks to the accolades expressed by others on this list
to you, Mr. Venema, and the other regular contributors.  I've already
talked about how I found the versatility of PostFix fixed problems at a
Web hosting company; let me add my personal experiences to the story:

I was the first paying customer for DSL in Reno NV, and was awarded the
booby prize of having to use the mail servers that Pacific Telesys
provided for its customers.  I found myself locked out of sending mail
to many destinations because of SORBS and other DNSBLs reacting to the
spew coming from "those" servers.  The final straw was when I found
myself locked out of contributing to the Linux Kernel list.

That was in 2000, or 16 years ago.

I had my own domain, satchell.net, using Register.com's DNS servers, so
I decided to operate my own mail server to avoid some of the blocks I
encountered with the ISP mail servers.  I looked at Sendmail and Qmail,
and got depressed.  Then I discovered PostFix, and successfully set up
my own mail server on Red Hat 6 -- first on a DHCP-allocated address,
then a static IP when Nevada Bell opened DSL provisioning to third
parties.

My initial experience was very positive.  It was later when I started
loading up my library shelves with books on PostFix, to take advantage
of many more of the features that the program offers.

I've gone through four iterations of personal mail server boxes, and
will be building a fifth sometime in Q2 of this year, when CentOS 7 is
rumoured to incorporate a reasonable up-to-date version of Postfix.
(Or, I'll compile from source if I have to -- the new mail server will
be dedicated to mail only, with Dovecot for IMAP.)

Let me say that the experience of running a personal PostFix server was
part of the reason I got the job at the Web hosting company...and the
rest of that experience you already know.

Again, thank you.

RE: Postfix 20 years ago

[Paul A]

I first started using postfix around 1998 to handle mail for a small privately 
help ISP I still work for today in MA. It’s been a pleasure using your 
software, it’s simple well written and to me the best MTA there is. Like others 
I remember being frustrated at the other MTA, especially when I was just 
starting out.  I switched to your program I couldn’t help but notice how simple 
it was to get it up and running an how reliable it was.  

Thanks for your contribution to the internet.

Paul 



On Feb 12, 2017 21:07, "Wietse Venema"  wrote:
Last month it was 20 years ago that I started writing Postfix code.
After coming to IBM research in November 1996, I spent most of
December and January making notes on paper. I knew that writing a
mail system was more work than any of my prior projects.

The oldest tarball, dated 19970220, contains library functions plus
two early versions of the master daemon. There are 8086 lines of
code, 4204 lines after stripping the comments, and the only
documentation was my pile of hand-written notes.

For comparison, today's Postfix 3.2.0 RC1 release candidate weighs
in at 236533 lines of code, 137257 after stripping comments. The
documentation amounts to 32589 lines of hand-written HTML source,
plus 41878 lines of auto-generated HTML.

Much of today's effort is not visible as new features (thought there
still are enough to make an upgrade worthwhile), but happens behind
the scenes as improvements to internal code, and updated tests to
ensure that future changes won't inadvertantly break something.

Wietse

Re: Postfix 20 years ago

[jin]

Hi

Thanks you for all efforts on postfix. But actual thanks goes to your
patience. Becouse, if i have a question i know you have an answer even if i
do not have any idea what is the problem.

On Feb 12, 2017 21:07, "Wietse Venema"  wrote:

> Last month it was 20 years ago that I started writing Postfix code.
> After coming to IBM research in November 1996, I spent most of
> December and January making notes on paper. I knew that writing a
> mail system was more work than any of my prior projects.
>
> The oldest tarball, dated 19970220, contains library functions plus
> two early versions of the master daemon. There are 8086 lines of
> code, 4204 lines after stripping the comments, and the only
> documentation was my pile of hand-written notes.
>
> For comparison, today's Postfix 3.2.0 RC1 release candidate weighs
> in at 236533 lines of code, 137257 after stripping comments. The
> documentation amounts to 32589 lines of hand-written HTML source,
> plus 41878 lines of auto-generated HTML.
>
> Much of today's effort is not visible as new features (thought there
> still are enough to make an upgrade worthwhile), but happens behind
> the scenes as improvements to internal code, and updated tests to
> ensure that future changes won't inadvertantly break something.
>
> Wietse
>

Re: Best way to run Postfix on a single server for multiple domains

[Nitin N]

Dear Rob,

Thank you for all your words of wisdom and for sharing your postscreen
recommendations.

I also checked out your Youtube video talk on postscreen.

It was good to see you in person :)

Warm regards,

Nitin

Ps: My earlier reply to you bounced back from the list as I had the word
'config' instead of 'recommendations' on in my first sentence :)

On Mon, Feb 13, 2017 at 9:00 PM, /dev/rob0  wrote:

> On Mon, Feb 13, 2017 at 12:20:45PM +0530, Nitin N wrote:
> > Dear Rob (I hope that is your name),
>
> That works, but I also answer to "hey you" and various epithets (you
> can even google up a few from this very list. ;) )
>
> > On Sat, Feb 11, 2017 at 8:53 PM, /dev/rob0  wrote:
> > > On Sat, Feb 11, 2017 at 01:55:26PM +0530, Nitin N wrote:
>
> > > > Method 2]
> > > >
> > > > Use postmulti and create a separate instance for each domain.
> > > > In this case, I am not sure how complex it might get if I want
> > > > to create further instances for each domain to handle outgoing,
> > > > incoming and null-client scenarios.
> > >
> > > Why would you want to do this?  If you're seeking Perfect
> > > Headers, why?  Users mostly can't read nor understand headers.
> >
> > [Nitin:]
> > One reason why we would like to have Perfect Headers is that one
> > of the domains is a B2C platform where many users can register. We
> > want to reduce all possibilities (as much as we can) of our first
> > email to these users from getting marked as Spam. So, we believe
> > having a CA Trusted certificate might just add some more
> > credibility in this scenario.
>
> It probably won't help.
>
> Deliverability is a frequent concern for small sites, and there is no
> single clear answer (nor group of answers) that will guarantee Inbox
> access.  Thank the spammers, sigh.
>
> The main steps are:
>
>   1. FCrDNS: your PTR value is $myhostname, which in turn resolves to
>  your IP address.  If you don't control the PTR you're sunk.
>   2. IP Reputation (more on that to follow)
>   3. Clean non-spammy practices (likewise)
>
> IP reputation depends mostly on clean, non-spammy practices, but it
> could also be linked to issues partly beyond your control, such as
> your hosting ISP's reputation for abuse.  I say "partly" because you
> always have the option to move to better-regarded hosting.
>
> You can possibly improve your own reputation by signing up for
> DNSWL.org (and possibly other whitelisting services.)  I use DNSWL
> myself with the postscreen_dnsbl_whitelist_threshold feature, and it
> is very useful.
>
> I doubt any major providers use DNSWL directly, but I bet they check
> their spam blocking against it.
>
> "Clean" means, of course, that you must not be the source of UBE, nor
> should you forward any UBE from your system to others.  "Spammy
> practices" ... well, there are a lot of those, but they mostly boil
> down to attempts to evade blacklisting.  If you're consistently
> sending from a single IP address (or netblock if you're big enough,
> but I don't think you'd be asking here if you were that big), with
> static forward and reverse DNS entries, you're not looking like a
> blacklist evader.
>
> Another spammy practice which might look tempting is to send
> "reminders" about registration emails.  You should only send ONE
> single verification email, because before address verification you
> have no way to know that it was a valid address.
>
> > Honestly, I am not sure if we are being paranoid here since you
> > mention below that MTAs don't really verify if the certificate used
> > by another MTA is in fact Trusted or not.
>
> Right.  And I said "probably won't help" above because it's possible
> that some providers might do occasional checks of certificates.  But
> it certainly won't matter that "example.net" hosts handle mail from
> send...@example.com.
>
> > > > Method 3]
> > > >
> > > > Use FreeBSD jails for each domain and a common jail for all the
> > > > spam/virus protection services and use a proxy + NAT on the
> > > > main host. This could also help me use postmulti in each jail
> > > > in case I need to have multiple instances based on functions.
> > > >
> > > > So based on your experience/expertise, which method would you
> > > > recommend?
> >
> > Seems like not many have tried Method 3]. I think it might be a
> > good path to take from a scalability/security point of view,
> > although Jails do add some additional overhead from a maintenance
> > perspective.
>
> It seems like a lot of fuss for no actual benefit.  You get the warm
> fuzzies when you examine your Received: headers, but that's not
> getting you out of spam folders.
>
> > > > Further, do you think I can stop using Postgrey as I also have
> > > > Postscreen enabled?
> > >
> > > With after-220 tests enabled, postscreen will easily block
> > > anything postgrey might have blocked.  Also, greylisting, ISTM,
> > > is mostly defeated by spammers' current methods.  It's typical
> > > for zombies to go through 

Re: Postfix 20 years ago

[Nitin N]

Dear Wietse,

I have been using Postfix since 2005/6 when I moved away from Qmail. It has
simply been a pleasure to use Postfix for its robustness, simplicity,
security and stability.

You, for creating Postfix, and the other contributors, have been a blessing
for a lot of people out there who would have been frustrated otherwise
using MTAs that did not really make it so easy to use and maintain.

Further, giving it away for free is never easy. But you chose to do so.

That reflects on your character and shows that you created Postfix purely
out of your love and passion for a good software that will be genuinely
useful. It takes a lot of passion, courage and love to achieve what you
have.

You are a true champion Wietse and your team are full of superstars. I
respect you for being the person behind Postfix as much as I love your
excellent software.

Thank you so very much!

May God bless you and your team!

Nitin

Ps: Just noticed I had not "replied-all" to Wietse's email, so posted my
message above as-is for the group.

Re: Best way to run Postfix on a single server for multiple domains

[Nitin N]

Dear Viktor,

Thanks for pointing out.

My config currently does not alter the defaults for the settings mentioned
by you.

Warm regards,

Nitin

On Mon, Feb 13, 2017 at 9:34 PM, Viktor Dukhovni  wrote:

>
> > On Feb 13, 2017, at 10:30 AM, /dev/rob0  wrote:
> >
> >> [Nitin:]
> >> One reason why we would like to have Perfect Headers is that one
> >> of the domains is a B2C platform where many users can register. We
> >> want to reduce all possibilities (as much as we can) of our first
> >> email to these users from getting marked as Spam. So, we believe
> >> having a CA Trusted certificate might just add some more
> >> credibility in this scenario.
>
> It should perhaps be pointed out that certificates have a negligible
> (likely negative) impact on (outbound) deliverability because receiving
> servers rarely request client certificates from sending systems, and
> when they are requested, they are at best ignored.
>
> Some receiving systems shoot themselves in the foot and abort TLS
> handshakes with client-certificates they don't like for various silly
> reasons.  The mail is then often delivered in the clear instead.  The
> solution to that problem is to follow the advice in the Postfix docs
> and to NOT configure any client certificates.
>
>http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
>
>Do not configure client certificates unless you *must* present
>client TLS certificates to one or more servers. Client certificates
>are not usually needed, and can cause problems in configurations
>that work well without them. The recommended setting is to let the
>defaults stand:
>
>   smtp_tls_cert_file =
>   smtp_tls_key_file =
>   smtp_tls_dcert_file =
>   smtp_tls_dkey_file =
>   smtp_tls_eccert_file =
>   smtp_tls_eckey_file =
>
> We may at some point in the next year or two have a spec for
> DANE client TLSA records.  At that point, client certificates
> may start to be used for reasons other than to impede email
> delivery.  Broad use is at least a decade away...
>
> --
> Viktor.
>
>

Re: Postfix 20 years ago

[Eray Aslan]

On Mon, Feb 13, 2017 at 09:57:56AM +0100, Patrick Ben Koetter wrote:
> Postfix is Postfix because you made it that way. It breathes your spirit,
> Wietse - your standards, your strictness and your mindset. I've learned a lot
> from you over all the years.
> 
> Postfix is my role model for good software. When we build tools, services,
> platforms I often catch myself thinking "How would Postfix do that?". I owe
> you a lot!

Nicely said.  Reading the code and the answers in this list thought me
a lot over the years.  One might even say that it helped me define my
own set of standards and thinking regarding how a software should
behave.  Thank you.

-- 
Eray