Bug 248563 - dma man page missing critical information
Summary: dma man page missing critical information
Status: Open
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-09 22:30 UTC by bc979
Modified: 2023-12-03 05:08 UTC (History)
7 users (show)

See Also:


Attachments
Patch to add missing information to dma man page (643 bytes, patch)
2020-08-09 22:30 UTC, bc979
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bc979 2020-08-09 22:30:10 UTC
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.
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2020-08-10 02:45:04 UTC
dma is in contrib/ which means it has upstream other than FreeBSD. I suggest you also send this patch to the upstream (DragonFlyBSD).
Comment 2 Ed Maste freebsd_committer freebsd_triage 2020-08-11 21:02:05 UTC
You can send a GitHub pull request to https://github.com/corecode/dma
Comment 3 bc979 2020-08-11 23:25:00 UTC
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.
Comment 4 Ceri Davies freebsd_committer freebsd_triage 2021-05-23 15:38:31 UTC
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.
Comment 5 bc979 2021-05-23 21:22:20 UTC
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.
Comment 6 Ronald Klop 2021-06-14 14:09:28 UTC
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.
Comment 7 bc979 2021-06-16 00:11:12 UTC
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.
Comment 8 Poul-Henning Kamp freebsd_committer freebsd_triage 2023-12-03 05:08:25 UTC
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)