Skip to content

Cron mail is rejected due to missing domain #75

Open

Description

@varac

I'm using this configuration:

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

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=<root@brix.MY.DOMAIN> 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: <varac@MY.DOMAIN>
From: MAILER-DAEMON <>
To: root@brix.MY.DOMAIN
Subject: Mail delivery failed
Message-Id: <22152e@brix.MY.DOMAIN>
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 <varac@MY.DOMAIN>.

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

Message headers follow.

Received: from root (uid 0)
        (envelope-from root@brix.MY.DOMAIN)
        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: <5e3ab909.22152a.4756bd5d@brix.MY.DOMAIN>
root@brix:/etc# cat /var/spool/dma/Q22152e.55d8f3dcc2f0
ID: 22152e.55d8f3dcc2f0
Sender:
Recipient: varac@MY.DOMAIN

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.

Activity

  1. varac commented on Feb 5, 2020

    @varac
    Author

    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 ?

  2. corecode commented on Feb 5, 2020

    @corecode
    Owner

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

  3. varac commented on Feb 5, 2020

    @varac
    Author

    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.

  4. varac commented on Feb 5, 2020

    @varac
    Author

    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 ?

  5. corecode commented on Feb 5, 2020

    @corecode
    Owner
  6. varac commented on Feb 5, 2020

    @varac
    Author

    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!

  7. varac commented on Feb 5, 2020

    @varac
    Author

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

  8. vlyon commented on Feb 7, 2020

    @vlyon

    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.

  9. vlyon commented on Feb 7, 2020

    @vlyon

    See related issue #21

  10. varac commented on Feb 7, 2020

    @varac
    Author

    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.

  11. varac commented on Feb 12, 2020

    @varac
    Author

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

  12. corecode commented on Feb 12, 2020

    @corecode
    Owner
  13. trevor87 commented on Sep 4, 2020

    @trevor87

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

  14. vlyon commented on Sep 7, 2020

    @vlyon

    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" <myaddr@somewhere.com>')
        ->subject($ARGV[1])
        ->text_body($out, encoding => '8bit')
        ->as_string;
        run3 [qw(/usr/sbin/dma -it)], \$out;
    }
    
  15. jjakob commented on Apr 12, 2021

    @jjakob
    Contributor

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

  16. corecode commented on Apr 12, 2021

    @corecode
    Owner
  17. jjakob commented on Apr 14, 2021

    @jjakob
    Contributor
  18. HenriGEIST commented on Sep 5, 2024

    @HenriGEIST

    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)

  19. added a commit that references this issue on Sep 6, 2024
    2e96816
  20. corecode commented on Sep 6, 2024

    @corecode
    Owner

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

  21. HenriGEIST commented on Sep 6, 2024

    @HenriGEIST

    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.

  22. corecode commented on Sep 6, 2024

    @corecode
    Owner
  23. HenriGEIST commented on Sep 6, 2024

    @HenriGEIST

    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 XXXXXXX@YYYYYYY.ZZZ
    `

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

    XXXXXXX@YYYYYYY.ZZZ|mail.gandi.net:WWWWWW

    Everything work well with the patch and fail silently without it.
    No error message, /var/log/mail.log say "aaaaaaa@bbbbbbb.ccc delivery successful"
    Just without the patch the mail never reach destination.

  24. corecode commented on Sep 6, 2024

    @corecode
    Owner
  25. HenriGEIST commented on Sep 6, 2024

    @HenriGEIST

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

  26. HenriGEIST commented on Sep 6, 2024

    @HenriGEIST

    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.

  27. e-minguez commented on Feb 18, 2025

    @e-minguez
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions