Bug 248563
| Summary: | dma man page missing critical information | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Documentation | Reporter: | bc979 | ||||
| Component: | Manual Pages | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Open --- | ||||||
| Severity: | Affects Some People | CC: | bapt, ceri, doc, emaste, lwhsu, phk, ronald-lists | ||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261536 | ||||||
| Attachments: |
|
||||||
dma is in contrib/ which means it has upstream other than FreeBSD. I suggest you also send this patch to the upstream (DragonFlyBSD). You can send a GitHub pull request to https://github.com/corecode/dma I sent a report to DragonFly, but not sure it will be received. Their bug list requires membership, but the list is closed. I sent it to one of the names listed. It doesn't appear in their bug list and there is no activity since 28 Jun. It's unlikely that this patch will get accepted upstream, as the information isn't true upstream as LOGIN support was added in 2015. We will have to decide whether to patch locally, do an update to upstream, or remove this from base in favour of the port. My personal preference would be to maintain it in base. Virtually all of the machines I set up have no direct user interface. They are servers. Having it in base saves having to remember to add yet another package. The big issue is remembering the name. I have to go digging around to find that each time. There are three things you lose as you get older. The first is your memory... I've forgotten the other two. The reporter of the issue was probably not using SSL/TLS.
DMA does not do plain text passwords over unencrypted connections so he needed CRAM-MD5 I guess. This is already documented (if you know how to read this):
see dma(8):
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
accidentally over an insecure connection.
I am not using encryption as the mail server is in the same room on the same net. I never expected to find information about how to configure the non-encrypted setup in the encrypted setup information. I don't believe how DMA finds the auth information is described anywhere. That was the big issue. Man-page cross-references are confusing in 14.0-R dma(8) xrefs mailaddr(7) which does not exist. dma.conf(5) links to dma(8) but there is no auth.conf(5) link to dma(8) |
Created attachment 217119 [details] Patch to add missing information to dma man page The dma man page (/usr/src/contrib/dma/dma.8) does not contain critical information that is needed in order to get dma to connect to a remote MTA. It took me several days of reading the dma source to figure out how to make it work. I am attaching a patch to the man page to provide this information.