Re: Dragonfly Mail Agent (dma) in the base system
> It was a let's consider all the gotchas before diving in with both feet. *shrug* And all I did was suggest one way to deal with it. I didn't disagree with your analysis. I don't understand the hostility. > For me personally, maintainer of nmh and heirloom-mailx, I will enable the > dma build on my sandbox to give it a little workout. I use heirloom-mailx all the time. It works fine with DMA. Ooops, sorry if that comment was too presumptuous of me ;-) cheers! ... Jamie
Re: Dragonfly Mail Agent (dma) in the base system
Am 2022-02-06 um 23:16 schrieb Jamie Landeg-Jones: Cy Schubert wrote: In message <202202061553.216fr0yt071...@donotpassgo.dyslexicfish.net>, Jamie La ndeg-Jones writes: Cy Schubert wrote: dma doesn't support SMTP submission, we may need to review various port default options or whether ports even support it. Good catch. You misquoted me. Read my email again! Sorry, I read it again, but it still looks to me as "some ports only work via SMTP submission, so they will need to be looked at." I suggested an alternative of instead, "emulating" the SMTP submission functionality (but maybe in a better way that my suggested hack, though) After all, it isn't just ports - there could be other third party stuff that only works via submission too. 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. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Cy Schubert wrote: > In message <202202061553.216fr0yt071...@donotpassgo.dyslexicfish.net>, > Jamie La > ndeg-Jones writes: > > Cy Schubert wrote: > > > > > dma doesn't support SMTP submission, we may need to review various port > > > default options or whether ports even support it. > > > > Good catch. > > You misquoted me. Read my email again! Sorry, I read it again, but it still looks to me as "some ports only work via SMTP submission, so they will need to be looked at." I suggested an alternative of instead, "emulating" the SMTP submission functionality (but maybe in a better way that my suggested hack, though) After all, it isn't just ports - there could be other third party stuff that only works via submission too. So, to avoid breaking functionality, smtp submission is something to think about continuing supporting, hence my use of the phrase "good catch". Is this not correct? cheers, Jamie > > Would a suitable workaround be to parse the dma.conf file for the SMARTHOST > > address, and then set up a simple tcp proxy on the local submission port to > > that? > > Your comment is based on a false premise.
Re: Dragonfly Mail Agent (dma) in the base system
Cy Schubert wrote: > dma doesn't support SMTP submission, we may need to review various port > default options or whether ports even support it. Good catch. Would a suitable workaround be to parse the dma.conf file for the SMARTHOST address, and then set up a simple tcp proxy on the local submission port to that?
Re: Dragonfly Mail Agent (dma) in the base system
On Thu, 27 Jan 2022, at 21:34, Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. Yes please. I've used both the one in base, and also from ports, for many years, on both hobby / home desktops, and also in production. The base one has occasionally gotten wedged, and backed up processes from periodic. I don't recall seeing this with the one from ports, nor do I recall seeing it recently in the last year. If I get a repeat, I'll add a PR rather than this anecdotal info. A+ Dave
Re: Dragonfly Mail Agent (dma) in the base system
In message , David Chisnall w rites: > On 30/01/2022 14:01, michael.osi...@siemens.com wrote: > > Sendmail: The biggest problem is that authentication strictly requires > > Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the > > handbook you must recompile sendmail from base with Cyrus SASL from > > ports to make this possible. A showstopper actually, for two reasons: > > 1. I don't like mixing base and ports, it just creates a messy system. > > 2. While this may work with hosts, when you have jails running off a > > RELEASE in Bastille this obviously will not work. > > Not going to work with sendmail easily. > > I think this is a critical point: at the moment, we're paying the cost > of having a full-featured MTA in the base system, without getting most > of the benefits. Around 2003, I hit exactly this problem. The > instructions after update were slightly terrifying: after each base > system or ports update, I potentially had to recompile my own sendmail. > > There's now a sendmail+sasl configuration in packages and so I was > incredibly happy to be able to move away from using sendmail in base. > Now I have two copies of sendmail on some machines. The one in ports, > for compatibility reasons, looks for config in /etc/mail not under > LOCALBASE, which is a layering violation and means that freebsd-update > periodically tries to corrupt my config. > > I have no strong opinions about where we move to, but moving *from* > shipping a limited sendmail in base would make me very happy. I'd like to add, proceed cautiously. I've been running postfix on my external gateway for a couple of decades but recently migrated all but one of my internal machines from sendmail to postfix. There were a couple of hiccups along the way. In one case there was a mail loop of at(1) jobs which required the tweak of a procmail rule. In the second case nmh submits mail to localhost:587 requiring altering master.cf. nmh uses only that port though it can pipe directly to the sendmail binary when built that way. If dma doesn't support SMTP submission, we may need to review various port default options or whether ports even support it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.
Re: Dragonfly Mail Agent (dma) in the base system
On 30/01/2022 14:01, michael.osi...@siemens.com wrote: Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. I think this is a critical point: at the moment, we're paying the cost of having a full-featured MTA in the base system, without getting most of the benefits. Around 2003, I hit exactly this problem. The instructions after update were slightly terrifying: after each base system or ports update, I potentially had to recompile my own sendmail. There's now a sendmail+sasl configuration in packages and so I was incredibly happy to be able to move away from using sendmail in base. Now I have two copies of sendmail on some machines. The one in ports, for compatibility reasons, looks for config in /etc/mail not under LOCALBASE, which is a layering violation and means that freebsd-update periodically tries to corrupt my config. I have no strong opinions about where we move to, but moving *from* shipping a limited sendmail in base would make me very happy. David
Re: Dragonfly Mail Agent (dma) in the base system
Am 28.01.2022 um 19:04 schrieb Ed Maste: On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate. Thanks everyone for the feedback so far. I think the feedback (including some private mail) can be summarised as: - It works well for the intended use case. - Documentation (FreeBSD handbook) is missing. I have submitted https://bugs.freebsd.org/261536 to track this. - We'd need to address queued mail in some way before it could be the default (e.g. provide a default cron job). Just to add the probably most simple way, in use here for several years, for the same purpose others already reported (nano-monitoring-solution): cat /etc/dma/dma.conf # $FreeBSD: stable/11/libexec/dma/dmagent/dma.conf 289087 2015-10-09 22:09:44Z bapt $ SMARTHOST msa PORT 587 NULLCLIENT Working perfectly fine (forwarding all and everything; mostly ending up for root(@localhost)) and highly appreciated zero-hassle base feature!
Re: Dragonfly Mail Agent (dma) in the base system
Baptiste Daroussin writes: > Dag-Erling Smørgrav writes: > > [...] does not have a default domain setting, so it cannot handle > > email from cron, periodic etc. where the recipient is just a user > > name (usually “root”) [...] > This has been fixed since. (not by me) In that case, assuming that it behaves sensibly out of the box, my only objection is the lack of documentation, which I understand is being worked on. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Dragonfly Mail Agent (dma) in the base system
On Sun, Jan 30, 2022 at 11:25:54PM +0100, Dag-Erling Smørgrav wrote: > Ed Maste writes: > > I am interested in determining whether dma is a viable minimal base > > system MTA, and if not what gaps remain. > > It cannot. Ask bapt@ who was the one to import it, and later abandon > the idea of making it our default MTA. The reason was that it does not > have a default domain setting, so it cannot handle email from cron, > periodic etc. where the recipient is just a user name (usually “root”), > and the devs were not willing to add that feature. I have email as far > back as 2015 on the subject. > This has been fixed since. (not by me) Bapt
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste writes: > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. It cannot. Ask bapt@ who was the one to import it, and later abandon the idea of making it our default MTA. The reason was that it does not have a default domain setting, so it cannot handle email from cron, periodic etc. where the recipient is just a user name (usually “root”), and the devs were not willing to add that feature. I have email as far back as 2015 on the subject. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: Dragonfly Mail Agent (dma) in the base system
Am 2022-01-30 um 15:01 schrieb michael.osi...@siemens.com: Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) Another feature I have forgot: * .forward support. All mails received on a Unix account shall be redirected to the user's email address. Michael
Re: Dragonfly Mail Agent (dma) in the base system
Hi Ed, thanks for raising, this is just on time for us. I'd like to describe what both cover and not cover and I would expect from a minimal MTA. I am on 12-STABLE/12.3-RELEASE. We solely use sendmail with relay via sendmail invocation or SMTP on localhost:25. Minimal configuration for scripts and applications running on hosts and jails. Our current corporate messaging service is being phased out for a new one which requires authentication via LOGIN or PLAIN and mandatory STARTTLS, previous was anonymous and unencrypted. Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. DMA: Disclaimer: I haven't tried, but read documentation and source code. Although it supports TLS, I don't see any of these [1], I fail to see how it verifies the peer. I have never seen something to provide the server's fingerprint to verification. It very much feels like an SSH-like approach. It does not listen, as documented, on localhost, so applications supporting SMTP only will need extra configuration to reach out to the relay host directly. Central config at MTA side not possible anymore. Although, I don't need certificate-based authentication against the relay and DMA supports it, it does not support of using a passphrase for the certificate key file like HTTPd supports through mod_ssl. Should be a no-brainer these days. Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) The issues with certificates and OpenSSL in the base system I have already extensively dicussed with kevans@ [2]. I hope this can be put into consideration. Regards, Michael [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_paths.html [2] https://reviews.freebsd.org/D31487#710650
Re: Dragonfly Mail Agent (dma) in the base system
On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: > > If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. Thanks everyone for the feedback so far. I think the feedback (including some private mail) can be summarised as: - It works well for the intended use case. - Documentation (FreeBSD handbook) is missing. I have submitted https://bugs.freebsd.org/261536 to track this. - We'd need to address queued mail in some way before it could be the default (e.g. provide a default cron job).
Re: Dragonfly Mail Agent (dma) in the base system
On 27/01/2022 22:34, Ed Maste wrote: The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functionality as a full MTA like postfix or sendmail. It is intended for use cases such as delivering cron(8) mail. Since 2014 we have a copy of dma in the base system available as an optional component, enabled via the WITH_DMAGENT src.conf knob. I am interested in determining whether dma is a viable minimal base system MTA, and if not what gaps remain. If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate. We use it also to get periodic mail and other mail off of the system and it works fine! Gr Johan
Re: Dragonfly Mail Agent (dma) in the base system
Hi, > On 27 Jan 2022, at 21:34, Ed Maste wrote: > > The Dragonfly Mail Agent (dma) [etc] We've used it for years on routers and other small boxes to offload mail from periodic and cron. -- Bob Bishop r...@gid.co.uk
Re: Dragonfly Mail Agent (dma) in the base system
On Thu, 27 Jan 2022 at 20:10, Jamie Landeg-Jones wrote: > > Ed Maste wrote: > > > Since 2014 we have a copy of dma in the base system available as an > > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I thought it was enabled at default! Yes, my mistake - by default WITH_DMAGENT is enabled, and /usr/libexec/dma is built. What is not done by default is configuring /etc/mailer.conf to use dma for /usr/sbin/sendmail or /usr/sbin/mailq.
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste wrote: > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. I thought it was enabled at default! > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I use it on my non-mailservers for delivering both local mail and remote mail (from cron etc. to remote users) via my mailservers as smarthost. 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) As for the smarthost configuration, I've successfully used ipv4, ipv6, both on port 25, and non-standard ports. I've also used combinations of non-encrypted, TLS, and opportunistic TLS, - all work as expected. I haven't ever used the smtp-login facility. Cheers, Jamie
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste wrote in : |The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) |which accepts mail from a local Mail User Agent (MUA) and delivers it |locally or to a smarthost for delivery. dma does not accept inbound |mail (i.e., it does not listen on port 25) and is not intended to |provide the same functionality as a full MTA like postfix or sendmail. |It is intended for use cases such as delivering cron(8) mail. | |Since 2014 we have a copy of dma in the base system available as an |optional component, enabled via the WITH_DMAGENT src.conf knob. | |I am interested in determining whether dma is a viable minimal base |system MTA, and if not what gaps remain. If you have enabled DMA on |your systems (or are willing to give it a try) and have any feedback |or are aware of issues please follow up or submit a PR as appropriate. I used it for years and even maintained a package for a Linux distribution (CRUX) until last October, and i think maybe even AlpineLinux before? I know for sure i maintained a package with Author: emaste Date: Fri Oct 27 20:21:09 2017 New Revision: 325047 URL: https://svnweb.freebsd.org/changeset/base/325047 patched on top of it for years. Very basic usage, only local delivery. But i plan to readd the package as part of the postfix-lmdb package i maintain, because, you know, postfix's sendmail(1) and local deliveries need read access to the postfix configuration, and as part of my effort to totally box (unshare + overlay mount) all my daemons which cross ingress/egress (and place their config under /root/hosts/$HOSTNAME), it's need to access /etc/postfix-lmdb is in the way. (The plan is thus to make dma "part of this package" and make it provide /usr/sbin/sendmail, configured to proxy to local SMTP, where postfix then regulary sits.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste writes: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I've been using DMA for quite some time (in fact, I'm using it to send this mail) for local delivery and forwarding. It is quite easy to set up, and I have no complaints at all. (forgot to carbon copy, sorry :p) -- Filipe da Silva Santos signature.asc Description: PGP signature
Re: Dragonfly Mail Agent (dma) in the base system
On 1/27/22 1:34 PM, Ed Maste wrote: The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functionality as a full MTA like postfix or sendmail. It is intended for use cases such as delivering cron(8) mail. Since 2014 we have a copy of dma in the base system available as an optional component, enabled via the WITH_DMAGENT src.conf knob. I am interested in determining whether dma is a viable minimal base system MTA, and if not what gaps remain. If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate. I've used DMA on systems without local mail accounts to forward cron periodic e-mails just fine. It even supports STARTTLS and SMTP AUTH. I haven't tried using it for simple local delivery to /var/mail/root. -- John Baldwin
Dragonfly Mail Agent (dma) in the base system
The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functionality as a full MTA like postfix or sendmail. It is intended for use cases such as delivering cron(8) mail. Since 2014 we have a copy of dma in the base system available as an optional component, enabled via the WITH_DMAGENT src.conf knob. I am interested in determining whether dma is a viable minimal base system MTA, and if not what gaps remain. If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate.
