Server Setup - Multiple Questions

Ruler2112 · 06-05-2008, 05:36 PM

OK, I fixed the problem on startup. Turns out that if I have root set up to use bash as the default shell, it throws this error up. Using csh eliminated the problem and PPP now autonegotiates the connection on boot. However, things still are not right; the change route failed messages continue, as do the strange connectivity issues. I can still get out from the box to the internet without a problem, but going in is another story. Still trying to figure things out on my own and would appreciate advice - I'm frankly out of my league when it comes to this advanced networking stuff... I'll take coding any day.

Ruler2112 · 06-12-2008, 01:38 PM

OK, I was able to fix the PPPoE problem. (Don't as how, as I'm not really sure - it works now though.) Three other problems related to the PPPoE connection not being completely set up at boot time were fixed as well. I have one last mail-related problem to overcome.

I have two ports set up to send mail - the standard port 25 and a high port intended for users whose home ISPs block port 25. Sending mail using this high port works fine. However, I cannot get port 25 to use TLS. Every time I try, I get a message that the server didn't issue STARTTLS in it's EHLO response. I've been going through main.cf and master.cf and really don't see where it differentiates between the two. (To get the high port working, I simply added a service to /etc/services called smtp2 and duplicated the smtp line in master.cf, changing the smtp to smtp2. BAM - the high port was able to be used to send mail the same as port 25.)

The frustrating part is that I *had* this working before and (obviously erroneously) don't think I did anything to break it. Any ideas?

billymayday · 06-12-2008, 04:22 PM

Can you post postconf -n and the relevant bits from master.cf?

Ruler2112 · 06-13-2008, 11:27 AM

Here you go- postconf -n with the first word of my domains replaced with ****.

Code:

broken_sasl_auth_clients = no
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:127.0.0.1:10024
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 10
home_mailbox = Maildir/
html_directory = no
local_destination_concurrency_limit = 2
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 20000000
mydestination = ****sales.com, ****service.com, ****collision.com, ****admin.com, ****bodyshop.com, ****parts.com localhost
mydomain = ****sales.com
mynetworks = 127.0.0.1/32
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/local/bin/newaliases
readme_directory = no
relay_domains = ****sales.com, ****service.com, ****collision.com, ****admin.com, ****bodyshop.com, ****parts.com, 127.0.0.1, localhost
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_key_file = /etc/postfix/key.pem
smtp_tls_note_starttls_offer = yes
smtp_use_tls = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,  check_helo_access hash:/etc/postfix/helo_access,  reject_invalid_hostname,  permit
smtpd_recipient_restrictions = reject_unauth_pipelining,  reject_non_fqdn_recipient,  reject_unknown_recipient_domain,  permit_mynetworks,  permit_sasl_authenticated,  reject_invalid_hostname,  reject_non_fqdn_hostname,  reject_non_fqdn_sender,  reject_unknown_sender_domain,  reject_unauth_destination,  reject_rbl_client zen.spamhaus.org,  check_policy_service inet:127.0.0.1:10023,  permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks,  permit_sasl_authenticated,  reject_non_fqdn_sender,  reject_unknown_sender_domain,  permit
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_loglevel = 0
smtpd_tls_received_header = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_client_reject_code = 450
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550

And all the lines of master.cf with smtp in the first column...

Code:

smtp      inet  n       -       n       -       -       smtpd
smtp2     inet  n       -       n       -       -       smtpd
smtp      unix  -       -       n       -       -       smtp
smtp-amavis unix -      -       y       -       2       smtp
  -o smtp_data_done_timeout=1200
  -o disable_dns_lookups=yes

billymayday · 06-13-2008, 02:57 PM

I'll have a more detailed look later, but initial thoughts

Why the duplication in, for example, smtp_tls_cert_file?

Try setting smtpd_tls_loglevel = 2 (1 may be enough) and see what's happening when the client attaches

Ruler2112 · 06-18-2008, 02:56 PM

I tried increasing the log level as you suggested, but to no avail - nothing is shown in /var/log/maillog when a client is unable to connect via port 25.

The duplication that you refer to really isn't. The smtpd_tls_key_file and smtp_tls_key_file do two different things according to the docs. The smtpd_ line enables encryption on connections coming into the SMTP server while the smtp_ line enables encryption on mail being sent to other mail servers as long as they support encryption.

I've gone through the configuration so many times I'm starting to get dizzy. I don't see where there would be any difference between the two SMTP ports... sockstat -4 shows that both ports are being listened to by master started by root. If I comment out the smtp2 line in master.cf, I still cannot send on port 25 using TLS.

The exact error that Mozilla Thunderbird produces when trying to send mail using TLS on port 25 is:

Code:

Sending of message failed.
An error occurred sending mail: Unable to connect to SMTP server mail.****sales.com
via STARTTLS since it doesn't offer STARTTLS in EHLO response.
Please verify that your Mail/News account settings are correct and try again.

billymayday · 06-18-2008, 03:54 PM

Missed that, but did you see

Quote:

smtp_tls_cert_file (default: empty)

File with the Postfix SMTP client RSA certificate in PEM format. This file may also contain the Postfix SMTP client private RSA key, and these may be the same as the Postfix SMTP server RSA certificate and key file.

Do not configure client certificates unless you must present client TLS certificates to one or more servers. Client certificates are not usually needed, and can cause problems in configurations that work well without them. The recommended setting is to let the defaults stand:

smtp_tls_cert_file =
smtp_tls_dcert_file =
smtp_tls_key_file =
smtp_tls_dkey_file =

The best way to use the default settings is to comment out the above parameters in main.cf if present.

In order to verify certificates, the CA certificate (in case of a certificate chain, all CA certificates) must be available. You should add these certificates to the client certificate, the client certificate first, then the issuing CA(s).

Example: the certificate for "client.dom.ain" was issued by "intermediate CA" which itself has a certificate of "root CA". Create the client.pem file with "cat client_cert.pem intermediate_CA.pem root_CA.pem > client.pem".

If you also want to verify remote SMTP server certificates issued by these CAs, you can also add the CA certificates to the smtp_tls_CAfile, in which case it is not necessary to have them in the smtp_tls_cert_file or smtp_tls_dcert_file.

A certificate supplied here must be usable as an SSL client certificate and hence pass the "openssl verify -purpose sslclient ..." test.

Example:

smtp_tls_cert_file = /etc/postfix/client.pem

This feature is available in Postfix 2.2 and later.

suggests to me that you shouldn't be defining smtp_tls_cert_file, etc. at all. It's a lng time sine I set TLS up for myself, but looking at http://postfix.state-of-mind.de/patr...s_support.html, he uses smtpd... not smtp..., so maybe that's where your problem lies.

billymayday · 06-18-2008, 04:02 PM

Sorry - did some more digging - smtp_tls stuff is only if you are connecting to other servers that require tls. Are you?

More importantly, I can't see either smtpd_use_tls or smtpd_tls_security_level defined. Am I missing something? I think you need to (the latter seems to be the version to use, smtpd_use_tls being depreciated)

Ruler2112 · 06-19-2008, 12:07 PM

Thanks for the tips Bill.

I found an article that stated that simply adding those few smtp_ lines to main.cf would enable encryption opportunistically when mail is being shuffled between mail servers on the internet - if the next server supports encryption it'll use it, otherwise it'll send plain.

I do have smtpd_tls_security_level = may as the seventh line from the bottom in my main.cf output pasted above. (The code window adds scroll bars; so it'd be easy to miss.)

I know it's working because the secondary SMTP port I set up works with TLS just fine. I'm actually thinking that it's not something in main.cf, as there's nothing that designates characteristics differently for different ports, but I know not where else to look. master.cf has one line different and the firewall allows port 25 through the same as the backup port. (They're actually specified in the same rules in my firewall rule set, though I don't see where the firewall would have this effect anyways... it might make it not work at all, but not change the response of a daemon.) What would cause a mail server to not advertise STARTTLS in it's HELO/EHLO response?

billymayday · 06-19-2008, 04:49 PM

I though I may have just missed it - too easy with these configs

I don't have much time today, but I'll havea look over the weekend if I can and try and re-setup a TLS version. It's not that hard as I recall.

In the meantime, if you can, strip out al lthe TLS stuff, and follow a basic howto to redo. Don't be tempted to sut and paste from your current setup (you only need to clean out the existing TLS bits, not the whole setup)

Mr. C. · 06-19-2008, 05:14 PM

Setup the standard "submission" port (587) for remote users. Leave port 25 w/out TLS; most MTAs are not going to attempt to connect via TLS.

Quote:

Originally Posted by Ruler2112

- nothing is shown in /var/log/maillog when a client is unable to connect via port 25.

Postfix always logs every connection - if there are no log messages for a connetion attempt, postfix didn't receive it. Consider that a firewall is blocking the attempt, or modifying the communication in some way.

Ruler2112 · 06-23-2008, 03:47 PM

OK, I figured out what the problem is. I feel real stupid not thinking of using a packet sniffer before scrolling through http://www.postfix.org/DEBUG_README.html#logging as suggested by a member of the postfix-users mailing list (I've used them many times before for a variety of applications), but using tcpdump to capture the transaction on both the client side and server side revealed that the server is responding with a 250-STARTTLS, but the client receives 250-XXXXXXXA instead. There must be something being done by my ISP to the traffic being passed on port 25 related to this. Given that I have a workaround (simply setting the sending port to my backup), I'm just going to drop it. (My ISP is such that they don't know what I'm talking about 1/2 the time anyways. They're nice and try, but simply don't have the knowledge required to understand what I'm saying when I have a problem I can't solve on my own.) It is nice to know that it's not something on my box though.

Thanks again for your help.

Mr. C. · 06-23-2008, 05:33 PM

Either a Cisco firewall or desktop antivirus software's mail-scanning proxy is changing the 250-STARTTLS into 250-XXXXXXXA.