Re: SASL question

2013-02-11 Thread Reindl Harald 


Am 11.02.2013 04:53, schrieb Simon Walter:
> On 02/11/2013 05:46 AM, Reindl Harald wrote:
>>
>> what are you using for IMAP?
>> if dovecot throw away the whole SASL crap!
>>
> Don't you mean "...the whole *Cyrus* SASL crap"? Isn't "smtpd_sasl_type = 
> dovecot" using the dovecot implementation
> of SASL?

ok, i word it "the whole manually configured SASL crap"

usually you need authentication for SMTP/POP3/IMAP and so
preferred is a single instance and the same aut-mechs on
all services



signature.asc
Description: OpenPGP digital signature

Split users outbound traffic to a different IP address.

2013-02-11 Thread Brice Figureau 
Hi,

Due to our traffic increasing, I'd like to split our corporate e-mail
traffic from our transactional traffic (mostly account creations
confimation and order confirmation e-mails) to different outbound smtp
IP address.

The way we can identify corporate users is either by distinct IP address
or SASL authenticated users (and by sender e-mail).

Considering I'm running postfix 2.7 what would be the best way to
achieve this?

I'm using postfix for a really long time now, but quite dropped
following the development and new features, so I might have missed a lot
of new stuff.

I've looked to the sender_dependent_default_transport_maps configuration
directive, but it requires to list all the senders (which is doable
automatically from our ldap system, but requires an external cron). This
would be combined with a different smtp transport bound to a different
IP address.

So, the only way apparently to do exactly what I want is to have second
postfix instance, to which authenticated users e-mail would be relayed
(could be done with an amavis policy banks). This second instance would
bind to a different IP address.

Is there any other options, I might have not find by myself?
Thanks!
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Fabio Sangiovanni 
Noel Jones  megan.vbhcs.org> writes:

> Seems like the easiest solution is to put permit_sasl_authenticated
> BEFORE reject_rbl_client.  Then no whitelisting is needed.
> 
>   -- Noel Jones
 
Hi, thanks for your answer.
Yes, that would be useful, except for malware that steals your credentials,
and that would be otherwise (hopefully) blocked against lists such as
Spamhaus XBL. Is it correct?
I prefer Victor's solution for this reason...

Thanks again,
Fabio

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Noel Jones 
On 2/11/2013 4:00 AM, Fabio Sangiovanni wrote:
> Noel Jones  megan.vbhcs.org> writes:
> 
>> Seems like the easiest solution is to put permit_sasl_authenticated
>> BEFORE reject_rbl_client.  Then no whitelisting is needed.
>>
>>   -- Noel Jones
>  
> Hi, thanks for your answer.
> Yes, that would be useful, except for malware that steals your credentials,
> and that would be otherwise (hopefully) blocked against lists such as
> Spamhaus XBL. Is it correct?
> I prefer Victor's solution for this reason...
> 
> Thanks again,
> Fabio
> 

Your method of manually whitelisting any IP that happens to be
spamhaus listed doesn't scale very well. Every time some authorized
user travels somewhere, stops at a wifi hotspot, or their home IP
changes, will need to call you to get whitelisted before they can
send mail.  This might be OK if you have only a handful of users and
neither you nor they mind a phone call every time they can't send mail.

A more typical solution is to allow authorized users to send mail
from wherever they happen to be, and use rate limits on postfix via
postfwd or similar to alert you to a possibly compromised account.



  -- Noel Jones

openssl updated on FreeBSD

2013-02-11 Thread Jerry 
Just a heads up for any FreeBSD users who were bitten by the resent
openssl bug. The FreeBSD ports version has been updated to
openssl-1.0.1_7 (/usr/ports/security/openssl/) and works fine now with
Postfix. I just installed and tested it. There is no need to rebuild
Postfix either.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Fabio Sangiovanni 
Noel Jones  megan.vbhcs.org> writes:

> Your method of manually whitelisting any IP that happens to be
> spamhaus listed doesn't scale very well. Every time some authorized
> user travels somewhere, stops at a wifi hotspot, or their home IP
> changes, will need to call you to get whitelisted before they can
> send mail.  This might be OK if you have only a handful of users and
> neither you nor they mind a phone call every time they can't send mail.
> 
> A more typical solution is to allow authorized users to send mail
> from wherever they happen to be, and use rate limits on postfix via
> postfwd or similar to alert you to a possibly compromised account.
> 
>   -- Noel Jones
> 
> 


Hi, thanks again for your advice. My use case is slightly different from the one
you describe (ip change is not that frequent), so my restrictions
should fit well. I'll be prepared to switch to your paradigm as the situation
changes. 

Bye,
Fabio

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Fabio Sangiovanni 
Viktor Dukhovni  dukhovni.org> writes:

> Replace "OK" with:
> 
>   /etc/postfix/whitelist_client.cidr:
>   192.0.2.1/32permit_sasl_authenticated
> 

Sorry Viktor,

I have another question: what happens if a client is whitelisted AND it fails
SASL authentication?
I suppose that the following directives are evaluated, aren't they?
So, in such cases, there is a query to the rbl, another (failed) check for
SASL authentication (if the IP is not listed), and the final reject due to
reject_unauth_destination.

So, is it correct to create the file /etc/postfix/whitelist_client.cidr with
entries like:
192.0.2.1/32permit_sasl_authenticated,reject

The additional reject should prevent further evaluation of restrictions outside
(and following) the access table.

Thanks again for your help.

Fabio

Postscreen RBLs

2013-02-11 Thread Nikolaos Milas 

Hello,

I am using Postfix 2.9.4 on CentOS 6.3 as a gateway server with the 
following postscreen settings:


postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites =
b.barracudacentral.org*2,
zen.spamhaus.org*2,
psbl.surriel.com*2
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce

Sometimes I receive complaints from some mail server operators that 
barracudacentral causes blocks of mail from their server, and "Very few 
email providers use Barracuda for their RBL's, so it is not an RBL we 
check very often or rely on".


I remember that, when I had set up this gateway server, I had researched 
and found that barracudacentral should be OK.


My questions now are:

 * Based on your experience and advice, should I keep the above
   postscreen settings? Any suggestions?
 * Should I avoid postscreen_dnsbl_sites and only use amavis to make
   decisions through scoring?  How are you implementing such blocks?

Thanks in advance,
Nick

Re: Postscreen RBLs

2013-02-11 Thread Reindl Harald 


Am 11.02.2013 17:13, schrieb Nikolaos Milas:
> Sometimes I receive complaints from some mail server operators that 
> barracudacentral causes blocks of mail from
> their server, and "Very few email providers use Barracuda for their RBL's, so 
> it is not an RBL we check very often
> or rely on"

explain them that 
https://www.barracudanetworks.com/products/spamandvirusfirewall
is using it fore sure and there are enough big companies using appliances
from barracuda networks



signature.asc
Description: OpenPGP digital signature

Re: Postscreen RBLs

2013-02-11 Thread Rod K 


On 2/11/2013 11:13 AM, Nikolaos Milas wrote:

Hello,

I am using Postfix 2.9.4 on CentOS 6.3 as a gateway server with the 
following postscreen settings:


postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites =
b.barracudacentral.org*2,
zen.spamhaus.org*2,
psbl.surriel.com*2
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce

Sometimes I receive complaints from some mail server operators that 
barracudacentral causes blocks of mail from their server, and "Very 
few email providers use Barracuda for their RBL's, so it is not an RBL 
we check very often or rely on".


I remember that, when I had set up this gateway server, I had 
researched and found that barracudacentral should be OK.


My questions now are:

* Based on your experience and advice, should I keep the above
postscreen settings? Any suggestions?
* Should I avoid postscreen_dnsbl_sites and only use amavis to make
decisions through scoring? How are you implementing such blocks?

Thanks in advance,
Nick



Barracuda and Spamhaus are the only RBLs that I use that can block by 
themselves. All others require at least one corroborating RBL. I've not 
run into any issues. I'd suggest that if their response is what you 
quoted they need to be more concerned about why they are being listed 
than telling others not to use them. Of course, that tells me they 
probably already know why they are listed and choose not to correct the 
behavior that caused the listing.

Re: Postscreen RBLs

2013-02-11 Thread Noel Jones 
On 2/11/2013 10:13 AM, Nikolaos Milas wrote:
> Hello,
> 
> I am using Postfix 2.9.4 on CentOS 6.3 as a gateway server with the
> following postscreen settings:
> 
> postscreen_dnsbl_threshold = 2
> postscreen_dnsbl_sites =
> b.barracudacentral.org*2,
> zen.spamhaus.org*2,
> psbl.surriel.com*2
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> 
> Sometimes I receive complaints from some mail server operators that
> barracudacentral causes blocks of mail from their server, and "Very
> few email providers use Barracuda for their RBL's, so it is not an
> RBL we check very often or rely on".
> 
> I remember that, when I had set up this gateway server, I had
> researched and found that barracudacentral should be OK.
> 
> My questions now are:
> 
>  * Based on your experience and advice, should I keep the above
>postscreen settings? Any suggestions?

There is no one-size-fits-all, so do what fits at your site.  What
some folks do is weigh barracuda*1 and a few other dnsbl's such as
bl.spamcop.net, bl.spameatingmonkey.net, fresh.spameatingmonkey.net,
hostkarma.junkemailfilter.com=127.0.0.2, or ix.dnsbl.manitu.net, all
scored at one.  That way multiple less-trusted dnsbl's must list a
site to reject their mail.

Opinions on which dnsbls are safe to block on their own vary
greatly.  Adjust the postscreen scores as you see fit.



>  * Should I avoid postscreen_dnsbl_sites and only use amavis to make
>decisions through scoring?  How are you implementing such blocks?

Use the scoring built into postscreen.  You may occasionally need to
use the whitelisting built into postscreen, too.


> 
> Thanks in advance,
> Nick




  -- Noel Jones

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Viktor Dukhovni 
On Mon, Feb 11, 2013 at 03:19:52PM +, Fabio Sangiovanni wrote:

> I have another question: what happens if a client is whitelisted AND it fails
> SASL authentication?

The whitelist only applies to authenticated users. Unauthenticated users
are treated like everyone else.

> I suppose that the following directives are evaluated, aren't they?
> So, in such cases, there is a query to the rbl, another (failed) check for
> SASL authentication (if the IP is not listed), and the final reject due to
> reject_unauth_destination.
> 
> So, is it correct to create the file /etc/postfix/whitelist_client.cidr with
> entries like:
> 192.0.2.1/32permit_sasl_authenticated,reject
> 
> The additional reject should prevent further evaluation of restrictions 
> outside
> (and following) the access table.

You're working too hard, the suggested settings should work just fine.

-- 
Viktor.

Re: HOLDing certain recipients during migration

2013-02-11 Thread Reindl Harald 


Am 11.02.2013 19:56, schrieb Miha Valencic:
> Hi!
> 
> Just want to double check if I am planning this correctly. We're migrating 
> users from one system to another, and
> want to HOLD incoming messages for certain recipients during migration. For 
> that purpose, we'll create a file with
> users listed:
> 
> /hold-users:
> us...@domain.com  HOLD
> us...@domain.com  HOLD

i would not do this and simply shutdown mail-services at night due
migration, the sender will try later and you do not lost messages

if the migration is done smart like imapsync before shutdown
and after that with the correct params again to sync changes
the downtime is minimal






signature.asc
Description: OpenPGP digital signature

Problem with line which is longer than 256 characters

2013-02-11 Thread Rolf E. Sonneveld 

Hi,

running:

Postfix 2.9.5

Output of uname -a:
SunOS hostname 5.10 Generic_147440-27 sun4v sparc sun4v

Running multiple instances in a multi-instance setup: the instance that 
is used and for which an SMTP client has problems is named postfix-app.


Output of postconf -n :

# /opt/postfix/sbin/postmulti -i postfix-app -x postconf -n
2bounce_notice_recipient = suppd...@example.nl
alias_maps = dbm:/opt/postfix-app/etc/aliases
append_dot_mydomain = no
authorized_submit_users =
bounce_notice_recipient = suppd...@example.nl
bounce_queue_lifetime = 3d
command_directory = /opt/postfix/sbin
config_directory = /opt/postfix-app/etc
daemon_directory = /opt/postfix/libexec
data_directory = /opt/postfix-app/lib
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5

default_transport = smtp
disable_vrfy_command = yes
error_notice_recipient = suppd...@example.nl
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /opt/postfix/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 4d
multi_instance_enable = yes
multi_instance_group = mta
multi_instance_name = postfix-app
mydestination = $myhostname
mydomain = app.example.nl
myhostname = mta12.app.example.nl
mynetworks = cidr:/opt/postfix-app/etc/mynetworks
myorigin = $myhostname
newaliases_path = /opt/postfix/bin/newaliases
notify_classes = resource, software, bounce
queue_directory = /opt/postfix-app/spool
readme_directory = /opt/postfix/readme
sample_directory = /opt/postfix/etc
sendmail_path = /opt/postfix/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = check_client_access 
dbm:/opt/postfix-app/etc/access

smtpd_delay_reject = no
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks,reject
syslog_facility = mail
syslog_name = postfix-app
transport_maps = dbm:/opt/postfix-app/etc/transport

In general, Postfix is running fine and this Postfix instance is also 
running fine. However, there is one SMTP client (of which we are not in 
control), that sends messages with long lines to this server running 
Postfix. There is a problem with the communication between this client 
and the server: whenever the clients sends a message which includes one 
long line (377 characters, excluding the CRLF), the client seems to 
'hang' after character # 256 of this long line is transmitted. Then, 
after some time the connection times out.


The part of the SMTP DATA that is causing problems is typically 
something like:


...
--=_Part_5045_26475068.1360013318406
Content-Type: application/smil; name=smil.xml; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: 
Content-Location: smil.xml

id="Image" left="0" top="0" width="240" height="220" fit="meet"/>id="Text" left="0" top="220" width="240" height="100" 
fit="meet"/>src="cid:_external_images_media_623478$IMAG0503.jpg" 
region="Image"/>

--=_Part_5045_26475068.1360013318406
...

On the client side the communication looks like:

...
...
--=_Part_5045_26475068.1360013318406
Content-Type: application/smil; name=smil.xml; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: 
Content-Location: smil.xml

id="Image" left="0" top="0" width="240" height="220" fit="meet"/>id="Text" left="0" top="220" width="240" height="100" 
fit="meet"/>
Connection to hostname closed by foreign host.

And the logfile on the (Postfix) SMTP server side shows:

Feb 11 22:19:16 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
> smtp. client[10.10.16.132]: 250 2.1.5 Ok
Feb 11 22:19:24 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
< smtp. client[10.10.16.132]: DATA
Feb 11 22:19:24 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
> smtp. client[10.10.16.132]: 354 End data with .
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
smtp_get: timeout
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
> smtp. client[10.10.16.132]: 421 4.4.2 mta12.app.example.nl Error: 
timeout exceeded
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
match_hostname: smtp. client ~? 
cidr:/opt/postfix-app/etc/mynetworks(0,lock|fold_fix)
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
dict_cidr_lookup: /opt/postfix-app/etc/mynetworks: smtp. client
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
match_hostaddr: 10.10.16.132 ~? 
cidr:/opt/postfix-app/etc/mynetworks(0,lock|fold_fix)
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
dict_cidr_lookup: /opt/postfix-app/etc/mynetworks: 10.10.16.132
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
timeout after DATA (1881 bytes) from smtp. client[10.10.16.132]
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
disconnect from smtp. client[10.10.16.132]
Feb 11 22:25:11 hostname postfix-app/smtpd[22726]: [ID 197553 mail.info] 
master_not

Re: Exceptions to reject_rbl_client *AND* SASL authentication enforcement

2013-02-11 Thread Fabii Sangiovanni 
Viktor Dukhovni  dukhovni.org> writes:

> You're working too hard, the suggested settings should work just fine.

Would you be so kind to point me to some readings on the matter? The only 
relevant piece of documentation seems to be RESTRICTION_CLASS_README, but, even 
after reading that, it's not clear to me *why* those settings should work 
equally (that is, with or without the final reject), nor what is the default in 
a sequnce of restrictions within an access table...
I don't want to just set the right configuration once for all, I'm interested 
in 
developing a deeper knowledge on the topic. :) 

As usual, thanks for your time. 

Fabio

Re: Problem with line which is longer than 256 characters

2013-02-11 Thread Wietse Venema 
Rolf E. Sonneveld:
> In general, Postfix is running fine and this Postfix instance is also 
> running fine. However, there is one SMTP client (of which we are not in 
> control), that sends messages with long lines to this server running 
> Postfix. There is a problem with the communication between this client 
> and the server: whenever the clients sends a message which includes one 
> long line (377 characters, excluding the CRLF), the client seems to 
> 'hang' after character # 256 of this long line is transmitted. Then, 
> after some time the connection times out.

A tcpdump recording will reveal if the client stops sending or if
the server stops reading (it's revealed by TCP receive window size).
Once this is known the search can be focused. It could be somethinh
as stupid as poorly-implemented anti-virus software.

http://www.postfix.org/DEBUG_README.html#sniffer

Wietse

TLS Library Problem? Postfix 2.9.6

2013-02-11 Thread weber 


Hi,
on my backup relay server i find these lines in the logs.
i rebuild openssl and postfix.
i am on gentoo linux.

openssl 1.0.1c
postfix 2.9.6

on the final destination postfix server in the logs all is fine.

this only appears on the backup relay server:


Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: SSL_connect error to 
mail.domain.de[176.xxx.xxx.xxx]:25: -1
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS library 
problem: 18823:error:04075070:rsa routines:RSA_sign:digest too big for 
rsa key:rsa_sign.c:127:
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS library 
problem: 18823:error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP 
lib:s3_clnt.c:2983:
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: 8C83420004CB: Cannot 
start TLS: handshake failure
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: Host offered 
STARTTLS: [mail.domain.de]
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: SSL_connect error to 
mail.domain.de[176.xxx.xxx.xxx]:25: -1
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: warning: TLS library 
problem: 18825:error:04075070:rsa routines:RSA_sign:digest too big for 
rsa key:rsa_sign.c:127:
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: warning: TLS library 
problem: 18825:error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP 
lib:s3_clnt.c:2983:
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: E8D6620004CD: Cannot 
start TLS: handshake failure
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: Host offered 
STARTTLS: [mail.domain.de]
Feb 11 22:52:52 fallbackhost postfix/smtp[18825]: E8D6620004CD: 
to=, relay=mail.domain.de[176.xxx.xxx.xxx]:25, 
delay=1.4, delays=0.4/0.01/0.91/0.03, dsn=2.0.0, status=sent (250 2.0.0 
Ok: queued as AD125102441)

Feb 11 22:52:52 fallbackhost postfix/qmgr[14999]: E8D6620004CD: removed


any ideas? what causes these errors?

thanks

marko

Re: TLS Library Problem? Postfix 2.9.6

2013-02-11 Thread Wietse Venema 
we...@zackbummfertig.de:
> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS library 
> problem: 18823:error:04075070:rsa routines:RSA_sign:digest too big for 
> rsa key:rsa_sign.c:127:
> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS library 
> problem: 18823:error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP 
> lib:s3_clnt.c:2983:

The TLS library (i.e. OpenSSL) is not part of Postfix, so this may
be the wrong mailing list.

What does 

$ openssl s_client -starttls smtp -connect servername:25

have to say about this?

Wietse

you may need to increase the main.cf ... destination_concurrency_limit from 20

2013-02-11 Thread Donovan Bray 
I am seeing the following in the postfix logs, and we are having a delivery
problem to blarg.com. However the destination_concurrency_limit reported at
20 took my by surprise. I was under the impression we had already set it
higher.

Feb 11 12:36:08 email postfix/qmgr[23132]: warning: mail for blarg.com is
using up 4001 of 4812 active queue entries
Feb 11 12:36:08 email postfix/qmgr[23132]: warning: this may slow down
other mail deliveries
Feb 11 12:36:08 email postfix/qmgr[23132]: warning: you may need to
increase the main.cf  smtp104_120_110_27_destination_concurrency_limit from
20
Feb 11 12:36:08 email postfix/qmgr[23132]: warning: please avoid flushing
the whole queue when you have
Feb 11 12:36:08 email postfix/qmgr[23132]: warning: lots of deferred mail,
that is bad for performance
Feb 11 12:36:08 email postfix/qmgr[23132]: warning: to turn off these
warnings specify: qmgr_clog_warn_time = 0

We use sender dependent transport maps to allow our applications to send
out the correctly plumbed sending-ip.

from master.cf

smtp  inet  n   -   n   -   -   smtpd
smtp104_120_110_27 unix  - - n - 150 smtp -o
smtp_bind_address=104.120.110.27 -o syslog_name=postfix-app1 -o
smtp_helo_name=mail-27.redacted.com


root@email:/var/log# postconf -n | grep destination_concurrency_limit
smtp_destination_concurrency_limit = 75

root@email:/var/log# postconf -d | grep destination_concurrency_limit
default_destination_concurrency_limit = 20
lmtp_destination_concurrency_limit = $default_destination_concurrency_limit
local_destination_concurrency_limit = 2
relay_destination_concurrency_limit = $default_destination_concurrency_limit
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
virtual_destination_concurrency_limit =
$default_destination_concurrency_limit

If I am understanding the implications correctly the currently set
'smtp_destination_concurrency_limit = 75' ONLY controls the limit for the
smtp line in master.cf; it's not an inherited default for any 'smtp'
service like we had assumed.

If my intention is to increase all of the smtpYYY_YYY_YYY_YYY interfaces
then I need to set 'default_destination_concurrency_limit = 20' higher.
(and 75 is probably way too high)

OR create entries for the specific transports in main.cf like

smtp104_120_110_27_destination_concurrency_limit = 30

I'm assuming that over time we set it higher, and not seeing a negative
effect kept increasing it, but there is almost no mail that goes out the
default smtp interface, so we've been effectively running at a
destination_concurrency_limit of 20 this entire time on all of our custom
interfaces.

I also understand raising the destination_concurrency_limit isn't going to
solve the deliverability problem; it will only correct our understanding
and intent regarding the configuration of our
default_destination_concurrency_limit for this and other interfaces.

Is my resulting understanding correct?

-o syslog_name=XYZ only shows first deferrals with that syslog_name? Retries appear to defer without the custom syslog_name.

2013-02-11 Thread Donovan Bray 
We override the syslog_name in the master.cf so that we can run pflogsumm
on the resulting log files (split out by rsyslog) and we began noticing
discrepancies.

Typical line in master.cf

smtp104_120_110_27 unix  - - n - 150 smtp -o
smtp_bind_address=104.120.110.27 -o syslog_name=postfix-app1 -o
smtp_helo_name=mail-27.redacted.com

We noticed that there were errors in the main mail.log file that referenced
that lines IP address but with a name of 'postfix/error' instead of
'postfix-app1/error', and pflogsumm wasn't reporting those deferrals.

If I grep the mail.log by that lines IP address and redirect it to a file,
then cat the specific log files for postfix-app1 into it, while sed'ing
s/postfix-app1/postfix/g  then running pflogsumm I get all of the deferrals.

Is the only way I can get this done by either running separate postfix
instances for every IP I want to send mail as or doing this post logfile
grep concat and translate?

Re: error using certificate server

2013-02-11 Thread deconya 
Hi

Thanks for you answers

I continue with the problem and I don't know where I can check more. At
now the situation is

-Sends mails deferred

-In logs appears:

Feb 12 01:20:50 mailserver postfix/smtpd[16653]: warning:
smtpd_tls_security_level: unsupported TLS level "verify", using "encrypt"
Feb 12 01:20:50 mailserver postfix/smtpd[16653]: initializing the
server-side TLS engine
Feb 12 01:20:50 mailserver postfix/tlsmgr[16655]: open smtpd TLS cache
btree:/var/lib/postfix/smtpd_scache
Feb 12 01:20:50 mailserver postfix/tlsmgr[16655]:
tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Feb 12 01:20:50 mailserver postfix/smtpd[16653]: connect from
unknown[194.183.97.58]
Feb 12 01:20:51 mailserver postfix/smtpd[16653]: setting up TLS
connection from unknown[194.183.97.58]
Feb 12 01:20:51 mailserver postfix/smtpd[16653]: unknown[194.183.97.58]:
TLS cipher list "ALL:!EXPORT:!LOW:+RC4:@STRENGTH"
Feb 12 01:20:51 mailserver postfix/smtpd[16653]:
SSL_accept:before/accept initialization
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 read
client hello B
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
server hello A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
certificate A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
key exchange A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
server done A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 flush data
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 read
client key exchange A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 read
finished A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:unknown state
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
change cipher spec A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 write
finished A
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: SSL_accept:SSLv3 flush data
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: Anonymous TLS
connection established from unknown[194.183.97.58]: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)
Feb 12 01:20:52 mailserver dovecot: auth(default): client in:
AUTH^I1^IPLAIN^Iservice=smtp^Inologin^Iresp=AG1hcmNvcy5nb256YWxlekBlc2NpLnVwZi5lZHUAYVYzcnlMMG5nUDRzc3cwcmQ=
Feb 12 01:20:52 mailserver postfix/smtpd[16653]: D88A97A0C9C:
client=unknown[194.183.97.58], sasl_method=PLAIN, sasl_username=usertest
Feb 12 01:20:53 mailserver postfix/smtpd[16653]: disconnect from
unknown[194.183.97.58]
Feb 12 01:20:53 mailserver postfix/smtp[16660]: D88A97A0C9C: Server
certificate not verified
Feb 12 01:20:56 mailserver postfix/smtp[16660]: D88A97A0C9C:
to=, relay=mysmarthost[130.206.18.4]:25, delay=3.3,
delays=0.48/0.01/2.8/0, dsn=4.7.5, status=deferred (Server certificate
not verified)

And postconf filtered by smtp is:

default_transport = smtp
lmtp_pix_workarounds = disable_esmtp,delay_dotcrlf
non_smtpd_milters =
parent_domain_matches_subdomains =
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,smtpd_access_maps
proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
$virtual_mailbox_domains $relay_recipient_maps $relay_domains
$canonical_maps $sender_canonical_maps $recipient_canonical_maps
$relocated_maps $transport_maps $mynetworks $sender_bcc_maps
$recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name
relayhost = myrelay
smtp_always_send_ehlo = yes
smtp_bind_address =
smtp_bind_address6 =
smtp_body_checks =
smtp_cname_overrides_servername = no
smtp_connect_timeout = 30s
smtp_connection_cache_destinations =
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 2s
smtp_connection_reuse_time_limit = 300s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_defer_if_no_mx_address_found = no
smtp_destination_concurrency_failed_cohort_limit =
$default_destination_concurrency_failed_cohort_limit
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
smtp_destination_concurrency_negative_feedback =
$default_destination_concurrency_negative_feedback
smtp_destination_concurrency_positive_feedback =
$default_destination_concurrency_positive_feedback
smtp_destination_rate_delay = $default_destination_rate_delay
smtp_destination_recipient_limit = $default_destination_recipient_limit
smtp_discard_ehlo_keyword_address_maps =
smtp_discard_ehlo_keywords =
smtp_enforce_tls = no
smtp_fallback_relay = $fallback_relay
smtp_generic_maps =
smtp_header_checks =
smtp_helo_name = $myhostname
smtp_helo_timeout = 300s
smtp_host_lookup = dns
smtp_initial_destination_concurrency = $initial_destination_concurrency
smtp_line_length_limit = 990
smtp_mail_timeout = 300s
smtp_mime_header_checks =
smtp_mx_address_limit = 5
smtp_mx_session_l

Postfix stable release 2.10.0

2013-02-11 Thread Wietse Venema 
[An on-line version of this announcement will be available at
http://www.postfix.org/announcements/postfix-2.10.0.html]

Postfix stable release 2.10.0 is available. As of now, Postfix 2.6
is no longer updated.

Main changes (see the RELEASE_NOTES file for details):

  * Separation of relay policy (with smtpd_relay_restrictions) from
spam policy (with smtpd_{client, helo, sender,
recipient}_restrictions), which makes accidental open relay
configuration less likely. The default is backwards compatible.

  * HAproxy load-balancer support for postscreen(8) and smtpd(8).
The nginx proxy was already supported by Postfix 2.9 smtpd(8),
using XCLIENT commands.

  * Support for the TLSv1 and TLSv2 protocols, as well as support
to turn them off if needed for inter-operability.

  * Laptop-friendly configuration. By default, Postfix now uses
UNIX-domain sockets instead of FIFOs, and thus avoids MTIME
file system updates on an idle mail system.

  * Revised postconf(1) command. The "-x" option expands $name in
a parameter value (both main.cf and master.cf); the "-o name=value"
option overrides a main.cf parameter setting; and postconf(1)
now warns about a $name that has no name=value setting.

  * Sendmail-style "socketmap" lookup tables.

You can find the updated Postfix source code at the mirrors listed
at http://www.postfix.org/.

Wietse

Re: -o syslog_name=XYZ only shows first deferrals with that syslog_name? Retries appear to defer without the custom syslog_name.

2013-02-11 Thread Wietse Venema 
Donovan Bray:
> smtp104_120_110_27 unix  - - n - 150 smtp -o
> smtp_bind_address=104.120.110.27 -o syslog_name=postfix-app1 -o
> smtp_helo_name=mail-27.redacted.com

This overrides the logging from the Postfix smtp(8) client.

> We noticed that there were errors in the main mail.log file that referenced
> that lines IP address but with a name of 'postfix/error' instead of
> 'postfix-app1/error', and pflogsumm wasn't reporting those deferrals.

You did not override the logging from the Postfix error(8) daemon.

Wietse

Re: TLS Library Problem? Postfix 2.9.6

2013-02-11 Thread weber 



Am 2013-02-12 01:07, schrieb Wietse Venema:

we...@zackbummfertig.de:
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS 
library
problem: 18823:error:04075070:rsa routines:RSA_sign:digest too big 
for

rsa key:rsa_sign.c:127:
Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS 
library
problem: 18823:error:14099006:SSL 
routines:SSL3_SEND_CLIENT_VERIFY:EVP

lib:s3_clnt.c:2983:


The TLS library (i.e. OpenSSL) is not part of Postfix, so this may
be the wrong mailing list.

What does

$ openssl s_client -starttls smtp -connect servername:25



openssl s_client -starttls smtp -connect mail.domian.de:25

CONNECTED(0003)
depth=2 C = US, O = "thawte, Inc.", OU = Certification Services 
Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = 
thawte Primary Root CA

verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/O=mail.domain.de/OU=Go to 
https://www.thawte.com/repository/index.html/OU=Thawte SSL123 
certificate/OU=Domain Validated/CN=mail.domain.de

   i:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
 1 s:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 
2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 
2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting 
cc/OU=Certification Services Division/CN=Thawte Premium Server 
CA/emailAddress=premium-ser...@thawte.com

---
Server certificate
-BEGIN CERTIFICATE-
MIIEOjCCAyKgAwIBAgIQSlUaiYoSfpq8Je9tqw4GYDANBgkqhkiG9w0BAQUFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE
b21haW4gVmFsaWRhdGVkIFNTTDEZMBcGA1UEAxMQVGhhd3RlIERWIFNTTCBDQTAe
Fw0xMjA2MTMwMDAwMDBaFw0xMzA2MTMyMzU5NTlaMIGwMRgwFgYDVQQKFA9tYWls
LnpiZm1haWwuZGUxOzA5BgNVBAsTMkdvIHRvIGh0dHBzOi8vd3d3LnRoYXd0ZS5j
b20vcmVwb3NpdG9yeS9pbmRleC5odG1sMSIwIAYDVQQLExlUaGF3dGUgU1NMMTIz
IGNlcnRpZmljYXRlMRkwFwYDVQQLExBEb21haW4gVmFsaWRhdGVkMRgwFgYDVQQD
FA9tYWlsLnpiZm1haWwuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDAmiudVoYwLPurkEGr1hcGeCZN54qAAur2Dh+c49nTLwupCJg0CmpCLKbgUob3
wupH7TLyTodGYR3mMaOxiDjVExoiIblR9hDSnvm2pnH3wqbFA8mjiCRrCvdKLQeE
pykUob2wAyIU7ZvD1VJa/WrPLEoBAbsJCu4xMv8GYnLGBld3VFM31dNGCJQt8Y7S
55ICMPKjVrQFNtkRRlCKqZnjpsmtWL/7Tji8qLVc8t8zPjB4oDPmSNhhd8bMjPBj
MAUi5Z1vsxbr40I/pTJ589QK2qcWNwEXXqZ2t6Nn2UoDnNDG/Z8bWmjRty+rThXA
2AJR1h57T8pFf3KgGedrhT1tAgMBAAGjgaAwgZ0wDAYDVR0TAQH/BAIwADA6BgNV
HR8EMzAxMC+gLaArhilodHRwOi8vc3ZyLWR2LWNybC50aGF3dGUuY29tL1RoYXd0
ZURWLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUH
AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqG
SIb3DQEBBQUAA4IBAQCYg3cdadM1yTaBSqE1AoEZHLq//WuabpkkGIqNUJVzuI7C
XqY5HOoLvuN7JBHJeNnFiZ9oMaVJeflc7FhExhxFF0M+lbpw77ZCVjpsCzYbr64h
Q1xcjxiu9E1tXNzB9VYW3f14fO08+z+ldg+Ip4Thukn1M4VEV2iIKsDjgZKANCMk
rRDVYHV9HjctIYdUv7hSvpOP+IZYyl19QVOPeXwYo1BSUfbf0q61VTnU2U4fXzMC
XmXU1iiTBmyLBp3rpPISIrIFyidZnz3t5DdpTbSG0stAdMdgTT1XI1l3W7Ok/B4V
+EYiEb5JOwXLuXh0h82R7DZo0ZyEL0RxA21EbCup
-END CERTIFICATE-
subject=/O=mail.domain.de/OU=Go to 
https://www.thawte.com/repository/index.html/OU=Thawte SSL123 
certificate/OU=Domain Validated/CN=mail.domain.de

issuer=/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
---
Acceptable client certificate CA names
/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

---
SSL handshake has read 4609 bytes and written 504 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 
01A34AF6F2586EFB5FCF8A4860FF9D13607FAE8BF2774587801985C6E5106C13

Session-ID-ctx:
Master-Key: 
09925141BD917D5E098A9BB18B8B547C732E6A38564CEEF3DAA18ECE963E24E7767D786E1276A117D13CAB5343C3B87C

Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 3600 (seconds)
TLS session ticket:
 - ae 98 22 74 98 e5 42 e3-d5 ab 25 80 bb 1a b6 ab   
.."t..B...%.
0010 - 45 fd 31 cb 63 96 1b 7d-44 1e 78 86 15 c5 de 17   
E.1.c..}D.x.
0020 - 05 42 1a bb 5b f2 e2 23-4a 63 cb 90 ed e8 a0 ca   
.B..[..#Jc..
0030 - 54 4e 08 7c c2 14 3a 0a-ad fe 31 89 6b 83 84 86   
TN.|..:...1.k...
0040 - 91 ce a8 06 7e 30 78 e4-ef e2 7c 7f 96 90 99 d8   
~0x...|.
0050 - ab 51 2a 6d 51 bb 2d 32-da b9 64 ec af 61 06 3a   
.Q*mQ.-2..d..a.:
0060 - 2f 9b e9 ea f3 23 38 01-7a 6f ed d2 d6 b8 65 8c   
/#8.zoe.
0070 - a7 9d 64 15 ff ca b8 e2-25 87 b0 86 a8 e5 87 97   
..d.%

Re: TLS Library Problem? Postfix 2.9.6

2013-02-11 Thread Viktor Dukhovni 
On Mon, Feb 11, 2013 at 11:58:07PM +0100, we...@zackbummfertig.de wrote:

> on my backup relay server i find these lines in the logs.
> i rebuild openssl and postfix.
> i am on gentoo linux.
> 
> openssl 1.0.1c

Gentoo builds software from source, are you sure you built OpenSSL
1.0.1c and not the troubled 1.0.1d?

> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
> library problem: 18823:error:04075070:rsa routines:RSA_sign:digest
> too big for rsa key:rsa_sign.c:127:
> Feb 11 22:52:52 fallbackhost postfix/smtp[18823]: warning: TLS
> library problem: 18823:error:14099006:SSL
> routines:SSL3_SEND_CLIENT_VERIFY:EVP lib:s3_clnt.c:2983:

This is only possible when the client and server are using TLSv1.2
and the client presents its own certificate. Do you have a client
cert? If so, can you post the output of:

$ openssl x509 -in clientcert.pem

Also the output of:

$ postconf -n | egrep '^(smtp_)?tls_'

> any ideas? what causes these errors?

The TLSv1.2 digest algorithm negotiated with the server is reportedly
"too big" for your client certificate. If so, this feels like an
implementation bug. The client should not present a certificate
for which it can't generate a signature using the agreed digest.

https://tools.ietf.org/html/rfc5246#section-7.4.8

The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field
of the CertificateRequest message.  In addition, the hash and
signature algorithms MUST be compatible with the key in the
client's end-entity certificate.  RSA keys MAY be used with any
permitted hash algorithm, subject to restrictions in the
certificate, if any.

You can retry the s_client command with the same client certificate
configured with Postfix,

$ openssl s_client \
-cert clientcert.pem -key clientkey.pem \
-state -debug -msg -starttls smtp -connect mail.zbfmail.de:25

I'm only able to reproduce your problem when I generate and use an
insecure 512-bit RSA client certificate (not a good plan).

SSL_connect:SSLv3 write client key exchange A
SSL_connect:error in SSLv3 write certificate verify A
SSL_connect:error in SSLv3 write certificate verify A
140735152091612:error:04075070:rsa routines:RSA_sign:digest too big for rsa 
key:rsa_sign.c:127:
140735152091612:error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP 
lib:s3_clnt.c:2983:

When I specify a 1024-bit key, the handshake completes normally.
Whatever motivated you to configure a client certificate, and
particularly a pointlessly weak one that is well short of 1024-bits,
was probably the result of a particularly delirious nightmare.

Just relax and set:

main.cf:
smtp_tls_cert_file = 
smtp_tls_key_file = 

as documented in:

http://www.postfix.org/TLS_README.html#client_cert_key

-- 
Viktor.

Re: error using certificate server

2013-02-11 Thread Viktor Dukhovni 
On Tue, Feb 12, 2013 at 01:36:15AM +0100, deconya wrote:

> Thanks for you answers
> 
> I continue with the problem and I don't know where I can check more. At
> now the situation is
> 
> -Sends mails deferred
> 
> -In logs appears:
> 
> Feb 12 01:20:50 mailserver postfix/smtpd[16653]: warning:
> smtpd_tls_security_level: unsupported TLS level "verify", using "encrypt"
> Feb 12 01:20:50 mailserver postfix/smtpd[16653]: initializing the
> server-side TLS engine

I give up, you still can't pay attention long enough to distinguish
"smtp_tls_security_level" from "smtpd_tls_security_level". Good luck,
over and out.

--
Viktor.