Re: tls_policy

[Birta Levente]

On 30/04/2015 09:58, Viktor Dukhovni wrote:

On Thu, Apr 30, 2015 at 09:25:48AM +0300, Birta Levente wrote:


Perhaps some sort of middle-box is interfering with TLS on your
end.  Also, what version of OpenSSL are you using?

Well "your end" can be anywhere between you and the Microsoft email
hosting mail servers.


I make a test on another server which is in totally other location, other
city, other ISP, but same OS, openssl and postfix.3.1.20150421

Can we rule out "Great Firewall of China"-style nation level
middleboxes?


Apr 30 08:55:06 srv2 postfix/smtp[4367]: SSL_connect error to
irs-ro.mail.eo.outlook.com[213.199.154.87]:25: lost connection
Apr 30 08:55:06 srv2 postfix/smtp[4367]: 3lcmBx5stxz7wX4:
   Cannot start TLS: handshake failure
Apr 30 08:55:06 srv2 postfix/smtp[4367]:
   SSL_connect error to irs-ro.mail.eo.outlook.com[213.199.154.23]:25:
   lost connection

I have no problem connecting to this host with default settings.


Apr 29 15:04:46 srv1 postfix/smtp[5398]: Untrusted TLS connection
established to mx4.hotmail.com[65.55.33.119]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-SHA384 (256/256 bits)

Hotmail.com is completely separate infrastructure.  You'd need to
find other domains with a ".mail.*.outlook.com" mailhost.
A somewhat more similar domain to test is "microsoft.com"

 $ dig +short -t mx microsoft.com
 10 microsoft-com.mail.protection.outlook.com.

Have you tried "swaks"? Or

 openssl s_client -starttls smtp -connect irs-ro.mail.eo.outlook.com:25



OK, I found the problem:
I had configured the smtp_tls_CAfile. Removing everything works fine.

Thanks for support

--
   Levi

Re: tls_policy

[Viktor Dukhovni]

On Thu, Apr 30, 2015 at 10:09:36AM +0300, Birta Levente wrote:

> OK, I found the problem:
> I had configured the smtp_tls_CAfile. Removing everything works fine.

Was the file malformed?  I have a hard time imagining any non-empty
set of well-formed certs in that file causing the problem you
describe.  Did the file contain any PEM X.509 certificates?

Does:

$ cafile=
$ openssl crl2pkcs7 -nocrl -certfile "$cafile" |
openssl pkcs7 -print_certs -noout |
grep -c '^issuer='

report any errors to stderr?  How many issuers were reported by
grep?

-- 
Viktor.

Re: tls_policy

[Birta Levente]

On 30/04/2015 10:17, Viktor Dukhovni wrote:

On Thu, Apr 30, 2015 at 10:09:36AM +0300, Birta Levente wrote:


OK, I found the problem:
I had configured the smtp_tls_CAfile. Removing everything works fine.

Was the file malformed?  I have a hard time imagining any non-empty
set of well-formed certs in that file causing the problem you
describe.  Did the file contain any PEM X.509 certificates?

Does:

 $ cafile=
 $ openssl crl2pkcs7 -nocrl -certfile "$cafile" |
openssl pkcs7 -print_certs -noout |
grep -c '^issuer='

report any errors to stderr?  How many issuers were reported by
grep?



No error and only 1 issuer, which was the cacert.org root certificate

--
   Levi

local transport: how to automatically create Maildir

[Алексей Доморадов]

 Hello,

I'm using local transport and system user with maildir. But when I sent mail in 
the log I see the following error

Apr 30 08:01:15 jira-srv01 postfix/local[20496]: warning: perhaps you need to 
create the maildirs in advance
Apr 30 08:01:15 jira-srv01 postfix/smtpd[20530]: disconnect from 
mail-la0-f51.google.com[209.85.215.51]
Apr 30 08:01:15 jira-srv01 postfix/local[20496]: 138F12002D4: 
to=, relay=local, delay=0.28, delays=0.21/0/0/0.07, 
dsn=5.2.0, status=bounced (maildir delivery failed: create maildir file 
/var/spool/mail/webmaster/tmp/1430380875.P20496.jira-srv01: Permission denied)

If I create dir manually and set corresponding permissions - all works fine

# mkdir /var/spool/mail/webmaster/
# chmod -R 700 /var/spool/mail/webmaster/
# chown -R webmaster:webmaster /var/spool/mail/webmaster/

Apr 30 08:03:07 jira-srv01 postfix/smtpd[20629]: disconnect from 
mail-la0-f46.google.com[209.85.215.46]
Apr 30 08:03:07 jira-srv01 postfix/local[20632]: DE9AF2002D4: 
to=, relay=local, delay=0.24, delays=0.19/0/0/0.05, 
dsn=2.0.0, status=sent (delivered to maildir)

# ls -la
total 20K
drwx--    5 webmaster webmaster 4.0K Apr 30 08:59 .
drwxrwxr-x 3 root         mail        4.0K Apr 30 08:01 ..
drwx--    2 webmaster webmaster 4.0K Apr 30 08:59 cur
drwx--    2 webmaster webmaster 4.0K Apr 30 08:59 new
drwx--    2 webmaster webmaster 4.0K Apr 30 08:59 tmp

But it's very uncomfortable to create maildir for each user manually. Are there 
any workaround?

P.S.
CentOS 6, postfix-2.6.6

Thanks in advance

Re: local transport: how to automatically create Maildir

[Koko Wijatmoko]

On Thu, 30 Apr 2015 12:12:33 +0300
Алексей Доморадов  wrote:

> But it's very uncomfortable to create maildir for each
> user manually. Are there any workaround?
> 
set "home_mailbox" to "Maildir/", and create "Maildir/{cur,new,tmp}"
at directory /etc/skel/, so on next adduser/useradd it will be
automatically create the correct requirement for maildir style inbox.

from main.cf:

# DELIVERY TO MAILBOX
#
# The home_mailbox parameter specifies the optional pathname of a
# mailbox file relative to a user's home directory. The default
# mailbox file is /var/spool/mail/user or /var/mail/user.  Specify
# "Maildir/" for qmail-style delivery (the / is required).
#
#home_mailbox = Mailbox
#home_mailbox = Maildir/

Re: Postfix forward mail to other server but leaving a copy...

[gilbertoferreira]

Hi...

Thanks for your answer, but I need this only for a few accounts... 
I thing use procmail or .forward rules...

Or other idea... 

Thanks



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-forward-mail-to-other-server-but-leaving-a-copy-tp76521p76569.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: What causes: User unknown in virtual mailbox table.

[Robert Chalmers]

@Nicolás

Fixed. Working. well 99%.  The problem was actually stupidly simple. On my part 
as usual.

station.master@quantum-radio SHOULD be station.manager@quantum-radio…. trust me 
to pick the one bad one to test with.

So now the original syntax for the query works.
>> query = SELECT 1 FROM virtual_users WHERE email='%s’

I checked the permissions as you suggested. That’s all ok.

It’s 99% working now. I had to track down a pam/password problem. I have mixed 
Virtual and Local users on the machine.
It appears to be ok.
So now the Virtual mailboxes are collecting mail, and so are the local users.

the mail directory is /var/mail/vhosts 

In which are appearing both the local and the virtual mailboxes.

drwxr-xr-x  4 vmail  vmail  136 28 Apr 12:29 quantum-radio.net 

drwx--  9 vmail  vmail  306 30 Apr 13:43 station.manager

under quantum-radio.net  is...
/private/var/mail/vhosts/quantum-radio.net
bash-3.2# ls -l
total 0
drwxr-xr-x  10 vmail  vmail  340 30 Apr 09:31 robert
drwxr-xr-x  10 vmail  vmail  340 30 Apr 13:56 station.manager

So I’m a little confused by all this now, and will take some time out. Mail is 
actually collecting in those mail-dire, but I can’t yet find a way to access it 
yet. !!!  Neither MailMate, or Apple Mail seem to want to look at it. hmmm. I 
guess they don’t know how to find it down in ghosts - but there will be a way.

anyway - thanks for your help and patience. much appreciated.

Robert



mysql> SELECT * FROM mailserver.virtual_users;
++---+---+---+
| id | domain_id | password  | email |
++---+---+---+

|  6 | 1 | xx| station.mas...@quantum-radio.net 
  |
xxx
++---+---+---+
11 rows in set (0.00 sec)
> On 29 Apr 2015, at 21:08, Nicolás  wrote:
> 
> (resending to list)
> 
> El 29/04/15 a las 19:34, Robert Chalmers escribió:
>> Ok, my /etc/postfix/mysql-virtual-mailbox-maps.cf
>> 
>> has:
>> user = mailman
>> password = xxx
>> hosts = 127.0.0.1
>> dbname = mailserver
>> query = SELECT 1 FROM virtual_users WHERE email='%s'
>> 
>> [...]
>> 
>> Using your syntax, I’m a little closer
>> 
>> postmap -q station.mana...@quantum-radio.net 
>>  
>> mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
>> postmap: warning: mysql query failed: You have an error in your SQL syntax; 
>> check the manual that corresponds to your MySQL server version for the right 
>> syntax to use near ''station.mana...@quantum-radio.net 
>> ???' at line 1
>> postmap: fatal: table mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf: 
>> query error: Undefined error: 0
>> 
> 
> Double check for syntax, quotation marks, ... in the query, it's likely you 
> missed copying the sentence correctly.
> 
>> [...]
>> 
>> I did have this 
>> virtual_mailbox_base = /var/mail/vhosts
>> 
>> [...]
> 
> Also check that this directory (and subdirectories) has the right permissions 
> so Postfix and your e-mail server can access them. Otherwise you'll get 
> errors.
> 
> Regards,
> 
> Nicolás
> 
>> 
>> 
>> 
>>> On 29 Apr 2015, at 16:51, Nicolás >> > wrote:
>>> 
>>> 
>>> El 29/04/15 a las 16:25, Robert Chalmers escribió:
 
 I have the following error when trying to send mail to a virtual domain on 
 the server.
 
 I’m afraid I can not find the source of this error.
 
 postfix/smtpd[901]: NOQUEUE: reject: RCPT from mail-yk0-f175.google.com 
 [209.85.160.175]: 550 5.1.1 
 >>> >: Recipient address rejected: 
 User unknown in virtual mailbox table; from=>>> > to=>>> > proto=ESMTP 
 helo=http://mail-yk0-f175.google.com/>>
 
 If this is not the appropriate mailing list for this type of question, can 
 someone please point me at a list that is? 
 thanks
 Robert
 
 
 robert$ postconf -n
 [...]
 virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
 [...]
>>> 
>>> What's the content of /etc/postfix/mysql-virtual-mailbox-maps.cf? For a 
>>> given e-mail address, it should return the path where the virtual user's 
>>> inbox is. For example:
>>> 
>>> user = db_username
>>> password = db_password
>>> dbname = db_name
>>> query = SELECT CONCAT(SUBSTRING_INDEX(email, '@', -1), '/', 
>>> SUBSTRING_INDEX(email, '@', 1), '/') FROM users WHERE email = '%s'
>>> hosts = 127.0.0.1
>>> 
>>> The query field assumes that an e-mail address like 
>>> station.mana...@quantum-radio.net 
>>>  will

Re: Is this a result of reject_unknown_sender_domain ?

[James B. Byrne]

On Wed, April 29, 2015 22:26, Viktor Dukhovni wrote:

>
> The fact that the same name fails HELO checks (which don't use the
> default suffixes) is not unexpected.
>

Actually, my suspicion was that this was a case of cause and effect. 
The reject due to the host name lookup failure was the result of the
process that was generating the additional dns queries.   I just want
to find out if the behaviour is expected or abnormal.

I presume that there is some setting in Postfix that governs this
behaviour and I would like to discover what that is, if indeed one
exists.

I discovered:

smtp_dns_resolver_options (default: empty)

and these

smtp_dns_support_level = dnssec
smtp_host_lookup = dns

But none of these seem to control the appending of our local search
domains to incoming smtp traffic from external network addresses.  I
am perplexed as to why this behaviour occurs at all for that
circumstance.


postconf -n

alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 30m
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks.regexp
home_mailbox = Maildir/
html_directory = no
ignore_mx_lookup_error = no
inet_interfaces = localhost, inet08.hamilton.harte-lyne.ca
inet_protocols = all
local_transport = smtp
mail_spool_directory = /var/spool/mail
mailman_destination_recipient_limit = 1
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_protocol = 2
mydestination =
mynetworks = 216.185.71.0/26, 209.47.176.0/26, 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
queue_minfree = 4096
rbl_reply_maps = hash:/etc/postfix/rbl_reply
readme_directory = /usr/share/doc/postfix-2.11.1/README_FILES
recipient_delimiter = +
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /usr/share/doc/postfix-2.11.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtp_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_use_tls = yes
smtpd_client_restrictions = permit
smtpd_data_restrictions = permit_mynetworks,
reject_multi_recipient_bounce, reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
pcre:/etc/postfix/helo_checks.pcre, reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname, permit
smtpd_milters = inet:127.0.0.1:8891
smtpd_proxy_timeout = 300s
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
reject_unauth_pipelining, check_policy_service
unix:/var/spool/postfix/postgrey/socket, check_policy_service
unix:private/policyd-spf, permit
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/sender_access, check_sender_mx_access
hash:/etc/postfix/sender_mx_access, check_sender_ns_access
hash:/etc/postfix/sender_ns_access, permit_sasl_authenticated,
reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_starttls_timeout = ${stress?10}${stress:120}s
smtpd_timeout = ${stress?10}${stress:120}s
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/ca.harte-lyne.hamilton.smtp.crt
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/ca.harte-lyne.hamilton.smtp.key
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
soft_bounce = no
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual,
regexp:/etc/postfix/virtual.regexp

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.ha

Re: Is this a result of reject_unknown_sender_domain ?

[James B. Byrne]

Further on this.  Doing the forward and reverse lookups reveals this:

;; QUESTION SECTION:
;133.201.62.95.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
133.201.62.95.in-addr.arpa. 106382 IN   PTR
static-133-201-62-95.ipcom.comunitel.net.

;; AUTHORITY SECTION:
62.95.in-addr.arpa. 106382  IN  NS  ns.ripe.net.

But no A record exists:

;; QUESTION SECTION:
;static-133-201-62-95.ipcom.comunitel.net. IN A

;; AUTHORITY SECTION:
ipcom.comunitel.net.10800   IN  SOA ns1.comunitel.net.
hostmaster.comunitel.net. 2015010200 86400 7200 2592000 172800


It seems to me the return value used by Postfix should be

   static-133-201-62-95.ipcom.comunitel.net.

But instead Postfix appears to use:

   static-133-201-62-95.ipcom.comunitel.net

Where the trailing root (dot) domain returned on the PRT RR is
ignored. I believe that it is this omission that leads to the
appending of the locally specified resolver search paths.  Is this the
intended behaviour?  If so then why?



-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re[2]: local transport: how to automatically create Maildir

[Алексей Доморадов]

>On Thu, 30 Apr 2015 12:12:33 +0300
>Алексей Доморадов < alex_...@mail.ru > wrote:
>
>> But it's very uncomfortable to create maildir for each
>> user manually. Are there any workaround?
>> 
>set "home_mailbox" to "Maildir/", and create "Maildir/{cur,new,tmp}"
>at directory /etc/skel/, so on next adduser/useradd it will be
>automatically create the correct requirement for maildir style inbox.
>
>from main.cf:
>
># DELIVERY TO MAILBOX
>#
># The home_mailbox parameter specifies the optional pathname of a
># mailbox file relative to a user's home directory. The default
># mailbox file is /var/spool/mail/user or /var/mail/user.  Specify
># "Maildir/" for qmail-style delivery (the / is required).
>#
>#home_mailbox = Mailbox
>#home_mailbox = Maildir/
If I correctly understood - path specified in the home_mailbox would be 
relative to a user's home directory. So with home_mailbox = Maildir/ all new 
emails would be stored in the /home/webmaster/Maildir/new. And that is not what 
I want. 

Whitelist specific address in postscreen

[Rod K]

Postscreen is successfully blocking a lot of spam for us.  Our DNSBL 
settings are doing a great job, however I'm having one "false 
positive."  One of our customers does a bit of business with a Chinese 
firm.  Their rep from this firm is using the nefarious 163.com as their 
service provider.  Of course this is being blocked.  I do NOT want to 
allow 163.com as a whole to be whitelisted (I'm getting 100s of 
connections/day from them and AFAIK only this particular address is 
sending legit email.)


Is there anyway to have postscreen allow just the one particular address?

Re: Whitelist specific address in postscreen

[Noel Jones]

On 4/30/2015 8:59 AM, Rod K wrote:
> Postscreen is successfully blocking a lot of spam for us.  Our DNSBL
> settings are doing a great job, however I'm having one "false
> positive."  One of our customers does a bit of business with a
> Chinese firm.  Their rep from this firm is using the nefarious
> 163.com as their service provider.  Of course this is being
> blocked.  I do NOT want to allow 163.com as a whole to be
> whitelisted (I'm getting 100s of connections/day from them and AFAIK
> only this particular address is sending legit email.)
> 
> Is there anyway to have postscreen allow just the one particular
> address?


postscreen knows the client IP address, nothing else.  If the
customer uses a particular IP address, you can whitelist it in
postscreen_access_list.
http://www.postfix.org/postconf.5.html#postscreen_access_list

The alternative is to move the offending setting from postscreen to
smtpd_sender_restrictions where you can whitelist by sender or
client name.


  -- Noel Jones

Re: Whitelist specific address in postscreen

[Rod K]

On 4/30/2015 10:15 AM, Noel Jones wrote:

On 4/30/2015 8:59 AM, Rod K wrote:

Postscreen is successfully blocking a lot of spam for us.  Our DNSBL
settings are doing a great job, however I'm having one "false
positive."  One of our customers does a bit of business with a
Chinese firm.  Their rep from this firm is using the nefarious
163.com as their service provider.  Of course this is being
blocked.  I do NOT want to allow 163.com as a whole to be
whitelisted (I'm getting 100s of connections/day from them and AFAIK
only this particular address is sending legit email.)

Is there anyway to have postscreen allow just the one particular
address?


postscreen knows the client IP address, nothing else.  If the
customer uses a particular IP address, you can whitelist it in
postscreen_access_list.
http://www.postfix.org/postconf.5.html#postscreen_access_list

The alternative is to move the offending setting from postscreen to
smtpd_sender_restrictions where you can whitelist by sender or
client name.


   -- Noel Jones
That is what I thought. However, postscreen DOES have that information 
eventually as it logs the reject with sender and recipient.

Re: Whitelist specific address in postscreen

[Noel Jones]

On 4/30/2015 9:27 AM, Rod K wrote:
> On 4/30/2015 10:15 AM, Noel Jones wrote:
>> On 4/30/2015 8:59 AM, Rod K wrote:
>>> Postscreen is successfully blocking a lot of spam for us.  Our DNSBL
>>> settings are doing a great job, however I'm having one "false
>>> positive."  One of our customers does a bit of business with a
>>> Chinese firm.  Their rep from this firm is using the nefarious
>>> 163.com as their service provider.  Of course this is being
>>> blocked.  I do NOT want to allow 163.com as a whole to be
>>> whitelisted (I'm getting 100s of connections/day from them and AFAIK
>>> only this particular address is sending legit email.)
>>>
>>> Is there anyway to have postscreen allow just the one particular
>>> address?
>>
>> postscreen knows the client IP address, nothing else.  If the
>> customer uses a particular IP address, you can whitelist it in
>> postscreen_access_list.
>> http://www.postfix.org/postconf.5.html#postscreen_access_list
>>
>> The alternative is to move the offending setting from postscreen to
>> smtpd_sender_restrictions where you can whitelist by sender or
>> client name.
>>
>>
>>-- Noel Jones
> That is what I thought. However, postscreen DOES have that
> information eventually as it logs the reject with sender and recipient.

At the time the reject decision is made, only the IP is known.

The collection of sender and recipient information is done by a stub
smtp agent much later, as a logging convenience.

This is intentional due to performance considerations and is
unlikely to ever be changed.


  -- Noel Jones

Re: tls_policy

[Viktor Dukhovni]

On Thu, Apr 30, 2015 at 10:29:29AM +0300, Birta Levente wrote:

> On 30/04/2015 10:17, Viktor Dukhovni wrote:
> >On Thu, Apr 30, 2015 at 10:09:36AM +0300, Birta Levente wrote:
> >
> >>OK, I found the problem:
> >>I had configured the smtp_tls_CAfile. Removing everything works fine.
> >Was the file malformed?  I have a hard time imagining any non-empty
> >set of well-formed certs in that file causing the problem you
> >describe.  Did the file contain any PEM X.509 certificates?
> >
> >Does:
> >
> > $ cafile=
> > $ openssl crl2pkcs7 -nocrl -certfile "$cafile" |
> > openssl pkcs7 -print_certs -noout |
> > grep -c '^issuer='
> >
> >report any errors to stderr?  How many issuers were reported by
> >grep?
> >
> 
> No error and only 1 issuer, which was the cacert.org root certificate

Can you reproduce the problem by using "-CAfile $cafile" with
s_client(1)?  I don't see how adding a trusted CA can break the
handshake if the CA is well formed.

Please provide more information.  Please attach a gzipped copy of
the CAfile after making sure putting it back restores the problem.

-- 
Viktor.

Re: local transport: how to automatically create Maildir

[Koko Wijatmoko]

On Thu, 30 Apr 2015 16:53:30 +0300
Алексей Доморадов  wrote:

> If I correctly understood - path specified in the
> home_mailbox would be relative to a user's home
> directory. So with home_mailbox = Maildir/ all new
> emails would be stored in the /home/webmaster/Maildir/
> new. And that is not what I want.

you need a script for that purpose. from adduser manpage:

---start---
If the file /usr/local/sbin/adduser.local exists, it will be executed
after the user account has been set up in order to do any local setup.
The arguments passed to adduser.local are:
username uid gid home-directory
---end---

Re[2]: local transport: how to automatically create Maildir

[Алексей Доморадов]

Четверг, 30 апреля 2015, 21:53 +07:00 от Koko Wijatmoko :
>On Thu, 30 Apr 2015 16:53:30 +0300
>Алексей Доморадов < alex_...@mail.ru > wrote:
>
>> If I correctly understood - path specified in the
>> home_mailbox would be relative to a user's home
>> directory. So with home_mailbox = Maildir/ all new
>> emails would be stored in the /home/webmaster/Maildir/
>> new. And that is not what I want.
>
>you need a script for that purpose. from adduser manpage:
>
>---start---
>If the file /usr/local/sbin/adduser.local exists, it will be executed
>after the user account has been set up in order to do any local setup.
>The arguments passed to adduser.local are:
>username uid gid home-directory
>---end---
Are we reading the same man page? :) I don't see any notes about adduser.local 
in man useradd on CentOS 6

Re: Is this a result of reject_unknown_sender_domain ?

[Viktor Dukhovni]

On Thu, Apr 30, 2015 at 09:26:11AM -0400, James B. Byrne wrote:

> > The fact that the same name fails HELO checks (which don't use the
> > default suffixes) is not unexpected.
> >
> 
> Actually, my suspicion was that this was a case of cause and effect. 

Your instinct is wrong, and further effort in this direction is
unwarranted.

The Postfix SMTP server smtpd(8), uses getnameinfo() and getaddrinfo()
to resolve the incoming client network address to a hostname and
to chech the validity that hostname.  This code does not tweak the
DNS resolver options and is subject to the default DNS search list
from /etc/resolv.conf.

Separately, various restrictions like "reject_unknown_helo_hostname"
and "reject_unknown_sender_domain", ... use explicit DNS lookups
that do disable the search list.

Nothing to see here, the DNS queries are not unexpected.

-- 
Viktor.

Re: local transport: how to automatically create Maildir

[Koko Wijatmoko]

On Thu, 30 Apr 2015 18:14:08 +0300
Алексей Доморадов  wrote:

> Are we reading the same man page? :) I don't see any
> notes about adduser.local in man useradd on CentOS 6

do your home work first, try it... if not work then upgrade your
adduser package rpm from centos 7 or latest tarball.

i'm closed this thread, not postfix issue.

Re: Is this a result of reject_unknown_sender_domain ?

[James B. Byrne]

On Thu, April 30, 2015 11:14, Viktor Dukhovni wrote:

>
> Separately, various restrictions like "reject_unknown_helo_hostname"
> and "reject_unknown_sender_domain", ... use explicit DNS lookups
> that do disable the search list.
>
> Nothing to see here, the DNS queries are not unexpected.
>

I follow that.  My point is that in the circumstance that a host
identifies itself solely with an IP address then the only manner in
which Postfix can obtain the associated domain name is via the PTR RR.
Since that must be, by definition, a FQDN then why is the search path
in the local resolver involved at all?

The issue to me seems to be the trailing dot on the FQDN returned from
the PRT RR which then is seemingly ignored.  If the dot was retained
then the resolver, presumably, would know not to append the local
search paths, and thereby eliminate a number of pointless DNS queries
and useless log entries.


-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Is this a result of reject_unknown_sender_domain ?

[Viktor Dukhovni]

On Thu, Apr 30, 2015 at 11:23:18AM -0400, James B. Byrne wrote:

> > Separately, various restrictions like "reject_unknown_helo_hostname"
> > and "reject_unknown_sender_domain", ... use explicit DNS lookups
> > that do disable the search list.
> >
> > Nothing to see here, the DNS queries are not unexpected.
> 
> I follow that.  My point is that in the circumstance that a host
> identifies itself solely with an IP address then the only manner in
> which Postfix can obtain the associated domain name is via the PTR RR.

In your original problem report the *HELO* name was rejected.

> Since that must be, by definition, a FQDN then why is the search path
> in the local resolver involved at all?

It is NOT by definition an FQDN, because in smtpd(8) the IP->name
mapping is via getnameinfo(), not DNS PTR lookups.

> The issue to me seems to be the trailing dot on the FQDN returned from
> the PRT RR which then is seemingly ignored.

There is no "trailing dot".  Postfix gets a name from getnameinfo()
which it passes for forward checking to getaddrinfo().  Whether
the C-library is doing any DNS under the covers is up to the C-
library.  The name returned by getnameinfo() could have come from
/etc/hosts, NIS, LDAP, ...

-- 
Viktor.

Re[2]: local transport: how to automatically create Maildir

[Алексей Доморадов]

>On Thu, 30 Apr 2015 18:14:08 +0300
>Алексей Доморадов < alex_...@mail.ru > wrote:
>
>> Are we reading the same man page? :) I don't see any
>> notes about adduser.local in man useradd on CentOS 6
>
>do your home work first, try it... if not work then upgrade your
>adduser package rpm from centos 7 or latest tarball.
>
>i'm closed this thread, not postfix issue.
> do your home work first, try it...
as I told before I need separate home dir and mail spool dir, for e.g.

home - /home/webmaster
mail spool - /var/spool/mail/webmaster/


> if not work then upgrade your adduser package rpm from centos 7 or latest 
> tarball.
OMG, thanks but that's not a solution at all

Re: Is this a result of reject_unknown_sender_domain ?

[James B. Byrne]

On Thu, April 30, 2015 11:28, Viktor Dukhovni wrote:

>
> There is no "trailing dot".  Postfix gets a name from getnameinfo()
> which it passes for forward checking to getaddrinfo().  Whether
> the C-library is doing any DNS under the covers is up to the C-
> library.  The name returned by getnameinfo() could have come from
> /etc/hosts, NIS, LDAP, ...
>

Thank you.  I now understand, somewhat. I think.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: local transport: how to automatically create Maildir

[Michael Tokarev]

30.04.2015 14:21, Koko Wijatmoko wrote:
> On Thu, 30 Apr 2015 12:12:33 +0300
> Алексей Доморадов  wrote:
> 
>> But it's very uncomfortable to create maildir for each
>> user manually. Are there any workaround?

Postfix do create missing Maildirs by default,
there's no need to do extra work in this context.

But it does that with permissions of the user.
So if the user does not have permissions to create
his own maildir, postfix will not try to do that.
One "possible" solution is to add all users to the
same group and let this group to write the common
spool directory.  This is bad because this way your
users will be able to create any file in there with
any name.

This is why adduser/useradd etc all have option to
create user's home directory, once when you create
a user, and run this command as root.  Later on,
postfix is able to create missing maildir in there,
with the permissions of that user.

So the solution is might be to move maildir to the
home directory, or, as Koko Wijatmoko suggested,
to run a script when you create a user, a script
which will create user's maildir in an alternative
location.

Or run whole email system as a separate user, such
as "vmail", who owns all mailboxes, and who obviously
can create maildirs in its own spool.

Thanks,

/mjt

postfix stats

[Terry Barnum]

I've been using pflogsumm but it's old and doesn't know about postscreen. I'd 
like to see how many connections are being refused by postscreen. What do you 
like? logwatch? awstats? other?

Thanks,
-Terry

Terry Barnum
digital OutPost
http://www.dop.com

Re: postfix stats

[Michael Orlitzky]

On 04/30/2015 08:24 PM, Terry Barnum wrote:
> I've been using pflogsumm but it's old and doesn't know about
> postscreen. I'd like to see how many connections are being refused by
> postscreen. What do you like? logwatch? awstats? other?
> 

http://logreporters.sourceforge.net/

I believe logwatch now includes recent copies of these two, but I like
to run them standalone anyway.

Re: Cannot Start TLS: handshake failure

[Tom Johnson]

On Apr 230, 2015, at 2:41:53 PM, Viktor Dukhovni wrote:


> > And I've tried this, thinking that it could be an issue with the selected 
> > ciphers, \
> > but it makes no difference:  
> > smtp_tls_exclude_ciphers = 3DES DES 
> 
> The symptom with broken 3DES with Microsoft systems is not a
> handshake failure.

Ok - I wasn't sure.  Thanks.


> 
> > 2015-04-29T22:36:51+ server.domain.com postfix-gw/smtp[29844]: setting 
> > up TLS \
> > connection to mail.mlmatthews.com[23.25.38.217]:25  
> > 2015-04-29T22:36:51+ \
> > server.domain.com postfix-gw/smtp[29844]: 
> > mail.mlmatthews.com[23.25.38.217]:25: TLS \
> > cipher list "aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!3DES:!DES" 
> >  \
> > 2015-04-29T22:36:51+ server.domain.com postfix-gw/smtp[29844]: \
> > SSL_connect:before/connect initialization  2015-04-29T22:36:51+ \
> > server.domain.com postfix-gw/smtp[29844]: SSL_connect:SSLv2/v3 write client 
> > hello A \
> >  2015-04-29T22:36:51+ server.domain.com postfix-gw/smtp[29844]: 
> > SSL_connect \
> > error to mail.mlmatthews.com[23.25.38.217]:25: lost connection  \
> > 2015-04-29T22:36:51+ server.domain.com postfix-gw/smtp[29844]: 
> > 3lcZT61sm7z5wjJ: \
> > to=, relay=mail.mlmatthews.com[23.25.38.217]:25, 
> > delay=8.8, \
> > delays=8.5/0.26/0.05/0, dsn=4.7.5, status=undeliverable-but-not-cached 
> > (Cannot \
> > start TLS: handshake failure)  
> 
> That aside, even with the "wrong" MX host, I still get successful
> connections.  Perhaps you're behind some sort of firewall that
> proxies TLS and disconnects when it does not like the peer certificate:
> 
> $ posttls-finger -c -Ldebug "[mail.mlmatthews.com]"
> posttls-finger: initializing the client-side TLS engine
> posttls-finger: setting up TLS connection to 
> mail.mlmatthews.com[23.25.38.217]:25
> ...
> posttls-finger: SSL_connect:SSLv2/v3 write client hello A
> posttls-finger: SSL_connect:SSLv3 read server hello A
> ...
> posttls-finger: SSL_connect:SSLv3 read server certificate A
> posttls-finger: SSL_connect:SSLv3 read server done A
> posttls-finger: SSL_connect:SSLv3 write client key exchange A
> posttls-finger: SSL_connect:SSLv3 write change cipher spec A
> posttls-finger: SSL_connect:SSLv3 write finished A
> posttls-finger: SSL_connect:SSLv3 flush data
> posttls-finger: SSL_connect:SSLv3 read finished A
> posttls-finger: server certificate verification failed for \
> mail.mlmatthews.com[23.25.38.217]:25: certificate has expired  
> posttls-finger: \
> mail.mlmatthews.com[23.25.38.217]:25: subject_CN=mail.mlmatthews.com, 
> issuer_CN=Go \
> Daddy Secure Certification Authority, \
> fingerprint=84:E0:0C:BD:01:55:DF:38:7C:7E:CF:22:DC:AC:97:6A:3B:91:87:7B, \
> pkey_fingerprint=D5:EE:32:D4:FF:7D:70:58:43:06:89:5A:85:8B:79:5B:6C:B4:3B:B4  
> \
> posttls-finger: Untrusted TLS connection established to \
> mail.mlmatthews.com[23.25.38.217]:25: TLSv1 with cipher RC4-MD5 (128/128 bits)
> 

Yes, that's what's strange.  I get the same result with posttls-finger.   

I've also tried this, which works fine:

# openssl s_client -starttls smtp -connect mail.mlmatthews.com:25
CONNECTED(0003)
depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert 
Class 2 Policy Validation Authority, CN = http://www.valicert.com/, 
emailAddress = i...@valicert.com
verify return:1
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 
Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = 
http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification 
Authority, serialNumber = 07969287
verify return:1
depth=0 OU = Domain Control Validated, CN = mail.mlmatthews.com
verify error:num=10:certificate has expired
notAfter=Sep 25 19:32:03 2014 GMT
verify return:1
depth=0 OU = Domain Control Validated, CN = mail.mlmatthews.com
notAfter=Sep 25 19:32:03 2014 GMT
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=mail.mlmatthews.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, 
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure 
Certification Authority/serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, 
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure 
Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification 
Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification 
Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy 
Validation Authority/CN=http://www.valicert.com//emailAddress=i...@valicert.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIFWTCCBEGgAwIBAgIHK1wrGFsncjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3Jlc

Re: Cannot Start TLS: handshake failure

[Viktor Dukhovni]

On Thu, Apr 30, 2015 at 08:28:21PM -0700, Tom Johnson wrote:

> > That aside, even with the "wrong" MX host, I still get successful
> > connections.  Perhaps you're behind some sort of firewall that
> > proxies TLS and disconnects when it does not like the peer certificate:
> > 
> > $ posttls-finger -c -Ldebug "[mail.mlmatthews.com]"
> > posttls-finger: Untrusted TLS connection established to \
> > mail.mlmatthews.com[23.25.38.217]:25: TLSv1 with cipher RC4-MD5 (128/128 
> > bits)

Notice I that with posttls-finger I'm connecting with "RC4-MD5",
when I disable RC4, I get connection problems.

> Yes, that's what's strange.  I get the same result with posttls-finger.   

Same, as in success with RC4?  Have you disabled RC4?  Or otherwise
changed the cipher-suite or procotol controls?  Post the output of:

$ postconf -n | grep '^smtp_tls'

> I've also tried this, which works fine:
> 
> # openssl s_client -starttls smtp -connect mail.mlmatthews.com:25
> Cipher: RC4-SHA

RC4-SHA this time.

> But postfix consistently gets those errors:

Postfix offers more ciphers when the security level is "may".  When
I explicitly set the "posttls-finger" security level to "may".  I
see your symptoms:

$ posttls-finger -c -lmay -o 'tls_medium_cipherlist=ALL:+RC4:@STRENGTH' 
-Ldebug "[mail.mlmatthews.com]"
posttls-finger: initializing the client-side TLS engine
posttls-finger: setting up TLS connection to 
mail.mlmatthews.com[23.25.38.217]:25
posttls-finger: mail.mlmatthews.com[23.25.38.217]:25: TLS cipher list 
"ALL:+RC4:@STRENGTH:!eNULL"
posttls-finger: SSL_connect:before/connect initialization
posttls-finger: SSL_connect:SSLv2/v3 write client hello A
posttls-finger: SSL_connect error to mail.mlmatthews.com[23.25.38.217]:25: 
lost connection

This is indeed an Exchange 2003 server which only supports RC4 and
a broken 3DES, but you must have a sufficiently recent OpenSSL
version where even 3DES (re-rated at 112-bit) is not in the first
64 cipherlist elements, and so the handshake fails early.

For this server, you need a more "compact" cipherlist as a work-around.

smtp_tls_exclude_ciphers = 
#
# Disable MD5, DSA, SRP and PSK, and the "exotic" fixed DH 
cipher suites.
#
MD5, SRP, PSK, aDSS, kECDH, kDH,
#
# Disable 256-bit ciphers, 128-bit is for now quite strong 
enough.
# Also disable the largely unused SEED, IDEA, RC2, RC5, ...
# leaving just AES128, CAMELLIA128, RC4 and 3DES.
#
AES256, CAMELLIA256, SEED, IDEA, RC2, RC5

This is does not noticeably impact the security of connections to
other sites, but enables communication with Exchange 2003 servers
(it is rather sad that folks are still using these), without having
to configure a separate policy for each such site.

-- 
Viktor.