Deliverability of mails sent by DMA: RFC headers issues, spam filtered, no messageID

[denigmus]

I liked the direct replacement for sendmail on FreeBSD, which works out of the box without any daemon in the system, with remote SMTP auth (the main reason I wanted replace sendmail, which is taught to configure for non-standard ports, etc...), but DMA doesn’t care about some simple things like basic RFC headers, which causes filtering emails on spam filters and unassuming appearance of emails (no To, no From, no default Subject). Neither it creats message id!

I know I can setup trusted network, I probably can forming headers in the "app" - in my case crontab's periodic tasks (which I never done for many years before, because sendmail did care about it), but I think it should be done on DMA's side.

So, as the result it hits the following scores:

1.0 MISSING_HEADERS Missing To: header
1.0 MISSING_FROM Missing From: header
1.8 MISSING_SUBJECT Missing Subject: header
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
1.4 MISSING_DATE Missing Date: header

Additionally:
Message-ID: GENERATED-WASMISSING-1gRdIz-000BsD-JS@MYSERVERNAMEHERE
X-ACL-Warn: Adding Message-ID header because it is missing!

Do you plan to fix it anytime soon?

[corecode]

Is it the job of the MTA to add those? So far I thought it should be the job of the application that produces the mail. Maybe your cron should submit the mail via mail(1)?

[denigmus]

I don't know who produces "FROM:" - either cron or sendmail, but either of them take it from envelope-from, because I don't set it implicitly. Never need to research because it works. With DMA it won't. Why couldn't DMA set FROM based on envelope-from?

"TO:" can be taken from envelope-to also, but I agree it's not the exact job of DMA, but good to have.

I'm sure that Date: and Message-ID: are both job for DMA as sendmail did it, definitely not the cron.
MTA (exim) will take care to fix missed Message-ID though.

UNPARSEABLE_RELAY - I don't know what's that, but I don't see it with submission via sendmail.

For "Subject:", sure it's job of the app, I overdid.

[corecode]

I'd love to consider a pull request for merging.

…

On 27/11/2018 16:49, denigmus wrote: I don't know who produces "FROM:" - either cron or sendmail, but either of them take it from envelope-from, because I don't set it implicitly. Never need to research because it works. With DMA it won't. Why couldn't DMA set FROM based on envelope-from? "TO:" can be taken from envelope-to also, but I agree it's not the exact job of DMA, but good to have. I'm sure that Date: and Message-ID: are both job for DMA as sendmail did it, definitely not the cron. MTA (exim) will take care to fix missed Message-ID though. UNPARSEABLE_RELAY - I don't know what's that, but I don't see it with submission via sendmail. For "Subject:", sure it's job of the app, I overdid. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#61 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK3OwGBGU9D_Kq2Nw0nN9O4iL64iDzPks5uzV77gaJpZM4Y1oa9>.

[bigon]

Using dma, when I'm doing echo foo | mail -s bar [email protected], the only problem I personally have is UNPARSEABLE_RELAY (with spamassassin 3.4.2)

[bigon]

FTR, postfix generate the following line:

Received: by foo.example.com (Postfix, from userid xxx)
	id 21BC51FEC8; Fri, 19 Jul 2019 19:08:08 +0200 (CEST)

[bigon]

Is it OK for you to use the same kind of output as postfix for the 1st Received lined?

[corecode]

sure, as long as it doesn't make the code more complicated.