Bug 244630 - dma(8): Refresh from upstream
Summary: dma(8): Refresh from upstream
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: needs-qa, patch
Depends on:
Blocks: 256608
  Show dependency treegraph
 
Reported: 2020-03-06 11:31 UTC by Jan-Piet Mens
Modified: 2021-06-14 20:32 UTC (History)
6 users (show)

See Also:
koobs: mfc-stable12?


Attachments
patch to import dma (41.52 KB, patch)
2020-03-06 12:24 UTC, Jan-Piet Mens
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Piet Mens 2020-03-06 11:31:49 UTC
I'm seeing authentication failures and strange messages in /var/log/maillog during dma(8) transfers, which doesn't make much sense as the SMTP server I'm speaking to offers LOGIN PLAIN authentication methods.

[root@gs /etc/dma]# echo hi | /usr/libexec/dma -D jp@example
dma[1052a][56283]: new mail from user=root uid=26 envelope_from=<root@shuttle.ww.example>
dma[1052a][56283]: mail to=<jp@example> queued as 1052a.800a5d0a0
dma[1052a.800a5d0a0][56283]: <jp@example> trying delivery
dma[1052a.800a5d0a0][56283]: using smarthost (mail.relay:587)
dma[1052a.800a5d0a0][56283]: trying remote delivery to mail.relay [ipv6] pref 0
dma[1052a.800a5d0a0][56283]: connect to mail.relay [ipv6] failed: No route to host
dma[1052a.800a5d0a0][56283]: trying remote delivery to mail.relay [ip4] pref 0
dma[1052a.800a5d0a0][56283]: using SMTP authentication for user jp@example
dma[1052a.800a5d0a0][56283]: remote delivery deferred: AUTH cram-md5 failed: 535 Refused. Authentication failed. Rate limit hit or SMTP disabled.
dma[1052a.800a5d0a0][56283]: SMTP login not available. Trying without.
dma[1052a.800a5d0a0][56283]: <jp@example> delivery successful

I then compiled a version of https://github.com/corecode/dma and the program works as expected:

[root@gs /tmp/dma/bsd]# echo hi | ./dma/dma -D jp@example
dma[10528][56272]: new mail from user=root uid=65534 envelope_from=<root@shuttle.ww.example>
dma[10528][56272]: mail to=<jp@example> queued as 10528.800a5d0a0
dma[10528.800a5d0a0][56272]: <jp@example> trying delivery
dma[10528.800a5d0a0][56272]: using smarthost (mail.relay:587)
dma[10528.800a5d0a0][56272]: trying remote delivery to mail.relay [ipv6] pref 0
dma[10528.800a5d0a0][56272]: connect to mail.relay [ipv6] failed: No route to host
dma[10528.800a5d0a0][56272]: trying remote delivery to mail.relay [ip4] pref 0
dma[10528.800a5d0a0][56272]: using SMTP authentication for user jp@example
dma[10528.800a5d0a0][56272]: <jp@example> delivery successful

I think we should please pull in a newer version; I've compiled a diff for *.? between what's currently in FreeBSD and upstream dma

https://gist.githubusercontent.com/jpmens/ef3a407212bd7d0295da1c9a7169f5c3/raw/46ae123777632263053cc24432cfe09fb3c1a356/differences.patch
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-03-06 11:44:52 UTC
@Jan-Piet Could you attach the proposed patch as an attachment please
Comment 2 Jan-Piet Mens 2020-03-06 12:24:04 UTC
Created attachment 212184 [details]
patch to import dma
Comment 3 Jan-Piet Mens 2020-03-06 12:24:39 UTC
(In reply to Kubilay Kocak from comment #1)

Kubilay, I have now prepared a patch which I herewith attach. It compiles on my test system and the binary appears to do what I think it should. :-)
Comment 4 Dan Mahoney 2020-12-22 09:55:24 UTC
Two notes:

1) We (at $dayjob) found an issue with handling of newaliases that's only fixed in HEAD for DMA.  (Effectively, newaliases is broken if called with full path).

2) There's a newaliases bug that causes alias files to not be read if an alternate one is defined.  (https://github.com/corecode/dma/issues/90)

FreeBSD devs may want to locally patch these, or wait for another release.
Comment 5 Helge Oldach 2020-12-25 10:30:08 UTC
(In reply to Dan Mahoney from comment #4)
What is the purpose of running DMA newaliases? The only thing it will do is validate the syntax of /etc/mail/aliases.

The mailer.conf for DMA (libexec/dma/dmagent/mailer.conf - installed as /etc/mail/mailer.conf if WITHOUT_SENDMAIL=yes) doesn't even include a translation for newaliases. (Admittedly however mailer.conf(5) does.)
Comment 6 Dan Mahoney 2021-03-24 11:20:28 UTC
(In reply to Helge Oldach from comment #5)

I mentioned this on the ports mailing list.  Many deploy tools like puppet will call "newaliases" (bareword, no args) when they touch aliases.  We don't want to break this behavior.  An alias should be an alias regardless of the installed system mta.

-Dan