From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] dma: Update to 0.13
Date: Sat, 30 Jan 2021 12:47:47 +0000 [thread overview]
Message-ID: <a55e0cb3-cacf-a03e-49cf-69fc4b1fb621@ipfire.org> (raw)
In-Reply-To: <B7197B2D-0959-4DC6-874F-4A15064AAF4B@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 4493 bytes --]
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(a)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(a)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:
>>
>> 1. Make MASQUERADE config setting override -f
>> 2. add support for RFC976 From_ lines
>> 3. add option to verify server certificate fingerprint
>> 4. 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/450d4b68d3295d2ef50fa5c9576f5c4e043c0c80) 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(a)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)
>>>
>>>
>
next prev parent reply other threads:[~2021-01-30 12:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 20:17 Adolf Belka
2021-01-28 20:36 ` Peter Müller
2021-01-28 22:54 ` Adolf Belka
2021-01-28 23:41 ` Tom Rymes
2021-01-29 11:19 ` Michael Tremer
2021-01-30 12:47 ` Peter Müller [this message]
2021-01-30 12:51 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a55e0cb3-cacf-a03e-49cf-69fc4b1fb621@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox