Re: domain resolution in check_client_access tables
Thank you to Wietse and Viktor for the replies. Appreciate explanations very much. On Sunday, November 17, 2013 4:42 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Sun, Nov 17, 2013 at 07:34:47PM -0500, Wietse Venema wrote: I wanted to allow certain clients to relay by using a check_client_access lookup map. It works nice if I use IP addresses. If I use domain names, it stops working for my test environment. My test client doesn't have rDNS set up (I think this is the cause of connect from unknown[x.x.x.x], right?). Do the check_client_access domain checks require rDNS? Any decision based on SMTP client hostname requires either an entry entry in /etc/hosts or equivalent, or a PTR record in DNS. And with DNS lookups, there is always the possibility of temporary lookup failures leading to the client being unknown now and then. This is fine when rejecting unknown clients because the rejection will be a temporary failure. It is not fine when whitelisting clients by their DNS name, since in that case they may be hard-rejected by later restrictions. The problem is unavoidable. Do not rely on whitelists that use names obtained via DNS. -- Viktor.
Client host name resolution
Hello, My understanding was clients for whom you see this in the logs: connect from unknown[1.2.3.4] Do not have a PTR/rDNS set up for themselves. However, I recently tested a connection (using telnet on the client side, connecting to port 25) from a server that does have rDNS in place, but I still get the connect from unknown. I did dig -x 1.2.3.4 on the server for the same IP address and the result came back with the correct domain name. So why didn't postfix see the host name? I restarted postfix in case it was caching, but it didn't help. I also tried putting this in /etc/hosts 1.2.3.4 host.example.com That didn't help, either. Appreciate any tips.
Re: Client host name resolution
Am 18.11.2013 12:43, schrieb E.B.: My understanding was clients for whom you see this in the logs: connect from unknown[1.2.3.4] Do not have a PTR/rDNS set up for themselves. However, I recently tested a connection (using telnet on the client side, connecting to port 25) from a server that does have rDNS in place, but I still get the connect from unknown. I did dig -x 1.2.3.4 on the server for the same IP address and the result came back with the correct domain name. So why didn't postfix see the host name? I restarted postfix in case it was caching, but it didn't help. I also tried putting this in /etc/hosts 1.2.3.4 host.example.com That didn't help, either. Appreciate any tips. check your master.cf that chroot is *explicit* set to NO
Re: Client host name resolution
On Mon, Nov 18, 2013 at 03:43:17AM -0800, E.B. wrote: I did dig -x 1.2.3.4 on the server for the same IP address and the result came back with the correct domain name. So why didn't postfix see the host name? I restarted postfix in case it was caching, but it didn't help. Show proof. Especially as 1.2.3.4 does _not_ have a PTR in the public DNS. There are several reasons why this does not work. Several of them are even listed in the log. Bastian -- Many Myths are based on truth -- Spock, The Way to Eden, stardate 5832.3
Re: Diffie-Hellman parameters
On Mon, Nov 18, 2013 at 10:53:19AM +0100, Andreas Schulze wrote: On the other hand, some Exim MTA SMTP clients (patched by a well-meaning, but under-informed Debian maintainer) don't support DH primes shorter than 2048 bits. I had trouble to receive messages from those sites too. I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server. That solved the problem ... Any evidence of other legitimate MTAs that now routinely fail TLS handshakes? I don't believe that the rather minimal TLS stack on Windows 2003 supports any EDH ciphersuites, so old Microsoft Exchange versions are probably unaffected. Similarly, no MTAs using OpenSSL or GnuTLS have such a limit, thus Sendmail, Exim and Qmail patched with TLS support are fine. The historical upper-bound on prime-DH sizes in NSS (the PKI stack in Netscape and then Firefox, ...) is 2236 bits. Thus 2048-bits should interoperate with Oracle Communications Messaging Server. https://bugzilla.mozilla.org/show_bug.cgi?id=636802 This leaves email from the large consumer email providers (Gmail, Hotmail, Yahoo, AOL), various vendor border SMTP appliances and various telco ISP email systems. Is there any evidence of inbound TLS handshake failures from any MTAs in the last group that is possibly related to interoperability issues with 2048 bit EDH? -- Viktor.
Re: Diffie-Hellman parameters
Zitat von Viktor Dukhovni postfix-us...@dukhovni.org: Any evidence of other legitimate MTAs that now routinely fail TLS handshakes? no, I don't saw more TLS errors. There is a usual noise of TLS failures that didn't changed. Andreas
Re: Diffie-Hellman parameters
On 18 Nov 2013, at 02:53 , Andreas Schulze s...@andreasschulze.de wrote: I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server. That solved the problem ... I can't imagine that that didn't cause other problems. If a server negotiates for a dh1024 key and is expecting a dh1024 key and it gets a dh2048 key, it is (hopefully) going to pitch a fit and barf. -- I do not feel obliged to believe that same God who endowed us with sense, reason, and intellect had intended for us to forego their use.
Re: Diffie-Hellman parameters
On Mon, Nov 18, 2013 at 08:03:00AM -0700, LuKreme wrote: I changed smtpd_tls_dh1024_param_file to use a 2k dh key at the mx server. That solved the problem ... I can't imagine that that didn't cause other problems. If a server negotiates for a dh1024 key and is expecting a dh1024 key and it gets a dh2048 key, it is (hopefully) going to pitch a fit and barf. There is no negotiation for a DH 1024 prime. TLS clients announce support for various prime-DH cipher-suites with an *unspecified* prime size. The TLS server announces the prime unilaterally in its Server Key Exchange message when it chooses such a cipher-suite from the client's list. Based on TLS protocol standards alone, all primes are equal, but clearly some primes are more equal than others. Some clients want primes that are not too large, others primes that are not too small. So the server needs a Goldilocks prime. :-) The bit-length of a Goldilocks prime varies by application protocol, based on the capabilities of the client implementations of that application protocol. For MTA to MTA SMTP, we have some evidence that 2048-bits is just right, for MUA to MTA submission, 1024-bits is for now more appropriate. -- Viktor.
Re: Client host name resolution
E.B. wrote: Hello, My understanding was clients for whom you see this in the logs: connect from unknown[1.2.3.4] Do not have a PTR/rDNS set up for themselves. For Postfix to include the rDNS in the log and Received: header, the PTR name must then resolve back to that same IP as well. Sometimes there will be a PTR record, but no matching A record. Also keep in mind that if there is a temporary glitch in DNS resolution, either the PTR or A lookup might fail when the message first passes through, but looks fine later on when you check by hand. -kgd
Need Help: Postfix Relayhost Setup and Dovecot
Hi, I am trying to migrate from cyrus - (Ubuntu 12.04 LTS Server, Mysql Postfix, cyrus, webcyradmin, saslauth) to dovecot - (Ubuntu 12.04 LTS Server, Mysql Postfix, Dovecot, Postfixadmin, saslauth) It all works fine with postfix/cyrus. However under postfix/dovecot, I have a problem with my relayhost setup. I got the following message in mail.log: Nov 18 17:10:15 mail postfix/smtp[20654]: 2937521D41: to=x...@gmail.com, relay=smtp.isp.es[1.1.1.1]:25, delay=1.1, delays=0.09/0/0.87/0.18, dsn=5.0.0, status=bounced (host smtp.isp.es[1.1.1.1] said: 522 Authenticate first (in reply to MAIL FROM command)) I understand that I need to authenticate first for the relayhost to kick in, and I thought I had it. (Applied the same logic from the cyrus setup), but it seems I missed something. Can someone give me a hint ? main.cf append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix content_filter = amavis:[127.0.0.1]:10024 delay_warning_time = 4h disable_vrfy_command = yes dovecot_destination_recipient_limit = 1 enable_original_recipient = no header_checks = regexp:/etc/postfix/header_checks inet_interfaces = all local_recipient_maps = mailbox_size_limit = 0 maximal_backoff_time = 8000s maximal_queue_lifetime = 7d minimal_backoff_time = 1000s mydestination = myhostname = mail.solipym.com mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128,192.168.1.0/24 mynetworks_style = host myorigin = /etc/mailname readme_directory = no recipient_delimiter = + relayhost = smtp.isp.es smtp_enforce_tls = no smtp_helo_timeout = 60s smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_client_restrictions = permit_mynetworks, reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl smtpd_data_restrictions = reject_unauth_pipelining smtpd_delay_reject = yes smtpd_enforce_tls = no smtpd_hard_error_limit = 12 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_recipient_limit = 16 smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service inet:127.0.0.1:10023, permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit smtpd_soft_error_limit = 3 smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 450 virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf, mysql:/etc/postfix/mysql_virtual_alias_domainaliases_maps.cf virtual_gid_maps = static:8 virtual_mailbox_base = /var/vmail virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf, mysql:/etc/postfix/mysql_virtual_mailbox_domainaliases_maps.cf virtual_transport = dovecot virtual_uid_maps = static:150 master.cf # # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: man 5 master). # # Do not forget to execute postfix reload after editing this file. # # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # == # SMTP on port 25, unencrypted. smtp inet n - - - - smtpd -o syslog_name=postfix/smtp -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject -o smtpd_sasl_security_options=noanonymous,noplaintext -o smtpd_sasl_tls_security_options=noanonymous #smtp inet n - - - 1 postscreen #smtpd pass - - - - - smtpd #dnsblog unix - - - - 0 dnsblog #tlsproxy unix -
relaying individual virtual domain to new postfix server ?
I would like to transfer some virtual domains to a new postfix server, what is the proper way to do so, I've tried adding to /etc/main.cf like: relay_domains = dom.org.au transport_maps = hash:$config_directory/transport and /etc/transport dom.org.au smtp:[emu.sbt.net.au] that returned a warning Nov 19 12:06:49 postfix/trivial-rewrite[24520]: warning: do not list domain dom.org.au in BOTH virtual_mailbox_domains and relay_domains I've removed dom.org.au from the sql, that removed the error, but, mail still gets delivered localy Nov 19 12:21:37 geko postfix/qmgr[24491]: 8770E382B93: from=x...@gmail.com, size=1845, nrcpt=1 (queue active) Nov 19 12:22:46 geko postfix/lmtp[29684]: 8770E382B93: to=v...@sbt.net.au, orig_to=postmas...@dom.org.au, relay=127.0.0.1[127.0.0.1]:10024, delay=70, delays=1.4/42/0.26/27, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 44247382BA8) Nov 19 12:22:46 geko postfix/qmgr[24491]: 8770E382B93: removed what is the proper way to relay virtual domains ? grep virtual main.cf virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_mailbox_base = /var/mail/vhosts virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf virtual_mailbox_limit = $message_size_limit virtual_minimum_uid = 5000 virtual_gid_maps = static:5000 virtual_uid_maps = static:5000
