Solved DMA makes sense

Many of you know that I run bunch of FreeBSD file (because of ZFS) and now virtualization servers (Jails) in production in-spite of the fact that I often criticize direction of FreeBSD development and that I consider myself primary OpenBSD user. This is just a friendly observation that FreeBSD is now the only BSD to be shipped with infamous Sendmail. As of release 4.2 DragonFly BSD is shipped by default only with its own Dragonfly Mail Agent (DMA for short). This begs the question what FreeBSD is going to do about it? I hope we will not wait 12 years like in the case of teTeX vs TeXLive to have dead horse replaced with the modern alternative. My vote will go for DMA but I will be happy with Postfix (like NetBSD) or OpenSMTPd as my native OpenBSD.
 
I think I read that it was on one of todo lists but I didn't know it was already imported. Could you kindly point me to the documentation explaining how to switch off Sendmail and use DMA for local delivery? This post is very much along the lines I think.

https://lists.freebsd.org/pipermail/freebsd-current/2014-February/048477.html

Edit: I read the man pages
http://www.freebsd.org/cgi/man.cgi?...tion=8&manpath=FreeBSD+11-current&format=html
and they are lacking explanation how to replace Sendmail with DMA. Handbook talks about replacing Sendmail with Postfix.

I personally prefer TrueOS installer over vanilla FreeBSD mostly because I like to install OS on ZFS mirror. DMA is not the part of the latest base. However it is easy to install with pkg install and the message says it all.

Code:
Proceed with this action? [y/N]: y
Fetching dma-v0.9_1,1.txz: 100%  31 KiB  31.7kB/s  00:01
Fetching libressl-2.1.6.txz: 100%  2 MiB  2.3MB/s  00:01
Checking integrity... done (0 conflicting)
[1/2] Installing libressl-2.1.6...
[1/2] Extracting libressl-2.1.6: 100%
[2/2] Installing dma-v0.9_1,1...
[2/2] Extracting dma-v0.9_1,1: 100%
Message for dma-v0.9_1,1:
To enable dma please edit /etc/mail/mailer.conf to replace all lines
referring to another MTA with the following:

sendmail  /usr/local/libexec/dma
send-mail  /usr/local/libexec/dma
mailq  /usr/local/libexec/dma

If you not need sendmail anymore, please add in your rc.conf:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

if you want anything in your queue to be flushed at on boot or before
shutdown, add the following to rc.conf as well:

dma_flushq_enable="YES"

you can also add a cronjob to do regular mailq flushes using the following
command:

/usr/local/libexec/dma -q

And you can disable some sendmail specific daily maintenance routines in your
/etc/periodic.conf file:

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"
 
That looks interesting. Personally I think it might be a good idea to replace sendmail with DMA. For similar reasons why BIND was replaced by unbound. Most people don't need a fully blown MTA and just need something that accepts local mail and is able to forward it. If you still need sendmail it can always be installed through a port or package.
 
I think I read that it was on one of todo lists but I didn't know it was already imported. Could you kindly point me to the documentation explaining how to switch off Sendmail and use DMA for local delivery? This post is very much along the lines I think.

https://lists.freebsd.org/pipermail/freebsd-current/2014-February/048477.html

Edit: I read the man pages
http://www.freebsd.org/cgi/man.cgi?...tion=8&manpath=FreeBSD+11-current&format=html
and they are lacking explanation how to replace Sendmail with DMA. Handbook talks about replacing Sendmail with Postfix.
...

Since dma(8) is in HEAD and hasn't even made it to stable/10 it's not quite at the point where it's officially documented and supported. In the meantime, mail/dma is the way to go.
 
  • Thanks
Reactions: Oko
I took the plunge and replaced sendmail(8) with mail/dma on all my file servers and Jail hosts running FreeBSD 10.1 (8 in total). So far things are working as expected and I am receiving e-mail notifications from the machines as expected. Please send me a PM if you have troubles configuring mail/dma.
 
I just spent 3 days trying to setup an internal only domain mailserver with sendmail(8). I wanted to only accept connections from clients with a certificate I issue, with no other authentication. I could only get access/relay control without TLS, however once I introduced TLS it just acted like an open relay and totally ignored the access :confused:. I tentatively switched to mail/postfix and had it working precisely the way I wanted within half a day.
The biggest help was that mail/postfix's online help was hyperlinked, while the few links I tried from sendmail(8) were dead.
I came across this thread whilst flailing and thought I'd share.
 
  • Thanks
Reactions: Oko
Configuring DMA to work with gmail & smartmail was a bit fiddly. I built the port against libressl and installed it the usual way. In gmail & fastmail, I generated an app token with only SMTP support, and then set up the following, where {{ variable }} is what you want to substitute:

Code:
# /etc/rc.conf.d/sendmail
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

Code:
# /etc/rc.conf.d/dma_flushq
dma_flushq_enable="YES"

Code:
# /etc/mail/mailer.conf
sendmail  /usr/local/libexec/dma
send-mail  /usr/local/libexec/dma
mailq  /usr/local/libexec/dma
newaliases  /usr/local/libexec/dma
hoststat  /usr/bin/true
purgestat  /usr/bin/true

Code:
# /etc/aliases
# append this line
root: {{ forwarding_address }}

Code:
# /usr/local/etc/dma/dma.conf
SMARTHOST {{ smtpthost }}
AUTHPATH /usr/local/etc/dma/auth.conf
SECURETRANSFER
PORT 587
INSECURE
MAILNAME {{ hostname }}
MASQUERADE root@{{ hostname }}

Code:
# /usr/local/etc/dma/auth.conf
{{ smtp_login}|{{ smtp_host}}:{{ smtp_app_token }}

You can check if it's working via tail -F /var/log/maillog & ; periodic daily which should send a couple of messages through and show you something like this in the logs:

Code:
Aug 19 03:02:53 wintermute dma[12a052]: new mail from user=root uid=26 envelope_from=<root@...t>
Aug 19 03:02:53 wintermute dma[12a052]: mail to=<root@...> queued as 12a052.8016280f0
Aug 19 03:02:53 wintermute dma[12a052.8016280f0]: trying delivery
Aug 19 03:02:53 wintermute dma[12a052.8016280f0]: using smarthost (smtp....:587)
Aug 19 03:02:53 wintermute dma[12a052.8016280f0]: trying remote delivery to smtp.... [12.34.56.789] pref 0
Aug 19 03:02:54 wintermute dma[12a052.8016280f0]: using SMTP authentication for user dch@...
Aug 19 03:02:55 wintermute dma[12a052.8016280f0]: delivery successful

In all cases you want to use 587 as your SMTP submission port, and ensure you're using end-to-end TLS.

If your delivery fails, I suggest using openssl which has a telnet-like console client that takes care of the TLS cert negotiation for you. Here's a sample session using port 465 and TLS. The first line in each code block is what you type in:

Code:
dch@wintermute ~> openssl s_client -connect smtp-relay.gmail.com:465 -tls1_2 -tlsextdebug -status

CONNECTED(00000004)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "session ticket" (id=35), len=0
TLS server extension "EC point formats" (id=11), len=2
0000 - 01  .
0002 - <SPACES/NULS>
OCSP response: no response sent
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = smtp-relay.gmail.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp-relay.gmail.com
  i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
  i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
  i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEjDCCA3SgAwIBAgIIJxNvJwRUYA0wDQYJKoZIhvcNAQELBQ...
XMOmNOwXndm9bjzGk3dZ0A==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp-relay.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3739 bytes and written 442 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
  Protocol  : TLSv1.2
  Cipher  : ECDHE-RSA-AES128-GCM-SHA256
  Session-ID: BC8FBD91...
  Session-ID-ctx:
  Master-Key: 8DE7313ACF54BA...
  Key-Arg  : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  TLS session ticket lifetime hint: 100800 (seconds)
  TLS session ticket:
  00a0 - d2 f2 f6 82  ....

  Start Time: 1471639809
  Timeout  : 7200 (sec)
  Verify return code: 0 (ok)
---
220 smtp-relay.gmail.com ESMTP f197sm1181739wmg.1 - gsmtp

Code:
EHLO your.local.hostname  *** you type this ***

250-smtp-relay.gmail.com at your service, [144.76.138.208]
250-SIZE 157286400
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

The AUTH LOGIN <password> is generated via printf “\0smtp_login\0smtp_token” | openssl enc -a:

Code:
AUTH PLAIN nie6PaShPhei1ahxiiShae1eiuda1OgiShahh  *** you type this ***
235 2.7.0 Accepted
^C⏎

If you got to Accepted here, then any issues are likely around IP or login restrictions imposed by gmail or the smart host provider -- Google has a number of alternate SMTP relay options with varying security requirements.

If you didn't get to Accepted, I hope you found out why from the openssl session.
 
Last edited:
In all cases you want to use 465 as your SMTP submission port, and ensure you're using end-to-end TLS as opposed to STARTTLS which only switches part way through the conversation to SMTP.

There should be no security advantage to using the non-standard and deprecated SMTPS on port 465. Properly implemented STARTTLS on port 25 or 587 offers the full security of TLS, if the client and server choose to implement it. The use of port 465 for SMTP mail is not supported by any current IETF standards, the port is allocated for another purpose by IANA, and it should be avoided whenever possible (only used if absolutely necessary, to support obsolete legacy clients/servers which do not have STARTTLS support). Ideally the TLS on 25 and 587 should be paired with DANE / TLSA.
 
  • Thanks
Reactions: dch
There should be no security advantage to using the non-standard and deprecated SMTPS on port 465. Properly implemented STARTTLS on port 25 or 587 offers the full security of TLS, if the client and server choose to implement it. The use of port 465 for SMTP mail is not supported by any current IETF standards, the port is allocated for another purpose by IANA, and it should be avoided whenever possible (only used if absolutely necessary, to support obsolete legacy clients/servers which do not have STARTTLS support). Ideally the TLS on 25 and 587 should be paired with DANE / TLSA.

I'll amend my post above to include this, *however* I could not get dma to successfully send using 587 unless INSECURE was enabled. This was not necessary when using 465 and TLS. My reading of STARTTLS implies there is a risk of MITM downgrade attacks, unless dma supports DANE/TLSA etc. Thoughts?

SECURE (boolean, default=commented)
Uncomment this entry and change it to `INSECURE' to use plain text
SMTP login over an insecure connection. You have to rename this
variable manually to prevent that you send your password acciden-
tally over an insecure connection.

Also, using 465 I could use TLS 1.2 which did not seem to be possible using 587; my system is built with libressl now so that presumably is an issue in this case. I can't speak for the implications.
 
I'll amend my post above to include this, *however* I could not get dma to successfully send using 587 unless INSECURE was enabled. This was not necessary when using 465 and TLS. My reading of STARTTLS implies there is a risk of MITM downgrade attacks, unless dma supports DANE/TLSA etc. Thoughts?

The MITM downgrade isn't any worse in practical terms than MITM proxying of the TLS session on 465, because a significant percentage of the world's mail servers use self-signed certificates. For SMTP, the only reliable mechanism currently widely available is DANE/TLSA, which notably also addresses the previously exploited issue of falsely issued certificates or untrustworthy sub-CA root certificates (both are documented to have happened during recent years, due to malpractice/negligence by supposedly trustworthy CAs). DMA should provide a mechanism to use 25/587 and configure TLS as mandatory (either for all connections in the case of forwarding to a relay, or specific remote hosts if used as a general MTA).

DANE solves most of the trust issues with TLS certificates, allowing the server operator to use more or less whatever they want to use, whether it's self-signed, their own org's CA, or a specific public CA. It also makes it almost impossible for someone with a compromised or improper root-CA cert to actually gain an advantage, unless DANE specifies a public CA and the problem cert is for that particular CA. Without DANE, 465 is essentially fully vulnerable to a MITM attack when used for MTA-to-MTA-via-MX purposes.

Sadly, adoption rates of DNSSEC and DANE are not terribly good at present, meaning that most ESMTPS sessions (on any port) are actually not protected against MITM. There's really no valid excuses for failing to implement both of them (yes, it does take time and skill to implement, and needs some ongoing management, but it's not terribly difficult, and there has been more than enough time for even the largest mail service providers to do it). DNSSEC may be imperfect, but not implementing it is like saying we're not going to fix the fuel tank which is known to frequently explode in a crash because it costs a bit and the fix won't prevent all explosions (in that analogy, it does actually prevent most easier explosions). Yes, I'm saying that not using DNSSEC is now equivalent to refusing to address the problems in a Ford Pinto! It may be imperfect, but it's a hell of a lot better than not using it.

If DMA does not have DANE support, I would grade it as sub-standard for general use on the public Internet, and only suitable for private network use or submission to a single or small set of upstream mail relay(s). I certainly hope that it does support DANE, but I don't know and your phrasing makes me wonder if that important feature is missing.

There is no technical reason why you should not be able to use TLS 1.2 on 587. There is also no technical reason why SMTP AUTH should work on 465 but fail on 587+STARTTLS. Problems with either of those are either misconfiguration (at either end of the connection), or bad implementation (at either end of the connection).

One of the issues with 465 is that it will not be forwarded by some routers, if those routers have the IANA-registered use of it enabled. That's due to the registered protocol being somewhat unusual, and not due to any firewall or filtering rules. So, it's randomly unusable or unreliable over some network paths. All usage of it is non-standard, and always has been, as it has never been part of a published standard; it was deprecated before RFC 2487 was published, only appearing in earlier drafts of that RFC.
 
Also, using 465 I could use TLS 1.2 which did not seem to be possible using 587; my system is built with libressl now so that presumably is an issue in this case. I can't speak for the implications.
I am resurrecting this thread in order to make some comments about default MTA on 11.0 but I am also using it to comment some of your statements too.

465 should never be used. I have being using dma to send mail via gmail relay on 587 over SECURE/STARTTLS compiled with LibreSSL since 10.1 so something is wrong with your configuration.

On the sad note FreeBSD uses sendmail as a default MTA. I see that /etc/dma does exist but is missing auth.conf file (dma.conf ). Having learned about badly misconfigured unbound in the base I am not sure whether to be sad or happy that dma is not default MTA.
 
I am resurrecting this thread in order to make some comments about default MTA on 11.0 but I am also using it to comment some of your statements too.

465 should never be used. I have being using dma to send mail via gmail relay on 587 over SECURE/STARTTLS compiled with LibreSSL since 10.1 so something is wrong with your configuration.

On the sad note FreeBSD uses sendmail as a default MTA. I see that /etc/dma does exist but is missing auth.conf file (dma.conf ). Having learned about badly misconfigured unbound in the base I am not sure whether to be sad or happy that dma is not default MTA.


Can you share your config Oko? I'm happy to update my guide above if it can be improved.
 
  • Thanks
Reactions: Oko
DMA is in the base and built by default on FreBSD 11, it's just not enabled by default:

Code:
% ls -l /usr/libexec/dma
-r-xr-sr-x  1 root  mail  61760 Nov  2 15:27 /usr/libexec/dma

There is a manual page as well, dma(8).

The mailer.conf(5) manual page in FreeBSD 11 has the relevant entries for switching to DMA as the default mailer in the system:

Code:
# Execute dma instead of sendmail
sendmail        /usr/libexec/dma
send-mail       /usr/libexec/dma
mailq           /usr/libexec/dma
newaliases      /usr/libexec/dma
 
Can you share your config Oko? I'm happy to update my guide above if it can be improved.
This is /usr/local/etc/dma/dma.conf

Code:
# $DragonFly: src/etc/dma/dma.conf,v 1.2 2008/02/04 10:11:41 matthias Exp $
#
# Your smarthost (also called relayhost).  Leave blank if you don't want
# smarthost support.
SMARTHOST smtp.gmail.com

# Use this SMTP port.  Most users will be fine with the default (25)
PORT 587

# Path to your alias file.  Just stay with the default.
#ALIASES /etc/aliases

# Path to your spooldir.  Just stay with the default.
SPOOLDIR /var/spool/dma

# SMTP authentication
AUTHPATH /usr/local/etc/dma/auth.conf

# Uncomment if yout want TLS/SSL support
SECURETRANSFER

# Uncomment if you want STARTTLS support (only used in combination with
# SECURETRANSFER)
STARTTLS

# Uncomment if you have specified STARTTLS above and it should be allowed
# to fail ("opportunistic TLS", use an encrypted connection when available
# but allow an unencrypted one to servers that do not support it)
#OPPORTUNISTIC_TLS

# Path to your local SSL certificate
#CERTFILE

# If you want to use plain text SMTP login without using encryption, change
# the SECURE entry below to INSECURE.  Otherwise plain login will only work
# over a secure connection.  Use this option with caution.
#SECURE

# Uncomment if you want to defer your mails.  This is useful if you are
# behind a dialup line.  You have to submit your mails manually with dma -q
#DEFER

# Uncomment if you want the bounce message to include the complete original
# message, not just the headers.
#FULLBOUNCE

# The internet hostname dma uses to identify the host.
# If not set or empty, the result of gethostname(2) is used.
# If MAILNAME is an absolute path to a file, the first line of this file
# will be used as the hostname.
#MAILNAME mail.example.net

# Masquerade envelope from addresses with this address/hostname.
# Use this if mails are not accepted by destination mail servers because
# your sender domain is invalid.
# By default, MASQUERADE is not set.
# Format: MASQUERADE [user@][host]
# Examples:
# MASQUERADE john@  on host "hamlet" will send all mails as john@hamlet
# MASQUERADE percolator  will send mails as $username@percolator, e.g. fish@percolator
# MASQUERADE herb@ert  will send all mails as herb@ert

This is the summary of my changes.
Code:
SMARTHOST smtp.gmail.com
PORT 587
SPOOLDIR /var/spool/dma
AUTHPATH /usr/local/etc/dma/auth.conf
SECURETRANSFER
STARTTLS

And this is /usr/local/etc/dma/auth.conf

Code:
# $DragonFly: src/etc/dma/auth.conf,v 1.1 2008/02/02 18:24:00 matthias Exp $
#
# SMTP authentication entries (currently AUTH LOGIN only)
# Format: user|my.smarthost.example.com:password
username@gmail.com|smtp.gmail.com:plain_text_password
 
Back
Top