postfix-tls error
Hi, I have enabled tls in 2 postfix servers(MTA1, MTA2). when i try to send mail from simple java client to server it is working fine. TLS negotiation happened properly. But when MTA1 try to send mail to other MTA, mail is getting deferred by writing following log " Aug 2 11:21:34 AHQ postfix/smtp[6372]: BEC5D67928BD: to=, orig_to=, relay=201.123.1.4[201.123.1.4]:25, delay=0.06, delays=0.04/0.01/0.01/0, dsn=4.7.5, status=deferred (Server certificate not verified) " "postconf -n " output is as follows bounce_queue_lifetime = 40s command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix 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 html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailbox_size_limit = 5000 mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_queue_lifetime = 8h mydestination = $myhostname.$mydomain,$myhostname, $myhostname, localhost.localdomain mydomain = tcs.mil.in myhostname = 1CorpHQserver.tcs.mil.in mynetworks = 127.0.0.0/8, 201.123.80.0/24, 201.123.2.0/24, 201.123.1.0/24 mynetworks_style = subnet newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix queue_run_delay = 30s readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_enforce_tls = yes smtp_tls_CAfile = /etc/new_pki/tls/certs/ca-bundle.crt smtp_tls_policy_maps = hash:/etc/postfix/tls_policy smtpd_starttls_timeout = 300s smtpd_tls_CApath = /etc/postfix_certs_24_7_17/ca_cert smtpd_tls_ask_ccert = no smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix_certs_24_7_17/1corphq_smtp_ad...@tcs.mil.in.pem smtpd_tls_key_file = /etc/postfix_certs_24_7_17/1corphq_smtp_ad...@tcs.mil.in.key smtpd_tls_loglevel = 2 smtpd_tls_security_level = encrypt transport_maps = hash:/etc/postfix/transportmap unknown_local_recipient_reject_code = 550 virtual_alias_maps = ldap:/etc/postfix/virtual_alias_map_ldapusers, ldap:/etc/postfix/ldapdistlist.cf virtual_gid_maps = static:6000 virtual_mailbox_base = /var/mail/vmail virtual_mailbox_domains = 1CorpHQ.tcs.mil.in virtual_mailbox_maps = ldap:/etc/postfix/virtual_mailbox_ldapusers virtual_minimum_uid = 1000 virtual_uid_maps = static:6000 = tls_policy file is as follows [201.123.1.4]:25secure match=1CorpHQ "1CorpHQ" is exactly same as the CN field of the certificate How to solve the above error...I'm stuck at this point for a long time... Any help will be appreciated greatly... -- Thanks & Regards Hyndavi rapuru Member( Research Staff) Central Research Laboratory Bharat Electronics Ltd Jalahalli Bangalore- 560 013 Int Ph No: 134 Off Ph No: 080-28381125 Off Fax No: 28381168 कागज़ के 3000 पन्नों के लिए एक पेड़ को काटा जाता है... पेड़ बचाएँ... पेड़ों का संरक्षण करें... हरियाली लाएँ... इस मेल का या इसकी किसी फाइल का प्रिंट तब तक न लें जब तक सचमुच ज़रूरत न हो Every 3000 Sheets of paper costs us a tree.. Save trees... Conserve Trees. Don't print this email or any Files unless you really need to Confidentiality Notice/गोपनीय सूचना इस इलेक्ट्रॉनिक संदेश में शामिल जानकारी और इस संदेश के साथ दिया गया संलग्नक केवल प्रेषिती के अनन्य इस्तेमाल के लिए है और इसमें गोपनीय या विशेषाधिकार प्राप्त जानकारी शामिल हो सकती है । यदि आप आशयित प्राप्तकर्ता नहीं हैं, तो कृपया तुरंत भारत इलेक्ट्रॉनिक्स के प्रेषक को बताएँ या supp...@bel.co.in पर मेल द्वारा सूचित करें और इस संदेश की सभी प्रतियाँ और उसके साथ लगे संलग्नकों को नष्ट कर दें । The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Bharat Electronics or supp...@bel.co.in immediately and destroy all copies of this message and any attachments. कागज़ के 3000 पन्नों के लिए एक पेड़ को काटा जाता है... पेड़ बचाएँ... पेड़ों का संरक्षण करें... हरियाली लाएँ... इस मेल का या इसकी किसी फाइल का प्रिंट तब तक न लें जब तक सचमुच ज़रूरत न हो Every 3000 Sheets of paper costs us a tree.. Save trees... Conserve Trees. Don't print this email or any Files unless you really need to Confidentiality Notice/गोपनीय सूचना इस इलेक्ट्रॉनिक संदेश में शामिल जानकारी और इस संदेश के साथ दिया गया संलग्नक केवल प्रेषिती के अनन्य इस्तेमाल के लिए है और इसमें गोपनीय या विशेषाधिकार प्राप्त जानकारी शामिल हो सकती है । यदि आप आशयित प्राप्तकर्ता नहीं हैं, तो कृपया तुरंत भारत इलेक्ट्रॉनिक्स के प्रेषक को बताएँ या supp...@bel.co.in पर मेल द्वारा सूचित करें और इस संदेश की सभी प्रतियाँ और उसके साथ लगे संलग्नकों को नष्ट कर दें । The information contained in this electronic message a
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 1, 2017, at 04:41 PM, Viktor Dukhovni wrote: > Just put the cipherlist in single quotes, otherwise "bash" history > substitution gets in the way: Grrr. Ok. > DO NOT confuse ciphers with protocol versions. > No, these are protocol version exclusions, not cipher exclusions. Yep. That's exactly what I was doing. Clear now. Thanks. > The low-level cipherlist interface is an OpenSSL interface, and > you ask OpenSSL not Postfix to interpret the configuration. Ok. > It is unfortunate that you're forced to scale this particular > learning curve. The vast majority of users can stay blissfully > unaware, and are better off for that. I'm not going to complain about it. I've got a decent start on the details of how to set TLS up in Postfix, how to tear it down, why I'd want to do either and how to check what I ended up with. So I guess, a little wiser. Thanks alot for the guidance!
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 01, 2017 at 04:11:45PM -0700, robg...@nospammail.net wrote: > For any given cipherlist in Postfix e.g. > > tls_medium_cipherlist = > !kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH > > Is there a postfix command to display an order list, by preference, of > all the actually presented ciphers etc, *including* all the built-in > Postfix exclusions? No, you use OpenSSL for that. > I know I can do > > openssl ciphers -V CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH > > (can't figure out how to get the "!kDHE" in there) Just put the cipherlist in single quotes, otherwise "bash" history substitution gets in the way: openssl ciphers -V '!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH' > but that lists the Openssl result obvioiusly. Including the SSL3 ciphers it > looks like. DO NOT confuse ciphers with protocol versions. The SSLv3 ciphers are also TLS 1.x ciphers, and are needed for interoperability with many TLS 1.0, TLS 1.1 and TLS 1.2 sites. TLS 1.2 uses many ciphers that date back to SSLv3, some that date back to TLS 1.0, and some that are new with TLS 1.2 (TLS 1.1 added no new ciphers). > IIUC those are excluded in Postfix by > > smtp_tls_protocols = !SSLv2, !SSLv3 > smtpd_tls_protocols = !SSLv2, !SSLv3 No, these are protocol version exclusions, not cipher exclusions. The configured cipherlist is dynamically filtered for compatibility with the negotiated TLS version. The input cipherlist is the one you see from the "ciphers -V" command. To see what you'd get for a particular protocol version: $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1 -V 'CHACHA20:!aRSA:!aDSA:!PSK' $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_1 -V 'CHACHA20:!aRSA:!aDSA:!PSK' $ /opt/openssl/1.1.0/bin/openssl ciphers -s -tls1_2 -V 'CHACHA20:!aRSA:!aDSA:!PSK' 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD Which shows that if you want CHACHA20 without RSA or DSA certs you lose with TLS 1.0 and TLS 1.1, but scrape by with one compatible cipher with TLS 1.2. > Is there a way to get the Postfic-actual cipherlist, so MINUS the SSLv2, > SSLv3, and anything else Postfix auto-excludes? The low-level cipherlist interface is an OpenSSL interface, and you ask OpenSSL not Postfix to interpret the configuration. Postfix just passes the cipherlists to OpenSSL after appending any exclusions (automatic exclusions of eNULL and/or aNULL as appropriate plus the various explicit mumble_exclude_ciphers parameters). It is unfortunate that you're forced to scale this particular learning curve. The vast majority of users can stay blissfully unaware, and are better off for that. -- Viktor.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
For any given cipherlist in Postfix e.g. tls_medium_cipherlist = !kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH Is there a postfix command to display an order list, by preference, of all the actually presented ciphers etc, *including* all the built-in Postfix exclusions? I know I can do openssl ciphers -V CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH (can't figure out how to get the "!kDHE" in there) but that lists the Openssl result obvioiusly. Including the SSL3 ciphers it looks like. IIUC those are excluded in Postfix by smtp_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 in main.cf. Is there a way to get the Postfic-actual cipherlist, so MINUS the SSLv2, SSLv3, and anything else Postfix auto-excludes?
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
> On Aug 1, 2017, at 6:59 PM, robg...@nospammail.net wrote: > >> smtp_tls_high_cipherlist = >> !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH >> smtp_tls_medium_cipherlist = >> !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH > > smtp_tls_* > > or just > > tls_* > > > I'm finding the 2nd in the docs, but not the first. > > Typo? Or bad search by me? My typo. -- Viktor.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 1, 2017, at 03:27 PM, Viktor Dukhovni wrote: > smtp_tls_high_cipherlist = > !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH > smtp_tls_medium_cipherlist = > !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH smtp_tls_* or just tls_* I'm finding the 2nd in the docs, but not the first. Typo? Or bad search by me?
Re: SMTP connection reuse with TLS
On Tue, Aug 01, 2017 at 02:41:52PM -0700, mark burdett wrote: > Hi, I was curious if there are any plans for postfix to eventually support > SMTP connection reuse with STARTTLS. This requires a complex outbound TLS proxy to cache the connections in process, and handle peer authentication. Some of the work has already been done on the inbound side to enable TLS in postscreen, but much work remains, as outbound TLS is much more complex. This is not likely to happen in the near term. > After enabling TLS, postfix delivery was much slower, and packet capture > revealed the connection reset after each message was delivered. Postfix > documentation confirms there is no connection reuse with TLS. Unfortunately > this dramatically slows down delivery to the relay because of the RTT > overhead of new TCP connections. Increased latency can be amortized with increased concurrency. Just open more connections and the overall throughput rate will remain the same. Throughput = Concurrency / Latency -- Viktor.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 01, 2017 at 02:59:35PM -0700, robg...@nospammail.net wrote: > > The name "CHACHA20" matches any ciphersuite that uses that stream > > cipher for the bulk crypto: > > Sounds like a group. It names a set of related ciphersuites. > > $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20 > > Ok so 'documented' by openssl directly, nothing Postfix specific. Correct. > And subgroups? If for any group of ciphers to be used in Postfix I want > to only ever use EC ciphers, so eg "in practice" here, only the 1st two? Define "EC ciphers"! Do you want ECDHE key agreement, ECDSA certificates or both? > Some shorthand for "EC only"? For ECDSA (really not RSA or DSA) certificates with CHACHA20 preferred over AES, ... smtp_tls_high_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH smtp_tls_medium_cipherlist = !aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH For ECDHE (really not kRSA or kDHE) key exchange with CHACHA20 preferred over AES, ... smtp_tls_high_cipherlist = !kRSA:!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH smtp_tls_medium_cipherlist = !kRSA:!kDHE:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH For ECDHE with ECDSA combine both sets of exclusions: smtp_tls_high_cipherlist = !kRSA:!kDHE:!aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH smtp_tls_medium_cipherlist = !kRSA:!kDHE:!aRSA:!aDSS:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH This work by exclusion of stuff you don't want (RSA, DSS, DHE and RSA key exchange) and don't lock out future improvements by freezing in today's recommended settings for perpetuity. > I never really checked. Is crypto for Postfix always/only provided by > OpenSSL? Yes. > So naming for cipherlists, and related shorthand, is OpenSSL-specific and > so we look to OpenSSL for the docs? Or is that set at a standards level > and naming is consistent across Postfix, Openssl and all other crypto? The underlying cipher names are from OpenSSL and documented there. > > Enabling the system-default cert store will only make sense in the > > context of SMTP STS, if/when Postfix has support for that. Sadly, > > the large providers (Google, Yahoo, Microsoft, ...) have difficulties > > combining DNSSEC with their load-balancing infrastructure, so they > > are pushing STS, with all its flaws, but arguably better than > > nothing... > > SMTP STS hadn't even heard of yet. DNSSEC is on my todo list. The SMTP STS draft proposed standard is not yet out of working group last call... -- Viktor.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
> The name "CHACHA20" matches any ciphersuite that uses that stream > cipher for the bulk crypto: Sounds like a group. > $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20 Ok so 'documented' by openssl directly, nothing Postfix specific. > 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH > Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD > 0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH > Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD > 0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA > Enc=CHACHA20/POLY1305(256) Mac=AEAD ... > The four PSK variants can't be used by most TLS applications > (including Postfix), so in practice CHACHA20 means just the first > three. And subgroups? If for any group of ciphers to be used in Postfix I want to only ever use EC ciphers, so eg "in practice" here, only the 1st two? Some shorthand for "EC only"? I never really checked. Is crypto for Postfix always/only provided by OpenSSL? So naming for cipherlists, and related shorthand, is OpenSSL-specific and so we look to OpenSSL for the docs? Or is that set at a standards level and naming is consistent across Postfix, Openssl and all other crypto? > > Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use > > ONLY the system-supplied default Certification Authority > > certificates. ... > > Then it > > > > won't ONLY use sys default CA certs > > No, it will trust no CAs at all. A pox on all their houses. Ok. That makes more sense. That's not what I got from reading that section. It read to me like if you don't specify it it doesn't ONLY use ... > As for "tls_append_default_CA = no". These have been the default > setting for ages. Sure. I don't actually set it explicitly on my setup. Like you say it's the default. > $ postconf -d smtp_tls_CApath tls_append_default_CA > smtp_tls_CApath = > tls_append_default_CA = no > > > So what exactly IS it gonna do? > > Not trust any CAs. When you want to authenticate some peer, use > the "tafile" feature of the policy table to specify a sensible list > of trust-anchors for that peer. Ok. > Enabling the system-default cert store will only make sense in the > context of SMTP STS, if/when Postfix has support for that. Sadly, > the large providers (Google, Yahoo, Microsoft, ...) have difficulties > combining DNSSEC with their load-balancing infrastructure, so they > are pushing STS, with all its flaws, but arguably better than > nothing... SMTP STS hadn't even heard of yet. DNSSEC is on my todo list.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 01, 2017 at 01:59:54PM -0700, robg...@nospammail.net wrote: > > I strongly recommend against > > listing individual explicit cipher names. Later there will be > > better key exchange algorithms, better hashes, ... > > Yeah I noticed you used just 'CHACHA20', which I guess is the group name? > Or is that still just an abbreviated, explicit cipher name? The name "CHACHA20" matches any ciphersuite that uses that stream cipher for the bulk crypto: $ /opt/openssl/1.1.0/bin/openssl ciphers -V CHACHA20 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xAE - RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xAD - DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xAC - ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xAB - PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD The four PSK variants can't be used by most TLS applications (including Postfix), so in practice CHACHA20 means just the first three. > I've been using the full/explicit cipher name so far because I havent > found the right doc that lists the group name (CHACHA20) that includes > it. https://www.openssl.org/docs/man1.1.0/apps/ciphers.html > > I recommend an empty setting here. Tastes great, less filling. > > Ok. So if the docs say > > Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use > ONLY the system-supplied default Certification Authority > certificates. If that's what you want. > > Specify "tls_append_default_CA = no" to prevent Postfix from > appending the system-supplied default CAs and trusting third-party > certificates. If that's what you want. > and I set > > smtp_tls_CApath = > tls_append_default_CA = no > > Then it > > won't ONLY use sys default CA certs No, it will trust no CAs at all. A pox on all their houses. As for "tls_append_default_CA = no". These have been the default setting for ages. $ postconf -d smtp_tls_CApath tls_append_default_CA smtp_tls_CApath = tls_append_default_CA = no > So what exactly IS it gonna do? Not trust any CAs. When you want to authenticate some peer, use the "tafile" feature of the policy table to specify a sensible list of trust-anchors for that peer. Enabling the system-default cert store will only make sense in the context of SMTP STS, if/when Postfix has support for that. Sadly, the large providers (Google, Yahoo, Microsoft, ...) have difficulties combining DNSSEC with their load-balancing infrastructure, so they are pushing STS, with all its flaws, but arguably better than nothing... -- Viktor.
SMTP connection reuse with TLS
Hi, I was curious if there are any plans for postfix to eventually support SMTP connection reuse with STARTTLS. We were using postfix to deliver bulk mail (email newsletters) to a mail relay. When TLS was disabled, Postfix was able to open up multiple connections to the relay and reuse these connections for some period of time, maintaining a high send rate with minimal RTT due to TCP connection. After enabling TLS, postfix delivery was much slower, and packet capture revealed the connection reset after each message was delivered. Postfix documentation confirms there is no connection reuse with TLS. Unfortunately this dramatically slows down delivery to the relay because of the RTT overhead of new TCP connections. We switched to having our app do SMTP delivery directly to the relay with connection reuse (using a standard SMTP library), rather than delivering to the local postfix instance. This was a reasonable work-around for us. But we'd love to have postfix on hand to queue and deliver mail to the relay, if it were possible to optimize the STARTTLS support. (In case you're curious why rapid delivery of bulk mail matters, even bulk mail can be time sensitive: for example, advocacy organizations ask subscribers to tweet or call their elected representative that morning.) --mark B. signature.asc Description: OpenPGP digital signature
RE: Postscreen and reject_rhsbl
Here's a related recent thread
http://postfix.1071664.n5.nabble.com/postscreen-dnsbl-AND-smtpd-recipient-restrictions-rbl-tt91307.html#none
>-Original Message-
>From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
>On Behalf Of Alex
>Sent: Tuesday, August 01, 2017 3:58 PM
>To: postfix users list
>Subject: Postscreen and reject_rhsbl
>
>Hi,
>I'm using postfix-3.1.4 on fedora. I've just noticed I've configured
>both postscreen to use spamhaus and other RBLs as well as have
>configured the reject_rhsbl_* options. Is this duplicative and
>unnecessary?
>
>I've posted what I think are the relevant pieces in hopes someone
>could review and clarify.
>
>smtpd_recipient_restrictions =
>reject_non_fqdn_recipient,
>reject_non_fqdn_sender,
>reject_unlisted_recipient,
>reject_unknown_recipient_domain,
>permit_mynetworks,
>reject_unauth_destination,
>reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
>reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
>reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
>check_sender_access hash:/etc/postfix/check_backscatterer,
>check_helo_access pcre:/etc/postfix/helo_checks.pcre,
>check_helo_access hash:/etc/postfix/helo_checks,
>reject_non_fqdn_helo_hostname,
>reject_invalid_helo_hostname,
>check_policy_service unix:private/policy-spf,
>check_policy_service inet:127.0.0.1:2501,
>check_recipient_access pcre:/etc/postfix/relay_recips_access,
>permit
>
>smtpd_client_restrictions =
>permit_mynetworks,
>check_client_access hash:/etc/postfix/client_checks,
>check_reverse_client_hostname_access
>pcre:/etc/postfix/fqrdns-042715a.pcre,
>check_reverse_client_hostname_access
>pcre:/etc/postfix/reverse_client_hostname_access.pcre,
>check_client_access cidr:/etc/postfix/client_access_blocklist
>check_client_access cidr:/etc/postfix/ransomware-ipbl
>
>
>postscreen_dnsbl_ttl = 10m
>postscreen_access_list =
>permit_mynetworks,
>cidr:/etc/postfix/postscreen_access.cidr,
>cidr:/etc/postfix/gmail_whitelist.cidr,
>cidr:/etc/postfix/postscreen_spf_whitelist.cidr
>postscreen_blacklist_action = drop
>postscreen_dnsbl_action = enforce
>postscreen_greet_action = enforce
>postscreen_greet_wait = ${stress?2}${stress:11}s
>postscreen_dnsbl_threshold = 8
>postscreen_dnsbl_reply_map =
>texthash:$config_directory/postscreen_dnsbl_reply_map.pcre
>postscreen_dnsbl_sites =
>mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
>score.senderscore.com=127.0.4.[0..19]*3
>score.senderscore.com=127.0.4.[20..29]*3
>score.senderscore.com=127.0.4.[30..49]*2
>score.senderscore.com=127.0.4.[50..59]*1
>score.senderscore.com=127.0.4.[60..69]*1
>score.senderscore.com=127.0.4.[70..79]*-1
>score.senderscore.com=127.0.4.[80..89]*-2
>score.senderscore.com=127.0.4.[90..100]*-4
>b.barracudacentral.org*7
>mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
>bl.mailspike.net*4
>bl.spamcop.net*4
>bl.spameatingmonkey.net*4
>mykey.zen.dq.spamhaus.net=127.0.0.3*4
>ubl.unsubscore.com=127.0.0.2*1
>list.dnswl.org=127.[0..255].[0..255].0*-2
>list.dnswl.org=127.[0..255].[0..255].1*-3
>list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
>dnsbl.sorbs.net=127.0.0.[10;14]*8
>dnsbl.sorbs.net=127.0.0.5*7
>dnsbl.sorbs.net=127.0.0.7*4
>dnsbl.sorbs.net=127.0.0.6*3
>dnsbl.sorbs.net=127.0.0.[8;9]*2
>dnsbl.sorbs.net=127.0.0.4*1
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
> Therefore, after "CHACHA20:-CHACHA20" the CHACHA20 ciphers are at > the top of the enabled+unselected cipher stack. And then after > "aNULL:-aNULL" the "aNULL" ciphers are at the top of the stack. That's what I it took. I was thinking of it in a literal order, not necessarily a pop'd/push'd stack Thanks. > I am assuming you are now wiser You know what they say about assumptions. But, I hope so! > how much you don't yet know about cipherlists... :-) It LOOKS simple when you first look at in the docs. > > So how DO you make sure that a specific cipher is ALWAYS used if it's > > available? > > You list the preferred category first. Which now makes more sense in stack-think. > I strongly recommend against > listing individual explicit cipher names. Later there will be > better key exchange algorithms, better hashes, ... Yeah I noticed you used just 'CHACHA20', which I guess is the group name? Or is that still just an abbreviated, explicit cipher name? I've been using the full/explicit cipher name so far because I havent found the right doc that lists the group name (CHACHA20) that includes it. > The best way to future-proof a non-default cipherlist is to use > preferences for particular features I do that already between internal machines. > and not hardcode specific individual ciphers. Even better, let the library > maintainers > construct a sensible cipherlist, and avoid being a crypto fashionista. > :-) Of course with paying cliets, they get what they ask and pay for if they > are not interested in advice on what to do. Yep. There's a bunch of clients in the customer chain. They all agreed on project standards long before I got invovled. We've got enough problems with the meat of the project without stirring their pot at this point on "just mail". > > > Google is presenting a certificate that > > > chains to a locally trusted CA. You must have configuned a non-empty > > > "smtp_tls_CAfile" or "smtp_tls_CApath". > I recommend an empty setting here. Tastes great, less filling. Ok. So if the docs say Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use ONLY the system-supplied default Certification Authority certificates. Specify "tls_append_default_CA = no" to prevent Postfix from appending the system-supplied default CAs and trusting third-party certificates. and I set smtp_tls_CApath = tls_append_default_CA = no Then it won't ONLY use sys default CA certs will PREVENT appending sys default CA certs won't TRUST (and/or use?) 3rd party certs So what exactly IS it gonna do?
Postscreen and reject_rhsbl
Hi,
I'm using postfix-3.1.4 on fedora. I've just noticed I've configured
both postscreen to use spamhaus and other RBLs as well as have
configured the reject_rhsbl_* options. Is this duplicative and
unnecessary?
I've posted what I think are the relevant pieces in hopes someone
could review and clarify.
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unlisted_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_rhsbl_reverse_client mykey.dbl.dq.spamhaus.net,
reject_rhsbl_sender mykey.dbl.dq.spamhaus.net,
reject_rhsbl_helo mykey.dbl.dq.spamhaus.net,
check_sender_access hash:/etc/postfix/check_backscatterer,
check_helo_access pcre:/etc/postfix/helo_checks.pcre,
check_helo_access hash:/etc/postfix/helo_checks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
check_policy_service unix:private/policy-spf,
check_policy_service inet:127.0.0.1:2501,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
permit
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/postfix/client_checks,
check_reverse_client_hostname_access
pcre:/etc/postfix/fqrdns-042715a.pcre,
check_reverse_client_hostname_access
pcre:/etc/postfix/reverse_client_hostname_access.pcre,
check_client_access cidr:/etc/postfix/client_access_blocklist
check_client_access cidr:/etc/postfix/ransomware-ipbl
postscreen_dnsbl_ttl = 10m
postscreen_access_list =
permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr,
cidr:/etc/postfix/gmail_whitelist.cidr,
cidr:/etc/postfix/postscreen_spf_whitelist.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:11}s
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_reply_map =
texthash:$config_directory/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites =
mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
score.senderscore.com=127.0.4.[0..19]*3
score.senderscore.com=127.0.4.[20..29]*3
score.senderscore.com=127.0.4.[30..49]*2
score.senderscore.com=127.0.4.[50..59]*1
score.senderscore.com=127.0.4.[60..69]*1
score.senderscore.com=127.0.4.[70..79]*-1
score.senderscore.com=127.0.4.[80..89]*-2
score.senderscore.com=127.0.4.[90..100]*-4
b.barracudacentral.org*7
mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4
bl.spamcop.net*4
bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
ubl.unsubscore.com=127.0.0.2*1
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
dnsbl.sorbs.net=127.0.0.[10;14]*8
dnsbl.sorbs.net=127.0.0.5*7
dnsbl.sorbs.net=127.0.0.7*4
dnsbl.sorbs.net=127.0.0.6*3
dnsbl.sorbs.net=127.0.0.[8;9]*2
dnsbl.sorbs.net=127.0.0.4*1
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 01, 2017 at 11:50:48AM -0700, robg...@nospammail.net wrote: > > the right way to do it is: > > tls_high_cipherlist = CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH > > tls_medium_cipherlist = > > CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH > > This leaves the existing aNULL ciphers first, then non-aNULL CHACHA, > > AES and CAMELLIA. Since Google does not do aNULL, the effect is still > > to use aNULL where available, and otherwise CHACHA20 first. > > I am having a time of it trying to wrap my head around that. > > I would interpret that order to mean CHACHA cipher first, BEFORE aNULL cipher. No, because the effect of "spec" is to pop all the ciphers matching "spec" (in their relative order) off the stack of enabled, but not selected ciphers and append them (maintaining relative order) to the list of selected ciphers. Then the effect of "-spec" is to pop all the ciphers matching "spec" (in their relative order) off stack of of selected ciphers and prepend them (in their relative order) to the stack of enabled ciphers. Therefore, after "CHACHA20:-CHACHA20" the CHACHA20 ciphers are at the top of the enabled+unselected cipher stack. And then after "aNULL:-aNULL" the "aNULL" ciphers are at the top of the stack. If there were aNULL+CHACHA20A ciphers, then those would be ahead of any non-CHACHA20 aNULL ciphers. But, since there are none at present, the effect is aNULL first, and CHACHA20 second and AES, CAMELLIA after. Within each group there is still a preference for kECDHE over kDHE over kRSA, and of course the whole lot later gets resorted by cipher bit strength, while maintaining relative order for ciphers of equal strength. I am assuming you are now wiser, in that you are now more aware of how much you don't yet know about cipherlists... :-) > So how DO you make sure that a specific cipher is ALWAYS used if it's > available? You list the preferred category first. I strongly recommend against listing individual explicit cipher names. Later there will be better key exchange algorithms, better hashes, ... The best way to future-proof a non-default cipherlist is to use preferences for particular features, and not hardcode specific individual ciphers. Even better, let the library maintainers construct a sensible cipherlist, and avoid being a crypto fashionista. :-) Of course with paying cliets, they get what they ask and pay for if they are not interested in advice on what to do. > > Google is presenting a certificate that > > chains to a locally trusted CA. You must have configuned a non-empty > > "smtp_tls_CAfile" or "smtp_tls_CApath". > > Yeah, here I have > > postconf smtp_tls_CApath > smtp_tls_CApath = /etc/ssl/certs/ > > > These are largely pointless unless you're actually doing WebPKI > > authentication. > > I set that because the docs say > > http://www.postfix.org/postconf.5.html#smtp_tls_CApath > Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use ONLY the > system-supplied default Certification Authority certificates. > > which sounds like good sense to me. I recommend an empty setting here. Tastes great, less filling. -- Viktor.
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Tue, Aug 1, 2017, at 10:55 AM, Viktor Dukhovni wrote: > listed first, pending any other directives that change the order. Ok, that 'pending others' part was what I wasn't getting. > > Well I have to tweak a bit anyway. I need to get ChaCha20 working. And > > I intend to know about it if only not to screw things up. > > That's an interesting use of "have to" that I'm not familiar with. :-) > https://xkcd.com/538/ > Frankly, I am surprised you feel compelled to prefer the still Tbh, I'm not sure why the 'frank surprise' etc. It's a client requirement for the project this is involved in. They audit, they specify, they pay. > OpenSSL 1.1.0 I assume, there's no CHACHA20 in OpenSSL 1.0.x IIRC yes > the right way to do it is: > tls_high_cipherlist = CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH > tls_medium_cipherlist = > CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH > This leaves the existing aNULL ciphers first, then non-aNULL CHACHA, > AES and CAMELLIA. Since Google does not do aNULL, the effect is still > to use aNULL where available, and otherwise CHACHA20 first. I am having a time of it trying to wrap my head around that. I would interpret that order to mean CHACHA cipher first, BEFORE aNULL cipher. So how DO you make sure that a specific cipher is ALWAYS used if it's available? > > I'm not authenticating to google as a user, just sending mail to it. So I > > thought that means I'd be 'ananoymous' to it. > > The log entry is showing whether Google's certificate is authenticating > it to your SMTP client. Google is presenting a certificate that > chains to a locally trusted CA. You must have configuned a non-empty > "smtp_tls_CAfile" or "smtp_tls_CApath". Yeah, here I have postconf smtp_tls_CApath smtp_tls_CApath = /etc/ssl/certs/ > These are largely pointless unless you're actually doing WebPKI > authentication. I set that because the docs say http://www.postfix.org/postconf.5.html#smtp_tls_CApath Specify "smtp_tls_CApath = /path/to/system_CA_directory" to use ONLY the system-supplied default Certification Authority certificates. which sounds like good sense to me. > > > So since I'm NOT authenting, and DO have "aNULL:-aNULL" in there why am > > I successfully using the ECDHE-ECDSA-CHACHA20-POLY1305 cipher? Shouldn't > > I HAVE to remove aNull support? > > Your server offers both aNULL (first) and non-aNULL (second) ciphers. > Google's servers don't enable aNULL, so you negotiate a ciphersuite > that employs (RSA) certificates, which you largely ignore, but you > do log that they could be authenticated if you cared to. More head-wrapping needed :-( > You're probably working too hard. Don't hear THAT often. > Perhaps it is just a matter of > trying to learn the technology, in which case, by all means, feel > free to experiment. > If you main goal was to just to get mail > delivered, with reasonable best-effort security, then the default > settings are the way to go. Nah. Just getting mail delivered, using defaults, was really straightfoward. Well it was once I sat down and read a big enough chunk of the docs and stopped paying attention to random online posts. > > Eventually I'll have to make this server mandatory TLS for in & outbound, > > and limit it to non-"Broken or Scary" ciphers. And to always prefer EC, > > strongest options first. > > Why? Because it's a real requirement. See above. > Are you aiming to receive email or look cool with the shiniest new crypto? :-) You have an interesting sense of humor. > (It not turn out to be more secure, though it does look promising). Sure. Thanks for the help. Rob
Re: Specify VPN for postfix
Since this is socks proxy and not vpn you could redirect postfix traffic with iptables to the port your socks proxy listens. Plenty examples on google. On Aug 1, 2017 19:23, "Yubin Ruan" wrote: > 2017-08-01 22:54 GMT+08:00 Tom Hendrikx : > > > > > > On 01-08-17 16:46, Wietse Venema wrote: > >> Yubin Ruan: > >>> Can anyone tell me how to point postfix to a VPN connection? I have > >>> setup a VPN listening at background on my Ubuntu and I want to point > >>> postfix to that listening port whenever postfix try to connect to the > >>> internet. > >> > >> Wietse: > >>> You specify > >>> /etc/postfix/main.cf: > >>> relayhost = smtp:[host on other side of tunnel] > >> > >> Gary Sellani: > >>> Could the host be something like 10.8.0.0/24? > >> > >> I wrote 'host' not 'network block'. > >> > >> Consider the network as a collection of layers. An example applicable > >> to Postfix looks like: physical layer (ethernet), network layer > >> (IP), transport layer (TCP), and application layer (SMTP). In this > >> architecture, an SMTP destination is a domain or host, where the > >> host may be specified as an IP address. It's not an IP address block > >> nor is it an ethernet broadast domain. > >> > >> Wietse > >> > > > > Maybe you (the OP) should clarify what you mean with 'connect to the > > internet'. Does this mean accepting email from hosts 'on the internet', > > does it mean sending email to random hosts 'on the internet', or does it > > mean something else? Explain in laymen terms what you're trying to do, > > your question is too vague. > > I have a shadowsocks client listening at 127.0.0.1:, and I want to > point postfix to that specified port when it try to connect to > internet. Put it in another words, I would like to make that address > (i.e., 127.0.0,1:) something like default gateway so that all my > network traffic go through it. > > Thanks, > Yubin >
Re: still use "aNULL:!aNULL:" in Postfix default cipherlists when tls policy is mandatory, == encrypt?
On Mon, Jul 31, 2017 at 03:19:29PM -0700, robg...@nospammail.net wrote: > > (Note that's "aNULL:-aNULL:..." not "aNULL:!aNULL:..."). > > Yeah noticed that. Not clear what the diff is yet, but sticking with the > "aNULL:-aNULL" for this. The difference is rather large. The OpenSSL cipherlist specification is a tiny and somewhat subtle programming language. The "!spec" form irrevocable disables the ciphers matching "spec". There's no way to bring "spec" back after that directive. While "-spec" removes "spec" from the working list, but the ciphers in question can be added back with later directives. The effect of: "spec:-spec" is to put the ciphers matching "spec" at the front of the list of not yet included ciphers. Thus "spec:-spec:ALL" ensures that the ciphers matching "spec" are listed first, pending any other directives that change the order. > > You're not expected to need to know about or tweak the cipherlists. > > Well I have to tweak a bit anyway. I need to get ChaCha20 working. And > I intend to know about it if only not to screw things up. That's an interesting use of "have to" that I'm not familiar with. :-) There's nothing sufficiently wrong with AES (which has hardware support on most modern CPUs) to warrant switching to CHACHA20 for SMTP, where the biggest of disclosure is not attacks on the crypto. https://xkcd.com/538/ > Unless I set the cipherlist manually to include the cipher, eg testing > > "aNULL:-aNULL:ECDHE-ECDSA-CHACHA20-POLY1305:HIGH:MEDIUM:@STRENGTH" > ^ If you want CHACHA20 to be preferred over AES (OpenSSL 1.1.0 I assume, there's no CHACHA20 in OpenSSL 1.0.x IIRC) then the right way to do it is: tls_high_cipherlist = CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH tls_medium_cipherlist = CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH This leaves the existing aNULL ciphers first, then non-aNULL CHACHA, AES and CAMELLIA. Since Google does not do aNULL, the effect is still to use aNULL where available, and otherwise CHACHA20 first. Frankly, I am surprised you feel compelled to prefer the still relatively new CHACHA20, which is likely slower than AES on your hardware, and could (though we hope not) turn out to be weaker than AES. It takes a long time to gain confidence in a symmetric cipher algorithm. > Jul 29 14:31:28 maryland postfix/mailout/smtp[6707]: Trusted TLS > connection established to gmail-smtp-in.l.google.com[74.125.28.26]:25: > TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) > > That log snip above is from a send TO someone at gmail FROM my server. > > I'm confused about the "Trusted TLS" bit. > > I'm not authenticating to google as a user, just sending mail to it. So I > thought that means I'd be 'ananoymous' to it. The log entry is showing whether Google's certificate is authenticating it to your SMTP client. Google is presenting a certificate that chains to a locally trusted CA. You must have configuned a non-empty "smtp_tls_CAfile" or "smtp_tls_CApath". These are largely pointless unless you're actually doing WebPKI authentication. > So since I'm NOT authenting, and DO have "aNULL:-aNULL" in there why am > I successfully using the ECDHE-ECDSA-CHACHA20-POLY1305 cipher? Shouldn't > I HAVE to remove aNull support? Your server offers both aNULL (first) and non-aNULL (second) ciphers. Google's servers don't enable aNULL, so you negotiate a ciphersuite that employs (RSA) certificates, which you largely ignore, but you do log that they could be authenticated if you cared to. > > It is somewhat unfortunate that to work around some quirks in Exchange 2003 > > (mostly gone now) I've had to post examples of pruned cipherlists that make > > TLS work against these crippled servers: > > > > smtp_tls_exclude_ciphers = ... > > Yeah, started looked at that too as part of the bunch of > > smtpd_tls_ciphers > smtpd_tls_mandatory_ciphers > smtpd_tls_exclude_ciphers > smtpd_tls_mandatory_exclude_ciphers > > smtp_tls_ciphers > smtp_tls_mandatory_ciphers > smtp_tls_exclude_ciphers > smtp_tls_mandatory_exclude_ciphers You're probably working too hard. Perhaps it is just a matter of trying to learn the technology, in which case, by all means, feel free to experiment. If you main goal was to just to get mail delivered, with reasonable best-effort security, then the default settings are the way to go. > If by 'subtle' you mean 'easily confused by', sign me up! > > Eventually I'll have to make this server mandatory TLS for in & outbound, > and limit it to non-"Broken or Scary" ciphers. And to always prefer EC, > strongest options first. Why? Are you aiming to receive email or look cool with the shiniest new crypto? :-) (It not turn out to be more secure, though it does look promising). > Figuring out what to 'tweak' in those options to get there and NOT shoot off > my own foot
Re: Specify VPN for postfix
You don't know local IP except that it will be in that block (cidr). In practice, my first VPN instance will use 10.8.0.6. I don't recall what is used when I run two VPNs. But I get your point. Original Message From: wie...@porcupine.org Sent: August 1, 2017 7:46 AM To: postfix-users@postfix.org Reply-to: postfix-users@postfix.org Subject: Re: Specify VPN for postfix Yubin Ruan: > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. Wietse: > You specify > /etc/postfix/main.cf: > relayhost = smtp:[host on other side of tunnel] Gary Sellani: > Could the host be something like 10.8.0.0/24? I wrote 'host' not 'network block'. Consider the network as a collection of layers. An example applicable to Postfix looks like: physical layer (ethernet), network layer (IP), transport layer (TCP), and application layer (SMTP). In this architecture, an SMTP destination is a domain or host, where the host may be specified as an IP address. It's not an IP address block nor is it an ethernet broadast domain. Wietse
Re: Specify VPN for postfix
2017-08-02 0:21 GMT+08:00 Yubin Ruan : > 2017-08-01 22:54 GMT+08:00 Tom Hendrikx : >> >> >> On 01-08-17 16:46, Wietse Venema wrote: >>> Yubin Ruan: Can anyone tell me how to point postfix to a VPN connection? I have setup a VPN listening at background on my Ubuntu and I want to point postfix to that listening port whenever postfix try to connect to the internet. >>> >>> Wietse: You specify /etc/postfix/main.cf: relayhost = smtp:[host on other side of tunnel] >>> >>> Gary Sellani: Could the host be something like 10.8.0.0/24? >>> >>> I wrote 'host' not 'network block'. >>> >>> Consider the network as a collection of layers. An example applicable >>> to Postfix looks like: physical layer (ethernet), network layer >>> (IP), transport layer (TCP), and application layer (SMTP). In this >>> architecture, an SMTP destination is a domain or host, where the >>> host may be specified as an IP address. It's not an IP address block >>> nor is it an ethernet broadast domain. >>> >>> Wietse >>> >> >> Maybe you (the OP) should clarify what you mean with 'connect to the >> internet'. Does this mean accepting email from hosts 'on the internet', >> does it mean sending email to random hosts 'on the internet', or does it >> mean something else? Explain in laymen terms what you're trying to do, >> your question is too vague. > > I have a shadowsocks client listening at 127.0.0.1:, and I want to > point postfix to that specified port when it try to connect to > internet. Put it in another words, I would like to make that address > (i.e., 127.0.0,1:) something like default gateway so that all my > network traffic go through it. Currently I can set up a proxy in the browser (i.e., pointing the browser to that address (127.0.0.1:)) so that I got a VPN kind of thing. And now I want to set it up for postfix, and if possible, for every program in the system. Thanks, Yubin
Re: Specify VPN for postfix
2017-08-01 22:54 GMT+08:00 Tom Hendrikx : > > > On 01-08-17 16:46, Wietse Venema wrote: >> Yubin Ruan: >>> Can anyone tell me how to point postfix to a VPN connection? I have >>> setup a VPN listening at background on my Ubuntu and I want to point >>> postfix to that listening port whenever postfix try to connect to the >>> internet. >> >> Wietse: >>> You specify >>> /etc/postfix/main.cf: >>> relayhost = smtp:[host on other side of tunnel] >> >> Gary Sellani: >>> Could the host be something like 10.8.0.0/24? >> >> I wrote 'host' not 'network block'. >> >> Consider the network as a collection of layers. An example applicable >> to Postfix looks like: physical layer (ethernet), network layer >> (IP), transport layer (TCP), and application layer (SMTP). In this >> architecture, an SMTP destination is a domain or host, where the >> host may be specified as an IP address. It's not an IP address block >> nor is it an ethernet broadast domain. >> >> Wietse >> > > Maybe you (the OP) should clarify what you mean with 'connect to the > internet'. Does this mean accepting email from hosts 'on the internet', > does it mean sending email to random hosts 'on the internet', or does it > mean something else? Explain in laymen terms what you're trying to do, > your question is too vague. I have a shadowsocks client listening at 127.0.0.1:, and I want to point postfix to that specified port when it try to connect to internet. Put it in another words, I would like to make that address (i.e., 127.0.0,1:) something like default gateway so that all my network traffic go through it. Thanks, Yubin
Re: Specify VPN for postfix
Gary Sellani skrev den 2017-08-01 14:31: Could the host be something like 10.8.0.0/24? make a hostname with multiple A//MX to do this one could simply add ip-addr to /etc/hosts with the hostname wanted for the lan of rfc1918 ips then change relayhost to relayhost = smtp::25 postfix will then use name-in-etc-hosts as a dns mx record relayhost = smtp:[host on other side of tunnel] with [] around hostname mx round robin is disabled this is ok and desired for single ip hostname # cat /etc/hosts 10.0.0.2 in.localdomain in 10.0.0.3 in.localdomain in or simple use splited dnsview on public dns better docs here: https://en.wikipedia.org/wiki/Split-horizon_DNS
Re: Specify VPN for postfix
On 01-08-17 16:46, Wietse Venema wrote: > Yubin Ruan: >> Can anyone tell me how to point postfix to a VPN connection? I have >> setup a VPN listening at background on my Ubuntu and I want to point >> postfix to that listening port whenever postfix try to connect to the >> internet. > > Wietse: >> You specify >> /etc/postfix/main.cf: >> relayhost = smtp:[host on other side of tunnel] > > Gary Sellani: >> Could the host be something like 10.8.0.0/24? > > I wrote 'host' not 'network block'. > > Consider the network as a collection of layers. An example applicable > to Postfix looks like: physical layer (ethernet), network layer > (IP), transport layer (TCP), and application layer (SMTP). In this > architecture, an SMTP destination is a domain or host, where the > host may be specified as an IP address. It's not an IP address block > nor is it an ethernet broadast domain. > > Wietse > Maybe you (the OP) should clarify what you mean with 'connect to the internet'. Does this mean accepting email from hosts 'on the internet', does it mean sending email to random hosts 'on the internet', or does it mean something else? Explain in laymen terms what you're trying to do, your question is too vague. Tom
Re: Specify VPN for postfix
Yubin Ruan: > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. Wietse: > You specify > /etc/postfix/main.cf: > relayhost = smtp:[host on other side of tunnel] Gary Sellani: > Could the host be something like 10.8.0.0/24? I wrote 'host' not 'network block'. Consider the network as a collection of layers. An example applicable to Postfix looks like: physical layer (ethernet), network layer (IP), transport layer (TCP), and application layer (SMTP). In this architecture, an SMTP destination is a domain or host, where the host may be specified as an IP address. It's not an IP address block nor is it an ethernet broadast domain. Wietse
Re: Specify VPN for postfix
Could the host be something like 10.8.0.0/24? Original Message From: wie...@porcupine.org Sent: August 1, 2017 4:01 AM To: postfix-users@postfix.org Reply-to: postfix-users@postfix.org Subject: Re: Specify VPN for postfix Yubin Ruan: > Hi, > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. You specify /etc/postfix/main.cf: relayhost = smtp:[host on other side of tunnel] Wietse
Re: Specify VPN for postfix
Yubin Ruan: > Hi, > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. You specify /etc/postfix/main.cf: relayhost = smtp:[host on other side of tunnel] Wietse
AW: Specify VPN for postfix
Easiest case if the default route for the postfix server points to the vpn tunnel. If def gw does not point to vpn then you could use nat rules on vpn server to replace the src address with the vpn servers vpn address. If NAT is not an option then you will have to setup a policy based routing aka source based routing on postfix server to ensure answers from postfix go back via the same gateway they came in. Cheers tobi - Originale Nachricht - Von: Yubin Ruan Gesendet: 01.08.2017 - 06:07 An: postfix-users@postfix.org Betreff: Specify VPN for postfix > Hi, > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. > > Thanks, > Yubin
Re: Specify VPN for postfix
Am 01.08.2017 um 06:07 schrieb Yubin Ruan: > Hi, > Can anyone tell me how to point postfix to a VPN connection? I have > setup a VPN listening at background on my Ubuntu and I want to point > postfix to that listening port whenever postfix try to connect to the > internet. Hi, read description of parameter "inet_interfaces" (http://www.postfix.org/postconf.5.html#inet_interfaces). That should help you finding the best way for you. Willi
