Cron mail is rejected due to missing domain #75

varac · 2020-02-05T12:59:32Z

I'm using this configuration:

root@brix:/etc/dma# grep -vE '(^$|^#)' dma.conf
SMARTHOST localhost
MAILNAME /etc/mailname
MASQUERADE [email protected]

to send all mails to a docker container running an smtp replay which accepts mail on port 25 and forwards it to
a mail hub using smtp auth.

I can send mail fine using the mail command like this:

echo hi | mail root

But cronmail is rejected because the From: header is root (Cron Daemon) without any domain.
My smtp relay rejects it with these message:

H=(brix.MY.DOMAIN) [172.17.0.1] F=<[email protected]> rejected after DATA: header syntax (unqualified address not permitted: failing address in "From:" header is: roo

t (Cron Daemon)): unqualified address not permitted: failing address in "From:" header is: root (Cron Daemon)

Shortly after that, a bounce notification is also rejected:

H=(brix.MY.DOMAIN) [172.17.0.1] F=<> rejected after DATA: header syntax (missing or malformed local part: failing address in "From:" header is: MAILER-DAEMON <>): missing or malformed local part: failing address in "From:" header is: MAILER-DAEMON <>

And i end up having 2 mails in the /var/spool/dma/ spool directory:

root@brix:/etc# cat /var/spool/dma/M22152e.55d8f3dcc2f0
Received: from MAILER-DAEMON
        id 22152e
        by brix.MY.DOMAIN (DragonFly Mail Agent v0.11);
        Wed, 05 Feb 2020 13:46:02 +0100
X-Original-To: <[email protected]>
From: MAILER-DAEMON <>
To: [email protected]
Subject: Mail delivery failed
Message-Id: <[email protected]>
Date: Wed, 05 Feb 2020 13:46:02 +0100

This is the DragonFly Mail Agent v0.11 at brix.MY.DOMAIN.

There was an error delivering your mail to <[email protected]>.

localhost [::1] did not like our final DATA:
550 header syntax

Message headers follow.

Received: from root (uid 0)
        (envelope-from [email protected])
        id 22152a
        by brix.MY.DOMAIN (DragonFly Mail Agent v0.11);
        Wed, 05 Feb 2020 13:46:01 +0100
From: root (Cron Daemon)
To: root
Subject: Cron <root@brix> fhkqrjhfb
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Date: Wed, 05 Feb 2020 13:46:01 +0100
Message-Id: <[email protected]>

root@brix:/etc# cat /var/spool/dma/Q22152e.55d8f3dcc2f0
ID: 22152e.55d8f3dcc2f0
Sender:
Recipient: [email protected]

What am I doing wrong ? Unfortunatly you can't configure the From address for cron mails, so there's nothing I can do about this on cron's side.

The text was updated successfully, but these errors were encountered:

varac · 2020-02-05T13:02:56Z

I also saw Make MASQUERADE config setting override -f
and tried latest master, but if I understand correctly, MASQUERADE only sets the envelope from, not the from header right ?

corecode · 2020-02-05T15:58:27Z

That is correct, we don't rewrite header lines. You probably should configure your smarthost not to reject mails originating from your machines/cron.

varac · 2020-02-05T17:03:45Z

But what happens when delivering directly to an smtp server which is not under my control ? I.e. the one from my mail provider ?
I think it would be a great feature to append the MAILNAME to any from address without a specific domain. This would solve this issue out of the box.

varac · 2020-02-05T17:04:57Z

If I'm not mistaken this is basically the discussion held in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697871, or am I wrong ?

corecode · 2020-02-05T17:30:09Z

would you like to submit a PR for review?

…

On 05/02/2020 18:03, Varac wrote: But what happens when delivering directly to an smtp server which is not under my control ? I.e. the one from my mail provider ? I think it would be a great feature to append the |MAILNAME| to any |from| address without a specific domain. This would solve this issue out of the box. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#75?email_source=notifications&email_token=AABLOO7IHIJJY2BAATOKSQTRBLWPFA5CNFSM4KQKU26KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK4GC6Y#issuecomment-582508923>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOO4Z4CLG7MRC3B4UHOLRBLWPFANCNFSM4KQKU26A>.

varac · 2020-02-05T20:31:35Z

would you like to submit a PR for review?

I would, but I can't since I haven't written a single line of C in my whole life!

varac · 2020-02-05T20:32:13Z

But I'm happy to test any PR and give feedback.

vlyon · 2020-02-07T11:44:46Z

If I'm not mistaken this is basically the discussion held in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697871, or am I wrong ?

Actually this is discussed here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830518, but is related to the one you mentioned. That bug has been partially fixed, but the unqualified To: and From: headers are not being corrected.

vlyon · 2020-02-07T11:53:07Z

See related issue #21

varac · 2020-02-07T12:40:25Z

Actually this is discussed here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830518

@vlyon Thanks for the correct link, this debian bug report describes my issue pretty well.

varac · 2020-02-12T12:19:47Z

@corecode Is there any chance to get this fixed soon ? Without this I need to look for another alternative, since recieving system/cron-mails is pretty important for me.

corecode · 2020-02-12T12:30:23Z

Not by me - happy to review and merge pull requests.

…

On 12/02/2020 13:19, Varac wrote: @corecode <https://github.com/corecode> Is there any chance to get this fixed soon ? Without this I need to look for another alternative, since recieving system/cron-mails is pretty important for me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75?email_source=notifications&email_token=AABLOO6TMWCXFNQM526GAW3RCPSOHA5CNFSM4KQKU26KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQSEEI#issuecomment-585179665>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOO4IELZ4GDVVCY5TWRLRCPSOHANCNFSM4KQKU26A>.

trevor87 · 2020-09-04T16:39:22Z

@corecode Is there any chance to get this fixed soon ? Without this I need to look for another alternative, since recieving system/cron-mails is pretty important for me.

Did you find a solution to this? I am also having trouble to get DMA to work with anything else than gmail (e.g. gmx.net does not work).

vlyon · 2020-09-07T10:10:37Z

I have found a workaround for this issue, and have been using it for some time now on Debian.

I use a simple perl script that I've written, to send email from cron via DMA.

In my crontab I have the following line:
SHELL=/home/somewhere/bin/cronsh

Then the cronsh script contains:

#!/usr/bin/perl -CA
use 5.024;
use warnings;
use IPC::Run3;
use Email::Stuffer;

@ARGV == 2 and $ARGV[0] eq '-c' or die "Usage:\n$0 -c <command>\n";
my $out;
run3 $ARGV[1], undef, \$out, \$out, {return_if_system_error => 1};
if ($? or length $out) {
    utf8::decode $out;
    $out .= $! if $?;
    $out = Email::Stuffer
    ->from("Cron <$ENV{LOGNAME}\@myhostname.com>")
    ->to('"Vernon Lyon" <[email protected]>')
    ->subject($ARGV[1])
    ->text_body($out, encoding => '8bit')
    ->as_string;
    run3 [qw(/usr/sbin/dma -it)], \$out;
}

jjakob · 2021-04-12T12:46:07Z

I've added header From rewriting to dma. I'll open a PR.

corecode · 2021-04-12T14:51:18Z

thanks!

…

On 12/04/2021 07:46, Jernej Jakob wrote: I've added header From rewriting to dma. I'll open a PR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOOZB3GDCNN6QA4TIPODTILTSFANCNFSM4KQKU26A>.

jjakob · 2021-04-14T15:36:49Z

#96

HenriGEIST · 2024-09-05T09:27:35Z

If it can help I had the same problem and I have solved it by applying this diff against tag 'v0.13'

`
$ git diff
diff --git a/mail.c b/mail.c
index bf82d52..c0caae8 100644
--- a/mail.c
+++ b/mail.c
@@ -397,7 +397,9 @@ readmail(struct queue *queue, int nodot, int recp_from_header)
* Ignore a leading RFC-976 From_ or >From_ line mistakenly
* inserted by some programs.
*/

                  if (strprefixcmp(line, "From ") == 0 || strprefixcmp(line, ">From ") == 0)

                  if (strprefixcmp(line, "From ")                    == 0 ||

                      strprefixcmp(line, ">From ")                   == 0 ||

                      strprefixcmp(line, "From: root (Cron Daemon)") == 0)
                          continue;
                  had_first_line = 1;
          }

`

It simply reject the first
From: root (Cron Daemon)
As invalid just like firsts "From " and ">From ".
And in fact this is not a valid expeditor (At least in my point of view)

Drop the anyway malformed "From: root (Cron Daemon)" That cron daemon place by default at head of its messages. Just like mistakenly inserted RFC-976 "From_" or ">From_" are already dropped. When not removed, lot of modern mail delivery service will reject or silently drop the message. Only some very new version of cron can change this behavior and it is not the default. On old version there is nothing you can do. When removed the expediter is available anyway by the mail envelop. Then no meaningful information is lost.

corecode · 2024-09-06T15:32:35Z

From: root (Cron Daemon) is not invalid. The receiving mail server is configured to reject it.

HenriGEIST · 2024-09-06T16:49:38Z

OK may be not strictly speaking "invalid" by RFC criteria.
But wired, and rejected by all 3 smarthosts I have tried :

"smtp.gmail.com";
"mail.gandi.net";
"smtp.laposte.net".

If most mail provider reject it, for my usage it is the same as "invalid".

I will keep the workaround on my fork as long as I have no better solution to get my cron report to find their way to my mailbox.
If it help someone else that's good. If not there is no harm.

corecode · 2024-09-06T19:26:21Z

do the providers also reject it if you authenticate for delivery?

On September 6, 2024 11:50:01 AM CDT, HenriGEIST ***@***.***> wrote: OK may be not strictly speaking "invalid" by RFC criteria. But wired, and rejected by all 3 smarthosts I have tried : - "smtp.gmail.com"; - "mail.gandi.net"; - "smtp.laposte.net". If most mail provider reject it, for my usage it is the same as "invalid". I will keep the workaround on my fork as long as I have no better solution to get my cron report to find their way to my mailbox. If it help someone else that's good. If not there is no harm. -- Reply to this email directly or view it on GitHub: #75 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

HenriGEIST · 2024-09-06T19:59:05Z

I am not sure what you mean by "authenticate" but I always use login and password on the SMTP before sending a mail.
If I don't nothing goes by what ever I do with the "From:" line in the mail content.

My /etc/dma/dma.conf contain :

`
SMARTHOST mail.gandi.net

PORT 465

ALIASES /etc/aliases

AUTHPATH /etc/dma/auth.conf

SECURETRANSFER

MAILNAME /etc/mailname

MASQUERADE [email protected]
`

And my /etc/dma/auth.conf contain :

[email protected]|mail.gandi.net:WWWWWW

Everything work well with the patch and fail silently without it.
No error message, /var/log/mail.log say "[email protected] delivery successful"
Just without the patch the mail never reach destination.

corecode · 2024-09-06T21:22:38Z

that seems like a big problem with gandi.net. it should never discard a message once it accepts it.

On September 6, 2024 2:59:26 PM CDT, HenriGEIST ***@***.***> wrote: I am not sure what you mean by "authenticate" but I always use login and password on the SMTP before sending a mail. If I don't nothing goes by what ever I do with the "From:" line in the mail content. My /etc/dma/dma.conf contain : ` SMARTHOST mail.gandi.net PORT 465 ALIASES /etc/aliases AUTHPATH /etc/dma/auth.conf SECURETRANSFER MAILNAME /etc/mailname MASQUERADE ***@***.*** ` And my /etc/dma/auth.conf contain : ` ***@***.***|mail.gandi.net:WWWWWW ` Everything work well with the patch and fail silently without it. No error message, /var/log/mail.log say ***@***.***> delivery successful" Just without the patch the mail never reach destination. -- Reply to this email directly or view it on GitHub: #75 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

HenriGEIST · 2024-09-06T21:25:04Z

Maybe but exact same situation with 'smtp.laposte.net'.

HenriGEIST · 2024-09-06T21:27:23Z

But in fact I do not now where exactly it is discarded.
Could be any intermediary server between the first smart host and the final pop/imap delivery server.
Could be an anti spam anywhere.

trevor87 mentioned this issue Oct 30, 2022

Replace from header function #112

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cron mail is rejected due to missing domain #75

Cron mail is rejected due to missing domain #75

varac commented Feb 5, 2020

varac commented Feb 5, 2020

corecode commented Feb 5, 2020

varac commented Feb 5, 2020

varac commented Feb 5, 2020

corecode commented Feb 5, 2020 via email

varac commented Feb 5, 2020

varac commented Feb 5, 2020

vlyon commented Feb 7, 2020

vlyon commented Feb 7, 2020

varac commented Feb 7, 2020

varac commented Feb 12, 2020

corecode commented Feb 12, 2020 via email

trevor87 commented Sep 4, 2020

vlyon commented Sep 7, 2020

jjakob commented Apr 12, 2021

corecode commented Apr 12, 2021 via email

jjakob commented Apr 14, 2021

HenriGEIST commented Sep 5, 2024

corecode commented Sep 6, 2024

HenriGEIST commented Sep 6, 2024

corecode commented Sep 6, 2024 via email

HenriGEIST commented Sep 6, 2024 •

edited

Loading

corecode commented Sep 6, 2024 via email

HenriGEIST commented Sep 6, 2024

HenriGEIST commented Sep 6, 2024

Cron mail is rejected due to missing domain #75

Cron mail is rejected due to missing domain #75

Comments

varac commented Feb 5, 2020

varac commented Feb 5, 2020

corecode commented Feb 5, 2020

varac commented Feb 5, 2020

varac commented Feb 5, 2020

corecode commented Feb 5, 2020 via email

varac commented Feb 5, 2020

varac commented Feb 5, 2020

vlyon commented Feb 7, 2020

vlyon commented Feb 7, 2020

varac commented Feb 7, 2020

varac commented Feb 12, 2020

corecode commented Feb 12, 2020 via email

trevor87 commented Sep 4, 2020

vlyon commented Sep 7, 2020

jjakob commented Apr 12, 2021

corecode commented Apr 12, 2021 via email

jjakob commented Apr 14, 2021

HenriGEIST commented Sep 5, 2024

corecode commented Sep 6, 2024

HenriGEIST commented Sep 6, 2024

corecode commented Sep 6, 2024 via email

HenriGEIST commented Sep 6, 2024 • edited Loading

corecode commented Sep 6, 2024 via email

HenriGEIST commented Sep 6, 2024

HenriGEIST commented Sep 6, 2024

HenriGEIST commented Sep 6, 2024 •

edited

Loading