Hello Michael, hello Adolf, hello development folks,
thanks for your replies.
I completely agree to our MTA needing to be smarter than /usr/bin/sendmail; back then, nullmailer seemed to be an alternative to me. However, as Michael mentioned, it has no significant benefits over DMA (apart from hopefully being maintained more active, but I have not checked that), and behaves RFC-ignorant at some other points.
Today, replacing DMA with nullmailer thereof does not seem to be worth the effort to me.
Aside from Postfix (and perhaps Exim), there are few open source MTAs left, and none of them is known to me to be RFC-compliant. Further, I agree on Postfix being too heavy for an IPFire machine which is just spewing out some notification mails every now and then.
I have no solution to this problem, yet I think we can agree on the current situation not being optimal. Because of this, accepting Adolf's patch makes sense to me.
Reviewed-by: Peter Müller peter.mueller@ipfire.org
Thanks, and best regards, Peter Müller
Hello Peter,
We know about your personal hatred for dma.
I do agree though. A couple of years you proposed replacing it with nullmailer which didn’t look too much better after a quick glance over the code.
I still stand by the fact that we need something that does more than a “fire and forget” email. If it cannot be sent immediately, the email needs to be spooled somewhere and tried again later.
dma is a very simple implementation that did this job. I agree with the bad patches that are being accepted right now and that make the whole software potentially vulnerable. The maintainer has confirmed to me that he has no interest in continuing development of dma and that he might consider a rewrite in Go or Rust or any other “modern” “programming” language.
Therefore I would like to ask if you still want to replace dma by nullmailer or something else?
-Michael
On 28 Jan 2021, at 20:36, Peter Müller peter.mueller@ipfire.org wrote:
Good evening Adolf, good evening *,
while you neither are responsible for nor can change anything to it, I must say missing changelogs are not a good sign to me. Referring to https://github.com/corecode/dma/commits/master, there were four commits to the source code since version 0.12:
- Make MASQUERADE config setting override -f
- add support for RFC976 From_ lines
- add option to verify server certificate fingerprint
- Change RCPT TO to split up multiple addresses
The latter is especially - um - interesting as the full commit message (available online at https://github.com/corecode/dma/commit/450d4b68d3295d2ef50fa5c9576f5c4e043c0...) states:
RFC5321 section 4.1.1.3 states that RCPT TO only takes one address at a time.
Seriously?! Not even an MTA programmer is reading most basic mail RFCs anymore?!?!
Yes, DMA might be a lightweight replacement for Postfix on machines just needing a better smarthost. However, the commit above means DMA behaved RFC-ignorant as soon as a message had more than one recipient - which apparently does not seem to happen that often to DMA users.
RFC 5321 is not about rocket science or some exotic corner cases at all, it is one of the most basic internet standards regarding e-mail communication. We have lost the complexity battle years ago, apparently, we cannot count on application programmers to have a slightest clue about what they are doing as well.
I am shocked about the quality of that piece of software.
Embittered, Peter Müller
- Update dma from 0.12 to 0.13
- No changelog information available
- No change to the rootfile
Signed-off-by: Adolf Belka adolf.belka@ipfire.org
lfs/dma | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lfs/dma b/lfs/dma index aceb2704e..78bb6465f 100644 --- a/lfs/dma +++ b/lfs/dma @@ -24,7 +24,7 @@
include Config
-VER = 0.12 +VER = 0.13
THISAPP = dma-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 58cb2a286995381c92dc557e639622d6 +$(DL_FILE)_MD5 = 8bf824b065295a594f399c8b96663673
install : $(TARGET)