dma: Update to 0.13

  - 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(-)
  

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@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)
>  
>
  

Hi Peter & *

On 28/01/2021 21:36, Peter Müller 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:
I was also surprised that there was no changelog info. Sometimes the programmers seem to make the changelogs well hidden but I had searched and searched and not found anything this time.
Your approach of extracting info out of the commits is something I will remember for the future.
> 
> 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.
That does sound a bit fundamental to have been missed previously but then this software is also a long way from version 1.0. It's taken 10 years to get from V0.1 V0.13
> 
> 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)
>>   
>>
  

On Jan 28, 2021, at 5:54 PM, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Peter & *
> 
> On 28/01/2021 21:36, Peter Müller wrote:

[snip]

>> 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.
> That does sound a bit fundamental to have been missed previously but then this software is also a long way from version 1.0. It's taken 10 years to get from V0.1 V0.13
>> 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

[snip]

I have run Communicate Pro as our MTA for years, and it has a tendency to be RFC compliant to a fault, even occasionally breaking interactions with other widely available mail servers ([cough] Exchange [cough]) when those mail servers are not 100% compliant, and I can say that it doesn’t surprise me that this sort of thing would be out there. I suspect that most servers accept the mail when submitted the way that dma has been doing it up to now, but someone found a particular piece of software that refused to accept messages with multiple recipients because that is not RFC compliant, necessitating the fix.

At least the silver lining here is that they have identified and fixed the problem.

Tom
  

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:
> 
> 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@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)
>> 
>>
  

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:
>>
>> 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@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)
>>>
>>>
>
  

Hi,

> On 30 Jan 2021, at 12:47, Peter Müller <peter.mueller@ipfire.org> wrote:
> 
> 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.

Long-term I do not see any other solution than Postfix. It is small enough and 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üller <peter.mueller@ipfire.org>
> 
> Thanks, and best regards,
> Peter Müller

-Michael

> 
>> 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:
>>> 
>>> 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@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)
>>>> 
>>>>