dma (Dragonfly Mail Agent) is a lightweight minimal MTA intended for local delivery or delivery to a smarthost, intended to handle basic use cases like mail from cron(8) There is some ongoing discussion about using it as the default MTA. It is installed with the base system by default (/usr/libexec/dma) but is not yet documented in the handbook. It must be documented independent of whether it is the default (but documentation is a hard requirement for making it the default). https://docs.freebsd.org/en/books/handbook/mail/#mail-changingmta https://docs.freebsd.org/en/books/handbook/mail/#outgoing-only
One related note, from the mailing list discussion on hackers and current: On Thu, 27 Jan 2022 at 20:10, Jamie Landeg-Jones <jamie catflap org> wrote: > > It works perfectly. I've been using it for many years. It doesn't run as > a daemon - if a message can't be delivered (e.g. smarthost temporarily > unavailable), it will be requeued, and the process exits. > > Don't forget to add the cron entry to retry requeued entries! > > */30 * * * * root /usr/libexec/dma -q > > Thus was my only minor "gotcha" - it wasn't obvious from the man pages > to add the cron entry (or maybe I just missed it)
(In reply to Ed Maste from comment #1) Because of the same mail I was inspired to create bug #261532. Might be nice to keep these in sync. If you have a different/better implementation I'm open for it.
michael.osipov at siemens.com pointed out on the mailing list that some applications only talk smtp to send mail: > It is not that easy just too look at ports. I give you three examples > from work: > > 1. Zabbix (network monitoring), suppports only SMTP, although PHP > supports sendmail(8) > 2. JavaMail Transport implementation exists only for SMTP, I was not > able to find any transport implementation for sendmail(8). Maybe I will > write one for fun. > 3. Python mail package supports SMTP only, no other package available, > at least AFAIK. > > Unless ecosystems provide impls for sendmail(8) I see it very hard to > live without localhost:25 for many cases.
(In reply to Jamie Landeg-Jones from comment #3) That may make completely replacing sendmail with dma inadvisable in these and similar use cases, but not everyone will be affected by these restrictions and I think documenting dma is a desirable goal by itself.
Since FreeBSD 14 is so close, I`m gonna make a jump and go directly to Electronic Mail chapter to have this documented on time.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=04c7892a0e2d0570b6fa111efd2e62833b4febc4 commit 04c7892a0e2d0570b6fa111efd2e62833b4febc4 Author: Sergio Carlavilla Delgado <carlavilla@FreeBSD.org> AuthorDate: 2023-10-09 11:04:26 +0000 Commit: Sergio Carlavilla Delgado <carlavilla@FreeBSD.org> CommitDate: 2023-10-09 11:04:26 +0000 Handbook - Mail: Upgrade mail chapter Upgrade mail chapter as part of the handbook working group Changes: * Include dma info * Upgrade sendmail info * Show how to change dma to use another MTA * Show how to change sendmail to use another MTA * Remove Dialup info * Remove fetchmail info * Reorg the sections of the chapter Documentation: * https://man.freebsd.org/cgi/man.cgi?query=dma * https://wiki.mageia.org/en/Dma_Dragonfly_Mail_Agent * https://www.dragonflybsd.org/handbook/mta/ * https://herrbischoff.com/2021/10/freebsd-13-simple-outgoing-email-with-dma/ * https://jpmens.net/2020/03/05/simple-solution-for-outgoing-mail-from-a-freebsd-system/ * https://wiki.archlinux.org/title/Dma * https://forums.freebsd.org/threads/dma-makes-sense.52219/ PR: 261536 Reviewed by: bapt, bcr, dbaio, jrm Differential Revision: https://reviews.freebsd.org/D42009 Sponsored by: Daifressh .../content/en/books/handbook/mail/_index.adoc | 1181 +++++++++----------- 1 file changed, 513 insertions(+), 668 deletions(-)