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
@Jan-Piet Could you attach the proposed patch as an attachment please
Created attachment 212184 [details] patch to import dma
(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. :-)
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.
(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.)
(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
updated in head