From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: Re: [PATCH] dma: Update to 0.13 Date: Sat, 30 Jan 2021 12:51:03 +0000 Message-ID: <2D5C1A4A-ABDB-4BF7-A5AE-E115AD9A58A2@ipfire.org> In-Reply-To: <a55e0cb3-cacf-a03e-49cf-69fc4b1fb621@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7580435302068746058==" List-Id: <development.lists.ipfire.org> --===============7580435302068746058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 30 Jan 2021, at 12:47, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wr= ote: >=20 > Hello Michael, hello Adolf, hello development folks, >=20 > thanks for your replies. >=20 > 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. >=20 > Today, replacing DMA with nullmailer thereof does not seem to be worth the = effort to me. >=20 > 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 heav= y for an IPFire machine > which is just spewing out some notification mails every now and then. Long-term I do not see any other solution than Postfix. It is small enough an= d can be stripped down to what need. > 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. Absolutely, because it still fixes bugs. > Reviewed-by: Peter M=C3=BCller <peter.mueller(a)ipfire.org> >=20 > Thanks, and best regards, > Peter M=C3=BCller -Michael >=20 >> Hello Peter, >> We know about your personal hatred for dma. >> I do agree though. A couple of years you proposed replacing it with nullma= iler which didn=E2=80=99t 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 =E2= =80=9Cfire and forget=E2=80=9D email. If it cannot be sent immediately, the e= mail needs to be spooled somewhere and tried again later. >> dma is a very simple implementation that did this job. I agree with the ba= d 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 int= erest in continuing development of dma and that he might consider a rewrite i= n Go or Rust or any other =E2=80=9Cmodern=E2=80=9D =E2=80=9Cprogramming=E2=80= =9D language. >> Therefore I would like to ask if you still want to replace dma by nullmail= er or something else? >> -Michael >>> On 28 Jan 2021, at 20:36, Peter M=C3=BCller <peter.mueller(a)ipfire.org> = wrote: >>>=20 >>> Good evening Adolf, >>> good evening *, >>>=20 >>> while you neither are responsible for nor can change anything to it, I mu= st say missing changelogs >>> are not a good sign to me. Referring to https://github.com/corecode/dma/c= ommits/master, there were >>> four commits to the source code since version 0.12: >>>=20 >>> 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 >>>=20 >>> The latter is especially - um - interesting as the full commit message (a= vailable online at >>> https://github.com/corecode/dma/commit/450d4b68d3295d2ef50fa5c9576f5c4e04= 3c0c80) states: >>>=20 >>>> RFC5321 section 4.1.1.3 states that RCPT TO only takes one address at a = time. >>>=20 >>> Seriously?! Not even an MTA programmer is reading most basic mail RFCs an= ymore?!?! >>>=20 >>> 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 mes= sage had more than one >>> recipient - which apparently does not seem to happen that often to DMA us= ers. >>>=20 >>> 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 compl= exity battle years ago, >>> apparently, we cannot count on application programmers to have a slightes= t clue about what they are >>> doing as well. >>>=20 >>> I am shocked about the quality of that piece of software. >>>=20 >>> Embittered, >>> Peter M=C3=BCller >>>=20 >>>> - Update dma from 0.12 to 0.13 >>>> - No changelog information available >>>> - No change to the rootfile >>>>=20 >>>> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> >>>> --- >>>> lfs/dma | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>=20 >>>> diff --git a/lfs/dma b/lfs/dma >>>> index aceb2704e..78bb6465f 100644 >>>> --- a/lfs/dma >>>> +++ b/lfs/dma >>>> @@ -24,7 +24,7 @@ >>>>=20 >>>> include Config >>>>=20 >>>> -VER =3D 0.12 >>>> +VER =3D 0.13 >>>>=20 >>>> THISAPP =3D dma-$(VER) >>>> DL_FILE =3D $(THISAPP).tar.gz >>>> @@ -40,7 +40,7 @@ objects =3D $(DL_FILE) >>>>=20 >>>> $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) >>>>=20 >>>> -$(DL_FILE)_MD5 =3D 58cb2a286995381c92dc557e639622d6 >>>> +$(DL_FILE)_MD5 =3D 8bf824b065295a594f399c8b96663673 >>>>=20 >>>> install : $(TARGET) >>>>=20 >>>>=20 --===============7580435302068746058==--