Re: can not telnet,can not send mail
Feel Zhou skrev den 2013-11-26 07:40: Hello, my friend +1 This is Tom I'm sending my greeting from China china is known for blocking port 25 :/ My postfix server can not telnet any other mail server, but other server can telnet my postfix server, so lots of mail in my queue, sadly you ask the incorrect people, ask your isp to have a solution, or try move to http://deployment.googleapps.com/ but I can not send it, what can I do now, depending of your isp, there is not much other ways to solve then hope thanks a lot. atleast you are not blocked using gmail, so i think you can turn over to google apps aswell with out any issues, but still ask your isp why its needed
Re: Rejecting emails based on domain blacklist
Mark Goodge: > Thanks. I'll have a play with that later. Another option is to blacklist a spammer's DNS server with check_client_ns_access or check_sender_ns_access. Wietse
Re: can not telnet,can not send mail
Hi On Tue, Nov 26, 2013 at 11:14:30AM +0100, Benny Pedersen wrote: > china is known for blocking port 25 :/ (...)> > depending of your isp, there is not much other ways to solve then hope You might want to try to relay all emails to your ISP mail server, by using the relayhost = [hostname_or_ip_for_the_isp_mail_server] If your ISP require authentication, you need to enable the smtp SASL auth for that host: smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/client_sasl where the client_sasl have: hostname_or_ip_for_the_isp_mail_serverusername:password (dont forget to postmap the /etc/postfix/client_sasl) good luck higuita
Re: can not telnet,can not send mail
higuita: > Hi > > On Tue, Nov 26, 2013 at 11:14:30AM +0100, Benny Pedersen wrote: > > china is known for blocking port 25 :/ > (...)> > > depending of your isp, there is not much other ways to solve then hope > > You might want to try to relay all emails to your ISP mail server, > by using the relayhost = [hostname_or_ip_for_the_isp_mail_server] And if their port 25 is blocked, too, try port 587 (submission): relayhost = [hostname_or_ip_for_the_isp_mail_server]:587 See higuita's comments below for authentication. See also: http://www.postfix.org/SOHO_README.html#client_sasl_enable Wietse > If your ISP require authentication, you need to enable the smtp SASL > auth for that host: > > smtp_sasl_auth_enable = yes > smtp_sasl_password_maps = hash:/etc/postfix/client_sasl > > > where the client_sasl have: > > hostname_or_ip_for_the_isp_mail_serverusername:password > > > (dont forget to postmap the /etc/postfix/client_sasl) > > good luck > higuita >
Re: can not telnet,can not send mail
Thanks for all May be my isp provider blocked outbound connections to port 25/tcp, I ask them to fix this problem, and it's working now, I want to send mail via port 587 when it happens again, Thanks again TOM 2013/11/26 Wietse Venema > higuita: > > Hi > > > > On Tue, Nov 26, 2013 at 11:14:30AM +0100, Benny Pedersen wrote: > > > china is known for blocking port 25 :/ > > (...)> > > > depending of your isp, there is not much other ways to solve then hope > > > > You might want to try to relay all emails to your ISP mail server, > > by using the relayhost = [hostname_or_ip_for_the_isp_mail_server] > > And if their port 25 is blocked, too, try port 587 (submission): > > relayhost = [hostname_or_ip_for_the_isp_mail_server]:587 > > See higuita's comments below for authentication. > > See also: http://www.postfix.org/SOHO_README.html#client_sasl_enable > > Wietse > > > If your ISP require authentication, you need to enable the smtp > SASL > > auth for that host: > > > > smtp_sasl_auth_enable = yes > > smtp_sasl_password_maps = hash:/etc/postfix/client_sasl > > > > > > where the client_sasl have: > > > > hostname_or_ip_for_the_isp_mail_serverusername:password > > > > > > (dont forget to postmap the /etc/postfix/client_sasl) > > > > good luck > > higuita > > >
Re: postprox per recipient
Hi Wietse, all, I may see your point. Although postprox itself is an SMTP proxy, the script I'm forwarding its stdin to does nothing to acknowledge the SMTP protocol of the incoming data. Would that be the correct interpretation of your answer? Ian On Sat, Nov 23, 2013 at 10:09 PM, Wietse Venema wrote: > Ian Baldwin: > > localhost:10027 inet n n n - - spawn > > user=vscan argv=/usr/local/sbin/postprox -v -c > ... > > Nov 24 07:01:13 aminoacid postfix/smtp[21274]: 80F96303AE7: > > to=, relay=127.0.0.1[127.0.0.1]:10027, delay=303, > > delays=1.9/0.02/301/0, dsn=5.5.0, status=bounced (host > 127.0.0.1[127.0.0.1] > > said: 354 End data with . (in reply to MAIL FROM > command)) > > You need a program that implements SMTP. The above program does not. > > Wietse >
Re: postprox per recipient
Ian Baldwin: > Nov 24 07:01:13 aminoacid postfix/smtp[21274]: 80F96303AE7: > to=, relay=127.0.0.1[127.0.0.1]:10027, delay=303, > delays=1.9/0.02/301/0, dsn=5.5.0, status=bounced (host > 127.0.0.1[127.0.0.1] said: 354 End data with . (in > reply to MAIL FROM command)) Wietse: > You need a program that implements SMTP. The above program does not. Ian Baldwin: > I may see your point. Although postprox itself is an SMTP proxy, the script > I'm forwarding its stdin to does nothing to acknowledge the SMTP protocol > of the incoming data. Would that be the correct interpretation of your > answer? The Postfix SMTP client sends the "MAIL FROM" command, and the remote SMTP server replies with 354. That is not valid according to the SMTP protocol. This a problem with the remote SMTP server. You can try if this eliminates the problem: /etc/postfix/main.cf: smtp_discard_ehlo_keywords = pipelining If that helps, then smtpprox has a problem in their implementation of SMTP command pipelining. Wietse
Re: postfix reports no rDNS on a host with many PTR records
Blake Hudson wrote the following on 10/18/2013 4:40 PM: Leonardo Rodrigues wrote the following on 10/17/2013 2:04 PM: Em 17/10/13 15:09, Blake Hudson escreveu: Based on your suggestion, I did find the following bug report for glibc from 2008 (that looks like Wietse had an indirect hand in): http://sourceware.org/bugzilla/show_bug.cgi?id=5790 It appears that the issue was resolved in glibc due to Leonardo's diligence. Unfortunately, although the issue was reported to RH via their Fedora bugzilla it doesn't appear RH ever took any action. Based on my results, I don't believe RH ever backported this fix to any version of RHEL. I'm not too worried about it since we've migrated most of our servers to RHEL 6 and the issue is resolved in the version of glibc used in there. However, I will see if I can file a bug report and have RHEL take action to prevent others from running into the same issue. Thank you for your and Weitse's comments and suggestions which helped confirm where this issue was so I can address the problem directly and mitigate any additional customer impact. i was about to reply that i had similar problems some years ago ... just have, at this exact moment, the URL on my clipboard for pasting :) i'm the Leonardo that filed that bug report ... Thanks Leonardo. In fact, I remembered your issue (or one similar to it), but not with enough clarity to lead me to the exact problem without some additional help. I went ahead and filed a bug against RHEL 5 through RedHat's bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1020486). I received a response within 24 hours that RH will "... consider this bug while we scope issues to fix for the next release.". I'm guessing that means that in RHEL 5.10 there's a slim chance this issue might be resolved. Perhaps we will save someone else from wasting time with the same issue. Thanks for your diligence investigating and reporting this issue to RH and the glibc guys. --Blake Looks like we missed the RHEL 5.10 deadline, but should have this fixed in RHEL 5.11 based on the following bugzilla comment: Jeff Law 2013-11-26 11:36:54 EST Just an FYI from the planning call. This will be ack'd by PM and is expected to be within QE capacity for RHEL 5.11.
reject_unknown_sender_domain rejects from domain with unusual PTR record
I see the following syslog entries for a message from the local public library system when I have reject_unknown_sender_domain in smtpd_recipient_restrictions: Nov 25 14:06:23 gob postfix/smtpd[19293]: connect from unknown[12.229.68.221] Nov 25 14:06:23 gob postfix/smtpd[19293]: warning: 221.68.229.12.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=221.68.229.12.zen.spamhaus.org type=A: Host not found, try again Nov 25 14:06:23 gob postfix/smtpd[19293]: NOQUEUE: reject: RCPT from unknown[12.229.68.221]: 450 4.1.8 : Sender address rejected: Domain not found; from= to=<[REDACTED]@ BERGMANS.US> proto=ESMTP helo= Nov 25 14:06:23 gob postfix/smtpd[19293]: disconnect from unknown[12.229.68.221] Their A and MX records for the sending domain and the A record for the host in HELO look typical and sane to me, but they have a setup for "reverse" DNS I don't believe I've seen before: $ dig -x 12.229.68.221 ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -x 12.229.68.221 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19095 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;221.68.229.12.in-addr.arpa.IN PTR ;; ANSWER SECTION: 221.68.229.12.in-addr.arpa. 85298 INCNAME 221.128/25.68.229.12.in-addr.arpa. 221.128/25.68.229.12.in-addr.arpa. 9698 IN PTR sangria.lcplin.org. ;; AUTHORITY SECTION: 128/25.68.229.12.in-addr.arpa. 85298 IN NS donuts1.lcplin.org. ;; ADDITIONAL SECTION: donuts1.lcplin.org. 85214 IN A 12.229.68.200 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Nov 26 19:21:26 2013 ;; MSG SIZE rcvd: 139 So my questions are: 1. Is this actually what's causing the rejection? 2. If the answer to (1) is yes, then is this a Postfix bug or a feature? I'm happy to write the administrators of lcplin.org and ask them to fix their zone, but I can't really cite chapter and verse as to why it's wrong. In fact, I'm not convinced it is. Best, -- Lucas
Re: reject_unknown_sender_domain rejects from domain with unusual PTR record
Lucas Bergman: > Nov 25 14:06:23 gob postfix/smtpd[19293]: NOQUEUE: reject: RCPT from > unknown[12.229.68.221]: 450 4.1.8 : Sender address > rejected: Domain not found; from= to=<[REDACTED]@ > BERGMANS.US> proto=ESMTP helo= 450 Means that Postfix did not receive a DNS reply. There could have been a network outage, or your link was saturated, or whatever. Wietse
Re: reject_unknown_sender_domain rejects from domain with unusual PTR record
On Tue, Nov 26, 2013 at 03:54:57PM -0500, Wietse Venema wrote: > Lucas Bergman: > > > Nov 25 14:06:23 gob postfix/smtpd[19293]: NOQUEUE: reject: RCPT from > > unknown[12.229.68.221]: 450 4.1.8 : Sender address > > rejected: Domain not found; from= to=<[REDACTED]@ > > BERGMANS.US> proto=ESMTP helo= > > 450 Means that Postfix did not receive a DNS reply. There could > have been a network outage, or your link was saturated, or whatever. And in any case PTR lookups have nothing to do with reject_unknown_sender_domain. The lookups in question are basically: $ dig +short -t mx lcplin.org 20 grid2i.seg.att.com. 10 grid1i.seg.att.com. $ dig +noall +ans -t a grid1i.seg.att.com. grid1i.seg.att.com. 28800 IN A 209.65.160.81 grid1i.seg.att.com. 28800 IN A 209.65.160.73 $ dig +noall +ans -t a grid2i.seg.att.com. grid2i.seg.att.com. 28800 IN A 209.65.160.89 grid2i.seg.att.com. 28800 IN A 209.65.176.73 grid2i.seg.att.com. 28800 IN A 209.65.176.81 Either the MX lookup or the A record lookups tempfailed. -- Viktor.
Re: reject_unknown_sender_domain rejects from domain with unusual PTR record
Viktor Dukhovni: > On Tue, Nov 26, 2013 at 03:54:57PM -0500, Wietse Venema wrote: > > > Lucas Bergman: > > > > > Nov 25 14:06:23 gob postfix/smtpd[19293]: NOQUEUE: reject: RCPT from > > > unknown[12.229.68.221]: 450 4.1.8 : Sender address > > > rejected: Domain not found; from= to=<[REDACTED]@ > > > BERGMANS.US> proto=ESMTP helo= > > > > 450 Means that Postfix did not receive a DNS reply. There could > > have been a network outage, or your link was saturated, or whatever. > > And in any case PTR lookups have nothing to do with > reject_unknown_sender_domain. The lookups in question are basically: > > $ dig +short -t mx lcplin.org > 20 grid2i.seg.att.com. > 10 grid1i.seg.att.com. > > $ dig +noall +ans -t a grid1i.seg.att.com. > grid1i.seg.att.com. 28800 IN A 209.65.160.81 > grid1i.seg.att.com. 28800 IN A 209.65.160.73 > > $ dig +noall +ans -t a grid2i.seg.att.com. > grid2i.seg.att.com. 28800 IN A 209.65.160.89 > grid2i.seg.att.com. 28800 IN A 209.65.176.73 > grid2i.seg.att.com. 28800 IN A 209.65.176.81 > > Either the MX lookup or the A record lookups tempfailed. IIRC Postfix looks up lcplin.org MX, and if that is not found, it looks up lcplin.org A or lcplin.org (the latter only when the DNS library routines understand lookups). This is the lighter extreme of the testing spectrum. The heavy extreme would involve connecting to the server(s) and confirming that they provide SMTP service for the sender address. That extreme is implemented with sender address verification. Wietse
lost connection error, need help debugging
Hi, I'm trying to figure out why the remote server is responding with a "lost connection" error without any further information to indicate why the message was deferred. If I use telnet and replicate the connection process, I can send a test message. However, messages sent from remote users and forwarded through our server via a .forward file to this remote user's account are deferred with a simple "lost connection" response. How can I get further information as to what the cause may be? Does the below debug help? It appears that it's being deferred immediately after the MAIL FROM, as this debug seems to indicate? Could the TLS error below be the cause? I believe that is a separate issue I have to address, and otherwise seems fine with other servers. smtp_stream_setup: maxtime=300 enable_deadline=0 > mail.sagebiz.com[66.252.104.194]:25: EHLO email.example.com vstream_fflush_some: fd 15 flush 39 vstream_buf_get_ready: fd 15 got 201 < mail.sagebiz.com[66.252.104.194]:25: 250-sagebiz.com < mail.sagebiz.com[66.252.104.194]:25: 250-SIZE 3000 < mail.sagebiz.com[66.252.104.194]:25: 250-ETRN < mail.sagebiz.com[66.252.104.194]:25: 250-ENHANCEDSTATUSCODES < mail.sagebiz.com[66.252.104.194]:25: 250-X-IMS 3 63253 < mail.sagebiz.com[66.252.104.194]:25: 250-DSN < mail.sagebiz.com[66.252.104.194]:25: 250-VRFY < mail.sagebiz.com[66.252.104.194]:25: 250-AUTH LOGIN NTLM SCRAM-MD5 CRAM-MD5 < mail.sagebiz.com[66.252.104.194]:25: 250-AUTH=LOGIN < mail.sagebiz.com[66.252.104.194]:25: 250-X-AVU 1385496485 < mail.sagebiz.com[66.252.104.194]:25: 250 8BITMIME server features: 0x900b size 3000 smtp_stream_setup: maxtime=300 enable_deadline=0 > mail.sagebiz.com[66.252.104.194]:25: MAIL FROM: > SIZE=47452 smtp_stream_setup: maxtime=300 enable_deadline=0 vstream_fflush_some: fd 15 flush 57 warning: TLS library problem: 16575:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: smtp_get: EOF connect to subsystem private/defer send attr nrequest = 0 send attr flags = 0 send attr queue_id = 1A8AB4055E send attr original_recipient = 39...@example.com send attr recipient = sangel...@denhallinn.com send attr offset = 430 send attr dsn_orig_rcpt = rfc822;39...@example.com send attr notify_flags = 0 send attr status = 4.4.2 send attr diag_type = send attr diag_text = send attr mta_type = send attr mta_mname = send attr action = delayed send attr reason = lost connection with mail.sagebiz.com[66.252.104.194] while sending MAIL FROM vstream_fflush_some: fd 16 flush 356 vstream_buf_get_ready: fd 16 got 10 I've also included the successful telnet test: $ telnet mail.sagebiz.com 25 Trying 66.252.104.194... Connected to mail.sagebiz.com. Escape character is '^]'. 220 mail.sagebiz.com MailSite ESMTP Receiver Version 9.5.4.12 Ready ehlo mail.example.com 250-sagebiz.com 250-SIZE 3000 250-ETRN 250-ENHANCEDSTATUSCODES 250-X-IMS 3 63253 250-DSN 250-VRFY 250-AUTH LOGIN NTLM SCRAM-MD5 CRAM-MD5 250-AUTH=LOGIN 250-X-AVU 1385496485 250-STARTTLS 250 8BITMIME mail from: 250 2.0.0 OK rcpt to:sangel...@denhallinn.com 250 2.0.0 OK quit 221 2.0.0 mail.sagebiz.com closing Connection closed by foreign host. Thanks, Alex
Re: lost connection error, need help debugging
Buried under useless verbose logging is a clear warning: > warning: TLS library problem: 16575:error:1408F10B:SSL > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: smtp_get: This means that the TLS library had a problem. > I've also included the successful telnet test: telnet is not valid, since you are using TLS. To debug SMTP over TLS, use "openssl s_client". Wietse
Re: lost connection error, need help debugging
On Tue, Nov 26, 2013 at 05:53:05PM -0500, Wietse Venema wrote: > Buried under useless verbose logging is a clear warning: > > > warning: TLS library problem: 16575:error:1408F10B:SSL > > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: smtp_get: > > This means that the TLS library had a problem. Plus the server is an Microsoft Exchange server, and the problem happens on the first command after the post STARTLS EHLO. > > I've also included the successful telnet test: > > telnet is not valid, since you are using TLS. > > To debug SMTP over TLS, use "openssl s_client". No need. This is the problem with Exchange on Windows 2003, and the broken DES-CBC3-SHA ciphersuite. Work-around in the list archives. -- Viktor.
Re: lost connection error, need help debugging
On Tue, Nov 26, 2013 at 11:05:48PM +, Viktor Dukhovni wrote: > > To debug SMTP over TLS, use "openssl s_client". > > No need. This is the problem with Exchange on Windows 2003, and > the broken DES-CBC3-SHA ciphersuite. Work-around in the list > archives. $ posttls-finger -c -lmay -Lsummary -o tls_medium_cipherlist=DES-CBC3-SHA "[66.252.104.194]" posttls-finger: Connected to 66.252.104.194[66.252.104.194]:25 posttls-finger: Untrusted TLS connection established to 66.252.104.194[66.252.104.194]:25: unknown with cipher DES-CBC3-SHA (168/168 bits) posttls-finger: warning: TLS library problem: 1748:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:/home/builds/ab/HEAD/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:339: posttls-finger: warning: lost connection while sending QUIT command Similar problem will happen any time OpenSSL fails to send either RC4-SHA or RC4-MD5 as the first 64 cipher-suites offered by the client. This is the default with OpenSSL 1.0.1, since additional ciphers with TLSv1.2 push RC4 further down the list. Web browsers apparently perform a fallback to SSLv3 (a built-in downgrade attack if you like), when TLS handshakes fail. Postfix falls back to plain-text when STARTTLS or the SSL handshake fails, but here, the failure is triggered by garbage after the encrypted EHLO response, which breaks the SSL records containing MAIL FROM:. We don't fallback to plaintext after the mail transaction begins. Perhaps the simplest work-around is to disable 3DES. Generally, servers other than Microsoft Exhange 2003 support AES. And with Microsoft Exchage 2003, disabling 3DES means that either we get RC4 (and succeed) or get no common ciphers and fail early (during the handshake), and thus fallback to plaintext. So we could set a default value of "smtp_tls_exclude_ciphers = 3DES". This won't solve the problem for people who configure explicit "encrypt" or "secure" policy with such servers as targets, but they are already doing a manual setup and can easily implement the more complex work-around from the list archive. -- Viktor.
Re: lost connection error, need help debugging
On Tue, Nov 26, 2013 at 11:05:48PM +, Viktor Dukhovni wrote: > > This means that the TLS library had a problem. > > Plus the server is an Microsoft Exchange server, and the problem > happens on the first command after the post STARTLS EHLO. One last comment, the mail server in question does run on Windows, but it is not Microsoft Exchange, rather it is: 220 mail.sagebiz.com MailSite ESMTP Receiver Version 9.5.4.12 Ready The underlying issue with CBC padding is therefore not Exchange-specific, it is either in Windows 2003 SSPI, or in some library on top of SSPI shared by MailSite and Exchange. With RC4-SHA and RC4-MD5 the ciphertext length exceeds the plaintext length by a fixed number of bytes. With DES-CBC3-SHA the ciphertext length exceeds the plaintext length by a variable number of bytes, but both Exchange and MailSite send the packets whose length is plaintext + maximum possible overhead, thus emitting random trailing data from the stack or heap after the first application data record. The servers in question should be removed from active Internet-facing duty. Their software stack is too ancient. -- Viktor.
how to make postfix alter the "From" header on outbound messages to mat IP
So here's the problem: An unusual server rejects mail on the basis that the domain portion of the FROM address in the header does not match the IP address of the server. So I need to compose a message like this: From: anything@ To: ... Subject: ... and I need postfix to replace the with whatever my external IP address is at the moment. Can postfix handle this?
Re: how to make postfix alter the "From" header on outbound messages to mat IP
l...@airstreamcomm.net: > So here's the problem: > > An unusual server rejects mail on the basis that the domain portion > of the FROM address in the header does not match the IP address of > the server. > > So I need to compose a message like this: > > From: anything@ > To: ... > Subject: ... > > and I need postfix to replace the with whatever > my external IP address is at the moment. > > Can postfix handle this? Yes. But, are you sure the problem is the mail header and not the MAIL FROM command? Wietse
Advanced master.cf query/update support
I recently picked up work on the postconf command that I suspended
in January this year. It's probably best to just give a few examples.
First, a word about notation. I wanted to describe master.cf
properties with a kind of pathname notation. The original idea was
to have things like servicename.servicetype.whatever but that turned
out to be problematic. Services can have '.' in their name, and
therefore, the '.' can also appear in service-defined parameters.
So I switched to servicename/servicetype/whatever. The result will
be released as a non-production snapshot because the code still
needs to be burned in (looking for feedback on the user interface).
Expected release is Wedneday.
The first example shows the smtp/inet service in the traditional
form:
$ postconf -M smtp/inet
smtp inet n - n - - smtpd
[note to self: add an option to replace '-' with default values]
Without the smtp/inet the above command would enumerate all services
and that would be too much output ("postconf -M smtp" would list
all services called "smtp", that's smtp/inet and smtp/unix).
The postconf command can now enumerate the fields as follows:
$ postconf -F smtp/inet
smtp/inet/service = smtp
smtp/inet/type = inet
smtp/inet/private = n
smtp/inet/unprivileged = -
smtp/inet/chroot = n
smtp/inet/wakeup = -
smtp/inet/process_limit = -
smtp/inet/command = smtpd
This form makes it very easy to change one field in master.cf.
For example to turn on chroot for the smtp/inet service you use:
$ postconf -F smtp/inet/chroot=y
Moreover, you can specify "*" for service name, service type or
field as a wild-card match. For example, to turn off chroot on
all Postfix daemons, use this:
$ postconf -F '*/*/chroot=n'
For a second example, let's look at the submission service. This
service typically has multple "-o parameter=value" overrides.
The postconf command can enumerate these parameters as follows:
$ postconf -P submission
submission/inet/milter_macro_daemon_name = ORIGINATING
submission/inet/smtpd_client_restrictions = $mua_client_restrictions
submission/inet/smtpd_helo_restrictions = $mua_helo_restrictions
submission/inet/smtpd_recipient_restrictions =
permit_sasl_authenticated,reject
submission/inet/smtpd_reject_unlisted_recipient = no
submission/inet/smtpd_sasl_auth_enable = yes
submission/inet/smtpd_sender_restrictions = $mua_sender_restrictions
submission/inet/smtpd_tls_security_level = encrypt
submission/inet/syslog_name = postfix/submission
Again, this form makes it very easy to modify one parameter
setting, for example to change the smtpd_tls_security_level setting for
the submission/inet service:
$ postconf -P 'submission/inet/smtpd_tls_security_level=may'
You can also a new parametername=parametervalue setting:
$ postconf -P 'submission/inet/parametername=parametervalue'
To get a quick report of all parameter overrides in master.cf:
$ postconf -P
This can produce a lot of output so no example is provided here.
Wietse
Re: lost connection error, need help debugging
Hi, > $ posttls-finger -c -lmay -Lsummary -o tls_medium_cipherlist=DES-CBC3-SHA > "[66.252.104.194]" > posttls-finger: Connected to 66.252.104.194[66.252.104.194]:25 > posttls-finger: Untrusted TLS connection established to > 66.252.104.194[66.252.104.194]:25: unknown with cipher DES-CBC3-SHA (168/168 > bits) > posttls-finger: warning: TLS library problem: 1748:error:1408F10B:SSL > routines:SSL3_GET_RECORD:wrong version > number:/home/builds/ab/HEAD/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:339: > posttls-finger: warning: lost connection while sending QUIT command I've just downloaded this and compiled it on my system, but it says invalid options: # posttls-finger -c -lmay -Lsummary -o tls_medium_cipherlist=DES-CBC3-SHA "[66.252.104.194]" posttls-finger: invalid option -- 'l' The -L is also not available: # posttls-finger usage: posttls-finger [-acStTv] [-h host_lookup] [-o name=value] destination > Postfix falls back to plain-text when STARTTLS or the SSL handshake > fails, but here, the failure is triggered by garbage after the > encrypted EHLO response, which breaks the SSL records containing > MAIL FROM:. We don't fallback to plaintext after the mail transaction > begins. Just to be sure I understand, you're saying that because 3DES had begun then failed, the connection is just closed, correct? > Perhaps the simplest work-around is to disable 3DES. Generally, > servers other than Microsoft Exhange 2003 support AES. And with > Microsoft Exchage 2003, disabling 3DES means that either we get > RC4 (and succeed) or get no common ciphers and fail early (during > the handshake), and thus fallback to plaintext. I've now done this, and it worked. I looked at my debug trace of the messages delivered successfully, and it didn't indicate what cipher was used. Is there a specific debug option available to determine this for the next time? > So we could set a default value of "smtp_tls_exclude_ciphers = 3DES". Is it possible to disable it just for this peer? Or is it okay to disable 3DES permanently system-wide? Thank you for all that you do. Alex
Re: lost connection error, need help debugging
On Tue, Nov 26, 2013 at 08:53:32PM -0500, Alex wrote: > > posttls-finger: warning: lost connection while sending QUIT command > > I've just downloaded this and compiled it on my system, but it says > invalid options: You have to compile *with* TLS support enabled. make -f Makefile.init CCARGS='-DUSE_TLS' AUXLIBS='-lssl -lcrypto' > Just to be sure I understand, you're saying that because 3DES had > begun then failed, the connection is just closed, correct? Yes. > I've now done this, and it worked. Good. This was expected, but unexpected things can also happen. > I looked at my debug trace of the messages delivered successfully, and > it didn't indicate what cipher was used. Is there a specific debug > option available to determine this for the next time? With 3DES disabled, no cipher is negotiated, the TLS handshake fails, and Postfix delivers the message in the clear. > > So we could set a default value of "smtp_tls_exclude_ciphers = 3DES". > > Is it possible to disable it just for this peer? Or is it okay to > disable 3DES permanently system-wide? Yes, you can play whack-a-mole disabling it one server at a time, but I would suggest disabling it globally. -- Viktor.
Re: reject_unknown_sender_domain rejects from domain with unusual PTR record
Just to close out this thread: On Tue, Nov 26, 2013 at 2:54 PM, Wietse Venema wrote: > Lucas Bergman: > > Nov 25 14:06:23 gob postfix/smtpd[19293]: NOQUEUE: reject: RCPT from > > unknown[12.229.68.221]: 450 4.1.8 : Sender address > > rejected: Domain not found; from= to=<[REDACTED]@ > > BERGMANS.US> proto=ESMTP helo= > > 450 Means that Postfix did not receive a DNS reply. There could > have been a network outage, or your link was saturated, or whatever. I was skeptical, because I saw many rejections of the same type while service on the host was otherwise fine. I looked in my BIND logs, and found that lcplin.org lookups in particular were failing for about a day with some inscrutable (to me) DNSSEC issue. They eventually got themselves sorted, and messages are good again. In my defense, their getting their zone sorted was contemporaneous with me changing Postfix settings. Thanks for the education, and sorry about the noise. -- Lucas
Re: lost connection error, need help debugging
Hi, > You have to compile *with* TLS support enabled. > > make -f Makefile.init CCARGS='-DUSE_TLS' AUXLIBS='-lssl -lcrypto' Okay, got it to work now. Apparently it wasn't included with my fedora postfix install. >> I looked at my debug trace of the messages delivered successfully, and >> it didn't indicate what cipher was used. Is there a specific debug >> option available to determine this for the next time? > > With 3DES disabled, no cipher is negotiated, the TLS handshake > fails, and Postfix delivers the message in the clear. Just to be sure, you mean TLS is now disabled only to these defective servers because of the faulty 3DES implementation, correct? >> Is it possible to disable it just for this peer? Or is it okay to >> disable 3DES permanently system-wide? > > Yes, you can play whack-a-mole disabling it one server at a time, > but I would suggest disabling it globally. So it will now most likely use RC4 as the next cipher, correct? Thanks, Alex
Re: lost connection error, need help debugging
On Tue, Nov 26, 2013 at 09:37:13PM -0500, Alex wrote: > > You have to compile *with* TLS support enabled. > > > > make -f Makefile.init CCARGS='-DUSE_TLS' AUXLIBS='-lssl -lcrypto' > > Okay, got it to work now. Apparently it wasn't included with my fedora > postfix install. Not surprising, posttls-finger(1) is only available with Postfix 2.11 snapshots. And so far, Wietse is not planning to add this utility to the list of command utilities that are installed by default. So to use it, you have to build it from source like you did. > > With 3DES disabled, no cipher is negotiated, the TLS handshake > > fails, and Postfix delivers the message in the clear. > > Just to be sure, you mean TLS is now disabled only to these defective > servers because of the faulty 3DES implementation, correct? Yes, just to the defective servers. > > Yes, you can play whack-a-mole disabling it one server at a time, > > but I would suggest disabling it globally. > > So it will now most likely use RC4 as the next cipher, correct? No, TLS will fail to the defective servers, but this will be during the handshake, so Postfix will fallback to plaintext. If you must encrypt traffic to these servers, you need per-destination policy. Search the archives for details posted in the last month or so. -- Vikor.
