Large hash access lists - performance impact?
Hello world, does anyone have experience with very large (about 2k entries) hash tables? I'll have to implement a check_recipient_access rule within smtpd_recipient_restrictions - it will be only temporary, three days at most, but I'm still worried about the possible performance impact. OS would be a recent CentOS 6.3, server is some mid-end hexacore form last year (I guess I/O does not matter in context of evaluationg hash tables), daily usage is about 80k deliveries and 200k connections, resulting in absolutely no load at all... until now. Stefan
Re: error using certificate server
Hi Recovering this thread Im configuring the CA certificates to validate the smarthost used to filter spam. At now the connection works but appears the message status=deferred (Server certificate not verified) I was looking all the information about it in howots, and seems that the problem is when my server exchanges credentials with smarthost. It seems that not recognizes the CA certificates from destination, and Im with two questions -What file is looking for smtp_tls_CApath=/certs, all? (Im refering the name of file), needs to use a special name? At now for recomedation of you and using howto of postfix I change this to smtp_tls_CApath = /var/spool/postfix/certs smtpd_tls_CApath = /var/spool/postfix/certs And now I don't know If I need to do something more to accept connection when sends to this smarthost, ideas? Best Regards El 08/02/13 20:07, deco...@riseup.net escribió: > > Hi list > > At now Im configuring the TLS function in my postfix 2.5.5 and Im > having a new problem. > > First was that said untrusted issuer because not detect the > certificates. At now the message every time you sends is > > status=deferred (Server certificate not verified) > > I was configuring using a howto that says to do > > - > mkdir /var/spool/postfix/certs > cp -R /etc/ssl/certs/* /var/spool/postfix/certs > mkdir -p /var/spool/postfix/usr/share/ca-certificates > cp -R /usr/share/ca-certificates > /var/spool/postfix/usr/share/ca-certificates > > Then, in main.cf, change the smtp_tls_security_level line and add an > smtp_tls_CApath line as follows: > > smtp_tls_security_level=verify > smtp_tls_CApath=/certs > > - > > And now the postconf for help: > > 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 = smtp.puc.mysmarthost.es > 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_limit = 2 > smtp_nested_header_checks = > smtp_never_send_ehlo = no > smtp_pix_workaround_delay_time = 10s > smtp_pix_workaround_maps = > smtp_pix_workaround_threshold_time = 500s > smtp_pix_workarounds = disable_esmtp,delay_dotcrlf > smtp_quit_timeout = 300s > smtp_quote_rfc821_envelope = yes > smtp_randomize_addresses = yes > smtp_rcpt_timeout = 300s > smtp_rset_timeout = 20s > smtp_sasl_auth_cache_name = > smtp_sasl_auth_cache_time = 90d > smtp_sasl_auth_enable = no > smtp_sasl_auth_soft_bounce = yes > smtp_sasl_mechanism_filter = > smtp_sasl_password_maps = hash:/etc/postfix/relay_passwd > smtp_sasl_path = > smtp_sasl_security_options = noanonymous > smtp_sasl_tls_security_options = $smtp_sasl_security_options > smtp_sasl_tls_verified_security_options = $smtp_sasl_tls_security_options > smtp_sasl_type = cyrus > smtp_send_xforward_command = no > smtp_sender_dependent_authentication = no > smtp_skip_5xx_greeting = yes > smtp_skip_quit_response = yes > smtp_starttls_timeout = 300s > smtp_tls_CAfile = > smtp_tls_CApath = /certs > smtp_tls_cert_file = > smtp_tls
Re: Large hash access lists - performance impact?
On 2/10/2013 4:37 AM, Stefan Foerster wrote: > Hello world, > > does anyone have experience with very large (about 2k entries) hash > tables? Hash tables scale very well to hundreds of thousands of entries; 2k entries on an Atom processor with 1G ram won't be an issue. -- Noel Jones > > I'll have to implement a check_recipient_access rule within > smtpd_recipient_restrictions - it will be only temporary, three days > at most, but I'm still worried about the possible performance impact. > > OS would be a recent CentOS 6.3, server is some mid-end hexacore form > last year (I guess I/O does not matter in context of evaluationg hash > tables), daily usage is about 80k deliveries and 200k connections, > resulting in absolutely no load at all... until now. > > > Stefan >
Re: error using certificate server
On Sun, Feb 10, 2013 at 01:46:59PM +0100, deconya wrote:
> status=deferred (Server certificate not verified)
>
> I was looking all the information about it in howots, and seems that the
> problem is when my server exchanges credentials with smarthost. It seems
> that not recognizes the CA certificates from destination, and Im with
> two questions
>
> -What file is looking for smtp_tls_CApath=/certs, all? (Im refering the
> name of file), needs to use a special name? At now for recomedation of
> you and using howto of postfix I change this to
Configuring CApath is a lot more complicated than setting up a CAfile.
When you have exactly one root CA to verify (the one used by the ISP's
relay) there is little benefit in managing a "herd" (choose your
favourite collective noun) of certificates via CApath.
> smtp_tls_CApath = /var/spool/postfix/certs
> smtpd_tls_CApath = /var/spool/postfix/certs
Instead:
/etc/postfix/main.cf:
# Empty
smtpd_tls_CApath =
smtpd_tls_CAfile =
smtp_tls_CApath =
# Copy PEM format root CA cert into this file
smtp_tls_CAfile = ${config_directory}/smtp_CAfile
/etc/postfix/smtp_CAfile:
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
Obtain the root CA certificate for the relay's smtp server in PEM
format (base64-encoded text between -BEGIN, -END line pairs)
from a trusted source and copy it into the CA file. Verify that
the file is well-formed by running:
openssl x509 -in /etc/postfix/smtp_CAfile -noout \
-subject -issuer -dates -sha1 -fingerprint
This must produce no errors and report the DN of the expected root
CA as both subject and issuer. The certificate must not be expired,
and typically is valid for 10-20 years. You can usually "google"
the sha1 fingerprint to find various online copies of the same CA
certificate.
You can store multiple trusted roots in a single CAfile, just
concatenate individual files with PEM format trusted root CA certs.
--
Viktor.
do i understand tls_policy_maps right?
hello, when i set in main.cf: smtp_tls_policy_maps= hash:/etc/postfix/tls_policy and do in /etc/postfix/tls_policy = externaldomain.com encrpyt will then every mail leaving my server to externaldomain.com forced using tls ? and when i set in the same map external2.com verify every incoming mail is checked if the cert is signed by the CA , that i have stored in the CA_path ? marko
SASL question
I had a server running on gentoo and it was running OK, but the latest updates in the gentoo tree killed it. So I spent yesterday afternoon setting up new mail server using Ubuntu 12.04 LTS. It took a while, but I have it all working except for smtp authentication (which was working on the gentoo machine. I copied the configuration over to the new machine and now I'm getting the following error: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: Invalid argument according to the redhat website that tells me that it is because postfix is linked against the wrong version of berkely db. https://bugzilla.redhat.com/show_bug.cgi?id=734088 However, nothing in my configuration says to open the sasldb file anywhere as the auth machanism is set to imap, but postfix seems intent on opening this file anyway. smtpd.conf: pwcheck_method: saslauthd mech_list: PLAIN LOGIN #auxprop_plugin: imap Does anyone have any ideas?
SASL question
I had a server running on gentoo and it was running OK, but the latest updates in the gentoo tree killed it. So I spent yesterday afternoon setting up new mail server using Ubuntu 12.04 LTS. It took a while, but I have it all working except for smtp authentication (which was working on the gentoo machine. I copied the configuration over to the new machine and now I'm getting the following error: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: Invalid argument according to the redhat website that tells me that it is because postfix is linked against the wrong version of berkely db. https://bugzilla.redhat.com/show_bug.cgi?id=734088 However, nothing in my configuration says to open the sasldb file anywhere as the auth machanism is set to imap, but postfix seems intent on opening this file anyway. smtpd.conf: pwcheck_method: saslauthd mech_list: PLAIN LOGIN #auxprop_plugin: imap Does anyone have any ideas?
Re: SASL question
Am 10.02.2013 21:31, schrieb Curtis Maurand:
> I had a server running on gentoo and it was running OK, but the latest
> updates in the gentoo tree killed it. So I
> spent yesterday afternoon setting up new mail server using Ubuntu 12.04 LTS.
>
> It took a while, but I have it all working except for smtp authentication
> (which was working on the gentoo
> machine. I copied the configuration over to the new machine and now I'm
> getting the following error:
>
> warning: SASL authentication problem: unable to open Berkeley db
> /etc/sasldb2: Invalid argument
>
> according to the redhat website that tells me that it is because postfix is
> linked against the wrong version of
> berkely db.
> https://bugzilla.redhat.com/show_bug.cgi?id=734088
>
> However, nothing in my configuration says to open the sasldb file anywhere as
> the auth machanism is set to imap,
> but postfix seems intent on opening this file anyway.
what are you using for IMAP?
if dovecot throw away the whole SASL crap!
dovecot.conf:
# configure backend for postfix sasl-auth
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
mainc.f:
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
signature.asc
Description: OpenPGP digital signature
Re: SASL question
* Curtis Maurand : > > > I had a server running on gentoo and it was running OK, but the latest > updates in the gentoo tree killed it. So I spent yesterday afternoon > setting up new mail server using Ubuntu 12.04 LTS. > > It took a > while, but I have it all working except for smtp authentication (which > was working on the gentoo machine. I copied the configuration over > to the new machine and now I'm getting the following error: > > warning: SASL authentication problem: unable to open Berkeley db > /etc/sasldb2: Invalid argument Did you follow the SASL documentation in Ubuntus Postfix documentation? On Debian/Ubuntu etc. you have to add the postfix user to the sasl group. > according to the redhat website > that tells me that it is because postfix is linked against the wrong > version of berkely db. > https://bugzilla.redhat.com/show_bug.cgi?id=734088 Nope. Wrong path. Debian is not RedHat. > However, nothing in my configuration says to open the sasldb file anywhere > as the auth machanism is set to imap, but postfix seems intent on opening > this file anyway. Cyrus SASL opens sasldb as fallback when all other attempts to do AUTH have failed. That in turn says your current setup is non-functional. Which docs did you follow? What's your current setup? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: SASL question
Patrick Ben Koetter wrote: > * Curtis Maurand : >> >> >> I had a server running on gentoo and it was running OK, but the latest >> updates in the gentoo tree killed it. So I spent yesterday afternoon >> setting up new mail server using Ubuntu 12.04 LTS. >> >> It took a >> while, but I have it all working except for smtp authentication (which >> was working on the gentoo machine. I copied the configuration over >> to the new machine and now I'm getting the following error: >> >> warning: SASL authentication problem: unable to open Berkeley db >> /etc/sasldb2: Invalid argument > > Did you follow the SASL documentation in Ubuntus Postfix documentation? On > Debian/Ubuntu etc. you have to add the postfix user to the sasl group. > > >> according to the redhat website >> that tells me that it is because postfix is linked against the wrong >> version of berkely db. >> https://bugzilla.redhat.com/show_bug.cgi?id=734088 > > Nope. Wrong path. Debian is not RedHat. > >> However, nothing in my configuration says to open the sasldb file >> anywhere >> as the auth machanism is set to imap, but postfix seems intent on >> opening >> this file anyway. > > Cyrus SASL opens sasldb as fallback when all other attempts to do AUTH > have > failed. That in turn says your current setup is non-functional. Which docs > did > you follow? What's your current setup? > > My currwnt setup has the imap connecting to a remote server on a private network. The imap server is dbmail 2.2.17. Postfix is a member of the sasl group. There is an sasldb2 file just in case. > >
Re: do i understand tls_policy_maps right?
On Sun, Feb 10, 2013 at 09:22:34PM +0100, we...@zackbummfertig.de wrote: > When I set in main.cf: > > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy > > and in > > /etc/postfix/tls_policy: > > example.com encrypt > > Will then every mail leaving my server to example.com be required > to use TLS? Yes, but without validation of the peer certificate. Thus you get protection from passive eavesdropping, but not active man-in-the-middle attacks (on TLS). > And when I set in the same map > > example.net verify > > Every incoming mail is checked if the cert is signed by the CA, > that i have stored in the CA_path ? No. The policy table as documented applies only to outgoing mail. Also the "verify" security level is not immune to MITM attacks that return forged DNS responses. To avoid all MITM attacks, use "secure", not "verify", provided the destination's SMTP servers have suitable certificates. Often you need to explicity provide non-default "match" parameters along with the "secure" policy. Once you do so, the "verify" and "secure" levels become identical, they only differ in their default match policies. All of this is explained in http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure http://www.postfix.org/TLS_README.html#client_tls_policy -- Viktor.
Re: SASL question
Am 10.02.2013 23:59, schrieb Curtis Maurand:
> My currwnt setup has the imap connecting to a remote server on a private
> network. The imap server is dbmail 2.2.17.
>
> Postfix is a member of the sasl group. There is an sasldb2 file just in
> case.
i am using dovecot as proxy in front of dbmail
since 2009 and for sasl auth because this way
you have ecryption, CRAM-MD5 and so on for
IMAP as also the same SASL auth mechs for SMTP
if postfix is using dovecot for SASL
the sql-config below is for a localhost where dbmail-imapd
is listening on 127.0.0.1:20143 and dovecot on 0.0.0.0:143
relevant snippets from dovecot.conf
# configure proxy-database
passdb {
driver= sql
args = /etc/dovecot/sql.conf
}
# we are not using local users
userdb {
driver= static
args = static uid=15000 gid=15000 home=/dev/null
}
# configure backend for postfix sasl-auth
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group= postfix
}
}
[root@srv-rhsoft:~]$ cat /etc/dovecot/sql.conf
driver = mysql
connect = host=mysqlhost dbname=dbmail user=dbmail
password=
password_query = SELECT passwd as password, '127.0.0.1' as host, '20143'
as port, userid as destuser, passwd
AS pass, 'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM dbmail_users WHERE
userid='%u'
default_pass_scheme = plain
signature.asc
Description: OpenPGP digital signature
Re: SASL question
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? Simon -- htholidays.com
Re: Connection timed out due to dns timeouts
El 08/02/13 15:29, Viktor Dukhovni escribió:
On Fri, Feb 08, 2013 at 09:29:22AM +0100, Angel L. Mateo wrote:
We are having problems with dns lookups to one domain. I know is
not a postfix problem, but a dns configuration error in that domain.
But it is affecting our servers.
The easiest work-around is to stop sending mail to the unreachable
domain.
Yes, I did it yet, but it could happen with other domains. I would like
a solution, not a workround.
The problem is that whenever the relay server receives a mail
directed to that domain, I get the error "conversation with timed out while sending MAIL FROM". And as list server group
messages, all recipients in that group as rejected.
Your DNS timeouts are too long (perhaps tunable via /etc/resolv.conf
on the relay), or SMTP timeouts too short (tunable via main.cf on
the list server). You posted no log entries, or "postconf -n" so
further help is not possible.
I'm sorry, I have attached it now, My timeouts are both defaults.
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 86337
address_verify_map = btree:${data_directory}/verify
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = yes
body_checks = pcre:/etc/postfix/body_checks.pcre
bounce_size_limit = 10240
broken_sasl_auth_clients = yes
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
default_privs = nobody
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
lmtp_data_done_timeout = 1200s
lmtp_destination_recipient_limit = 10
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 2560
mime_header_checks = pcre:/etc/postfix/mime_header_checks.pcre
mydestination = $myhostname, localhost.\$mydomain, localhost
mydomain = um.es
myhostname = xenon11.um.es
mynetworks = 127.0.0.0/8, 155.54.0.0/16, 10.54.0.0/16, 10.56.0.0/16,
10.64.0.0/28, 172.19.0.0/16, 10.57.0.0/16, 155.54.212.160/28
myorigin = um.es
nested_header_checks = pcre:/etc/postfix/nested_header_checks.pcre
newaliases_path = /usr/bin/newaliases
notify_classes = resource, software
parent_domain_matches_subdomains = 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
$smtpd_sender_login_maps
queue_directory = /var/spool/postfix
queue_minfree = 3840
rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
readme_directory = /usr/share/doc/postfix
recipient_canonical_maps = hash:/etc/postfix/listas_con_um_es
relay_domains = um.es, alu.um.es, cii-murcia.es, cyum.es, lcu.es, dif.um.es,
ditec.um.es, fuem.um.es, infomun.um.es, listas.um.es, listas.cii-murcia.es,
campusmarenostrum.com, listas.campusmarenostrum.es, ticarum.es,
aulavirtual.um.es
relay_recipient_maps = hash:/etc/postfix/relaydomains,
hash:/etc/postfix/alu-aliases, hash:/etc/postfix/dif-aliases,
proxy:ldap:/etc/postfix/ldap-vmail.cf,
proxy:ldap:/etc/postfix/ldap-sysaliases.cf
relocated_maps = proxy:ldap:/etc/postfix/ldap-relocated.cf
sample_directory = no
sendmail_path = /usr/lib/sendmail
setgid_group = postdrop
smtpd_banner = $myhostname NO UCE ESMTP
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 100
smtpd_client_event_limit_exceptions = 127.0.0.1, 172.19.0.0/16,
155.54.208.0/24, 155.54.212.0/24, 155.54.213.0/24, 155.54.216.0/24,
155.54.67.15, 155.54.135.194, 10.54.1.8, 155.54.204.60, 155.54.204.49,
155.54.210.253, 155.54.169.2, 155.54.204.69, 155.54.204.128, 155.54.206.3,
155.54.118.3, 155.54.204.146, 155.54.67.13, 155.54.170.10, 155.54.21.123,
155.54.204.57, 155.54.204.9, 155.54.204.231, 155.54.211.0/24, 155.54.117.10,
130.206.18.0/27, 155.54.119.83
smtpd_client_message_rate_limit = 500
smtpd_client_restrictions = check_client_access
cidr:/etc/postfix/client_checks.cidr, permit_sasl_authenticated,
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,check_helo_access
hash:/etc/postfix/helo_checks
smtpd_recipient_limit = 150
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
reject_unknown_recipient_domain,check_recipient_access
pcre:/etc/postfix/recipient_checks.pcre, check_recipient_access
hash:/etc/postfix/verified_recipient_checks, check_policy_service
inet:127.0.0.1:10031, permit_mynetworks,
