2 super noob question about email...

  • Thread starter Thread starter nx
  • Start date Start date
N

nx

I have 2 FreeBSD servers in same subnet and domain. One is webserver with contact form that should email directly to my mailserver. I can get this working using sendmail on the webserver (but not ssmtp yet).

Q1. When sendmail sends email does it leave the subnet and go via the 'net before coming back to find my mailserver, via mx records?
If it does, can I somehow force it not to, but to send email directly from webserver to mailserver without leaving the subnet?

Q2. Sendmail works fine, but I can't get ssmtp working.
If possible, I don't want ssmtp to authenticate with the mailserver, as I don't want to store the mailserver authentication info on the webserver. I just need ssmtp to behave like sendmail. Is this possible?

So... I guess I'm not talking about 'forwarding/relaying' email - but just emailing directly from webserver to mailserver?

Can anyone answer these 2 super noob questions about email?
 
I think it comes down to name resolution (make sure your DNS is setup properly (or hosts file)).

One thing to note is that you can turn on debugging mode for ssmtp and then check exactly what it's doing in /var/log/maillog.

PS: If you installed ssmtp from ports, did you also include the "Enable log file" option? Second, did you issue "make replace" after the installation finished or manually edited /etc/mail/mailer.conf?
 
  • Thanks
Reactions: nx
In regard to question 1, by default Sendmail will attempt to look up the MX records using whatever DNS servers the system is set to use, and will send the mail there.

I would generally configure the web server to send all mail to the mail server, and let the mail server handle all mail traffic. This makes it much easier to track/monitor emails going in/out, especially when you have more than one web server. The way to do this is by setting a smart host.

Go into /etc/mail and run make if you haven't already on the web server. This will create all the default configuration files. Edit the file called {hostname}.mc and find the following line:

Code: 
dnl define(`SMART_HOST', `your.isp.mail.server')

Uncomment it (remove 'dnl ') and change your.isp.mail.server to the hostname of your mail server. Rebuild the configuration files and restart the sendmail submit daemons.

Code: 
# cd /etc/mail
# make install restart

You can confirm the setting with 'sendmail -bv':
It should report that emails to your address (or any address) will be relayed to the local mail server:

Code: 
# sendmail -bv me@mydomain.com
me@mydomain.com... deliverable: mailer relay, host my.smart.host, user me@mydomain.com

Without the smart host it would look like the following, to show that it will deliver via smtp to the MX servers responsible for mydomain.com:

Code: 
# sendmail -bv me@mydomain.com
me@mydomain.com... deliverable: mailer esmtp, host mydomain.com., user me@mydomain.com
 
  • Thanks
Reactions: nx
@da1 - Thanks, I reinstalled ssmtp with logging and turned on debugging - but can't get it to send.
I think the problem is that postfix on the mailserver is configured to use SSL key/cert.
If I lazily test this by copying the key/cert from postifix's smtpd.pem to one I've made in the webserver, /var/log/maillog shows ssmtp starting to authenticate but fails.
I've set up a private SSL cert to access squirrelmail on the webserver by creating a CA etc on it.
My guess is I would have to remake the key/cert for postfix the same way to generate a key for the webserver.
Then I'd update ssmtp.conf in the webserver to authenticate with postfix in the mailserver?

If you or anyone has experience with this, please confirm, as I'd like to complete my learning about this as I may have need for ssmtp authenticated forwarding/relaying in future.

Here's the relevant part of my /usr/local/etc/postfix/main.cf

Code: 
# SASL CONFIG
#
broken_sasl_auth_clients = yes
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_non_fqdn_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_invalid_hostname,
  reject_rbl_client list.dsbl.org,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client sbl-xbl.spamhaus.org
  check_policy_service unix:private/spf-policy
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

# TLS CONFIG
# 
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/ssl/postfix/smtpd.pem
smtpd_tls_cert_file = /etc/ssl/postfix/smtpd.pem
smtpd_tls_CAfile = /etc/ssl/postfix/smtpd.pem
smtpd_tls_loglevel = 0
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

I setup the mailserver based on this guide:
http://www.purplehat.org/?page_id=4


I think I should stick with sendmail for now, as it works without authenticating.
(I guess this is because of the permit_mynetworks setting in /usr/local/etc/postfix/main.cf?
Or perhaps that just restricts sasl authentication to subnet servers?)

My reasoning being that I don't want to have any copy of authentication info for the mailserver in the webserver.

I'm up for any advice in this regard, as my priorities are:
- speed of email delivery from webserver to mailserver,
- privacy of email delivery - directly from server to server - not leaving the subnet,
- security - all mail related authentication info should be on the mailserver only,
and the webserver shouldn't accept/receive any mail from anywhere - only send to the mailserver.

@usdmatt - Thanks, I followed those steps and sendmail is now configured the same. And it works.
It still takes about 20-25secs for mail to be received by the mailserver.

Here's the /var/log/maillog

Code: 
Aug  2 15:33:09 webserver sendmail[1201]: q723X907001201: from=www, size=173, class=0, nrcpts=1, msgid=<201208020333.q723X907001201@webserver.mydomain.com>, relay=www@localhost
Aug  2 15:33:10 webserver sm-mta[1202]: q723X9Mt001202: from=<www@webserver.mydomain.com>, size=424, class=0, nrcpts=1, msgid=<201208020333.q723X907001201@webserver.mydomain.com>, proto=ESMTP, daemon=IPv4, relay=localhost [127.0.0.1]
Aug  2 15:33:10 webserver sendmail[1201]: q723X907001201: to=emailaddress@mydomain.com, ctladdr=www (80/80), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30173, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (q723X9Mt001202 Message accepted for delivery)
Aug  2 15:33:11 webserver sm-mta[1204]: STARTTLS=client, relay=mailserver.mydomain.com., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug  2 15:33:52 webserver sm-mta[1204]: q723X9Mt001202: to=<emailaddress@mydomain.com>, ctladdr=<www@webserver.mydomain.com> (80/80), delay=00:00:42, xdelay=00:00:42, mailer=relay, pri=30424, relay=mailserver.mydomain.com. [192.168.0.183], dsn=2.0.0, stat=Sent (Ok: queued as E452922B3F)

Is the delay because it first tries TLS authentication and then fails?

If I'm going to continue using sendmail, are there any security hazards/tips I should immediately fix like blocking particular ports?
 
Sendmail has a long history of security vulnerabilities and personally, I would avoid it all together.

Regarding ssmtp, what do the logs say when you send something?

PS: did you issue [cmd=""]make replace[/cmd] after reinstalling ssmtp?
 
  • Thanks
Reactions: nx
Actually, sendmail and postfix have had a similar low but non-zero number of serious security problems in the last ten years or so. The major differences are that sendmail comes preinstalled and that postfix is easier to configure.
 
  • Thanks
Reactions: nx
Thanks all,

but I've run out of time to get the related site launched, so have to stick with sendmail for now.
I spent at least a morning trying to get ssmtp working, and the logs were showing it trying to authenticate with postfix and failing.
Email is a big black box to me - so much configuration, historical protocol stuff (baggage?), etc - that I've now resigned myself to use what's working after having the best intentions.

The only thing I wish I could fix now is speeding up delivery from the webserver to mailserver - it still takes about 25secs for mail to pass across, although the contact form works nearly instantly.
 
You must log in or register to reply here.
Back
Top