Skip to content

Missing domain in To: header #21

Open
Open
Missing domain in To: header#21

Description

@ghost
ghost
opened on Apr 24, 2014

Hello,

dma seems to differ in behavior from other MTAs in the following scenario:

In my /etc/aliases file I have root defined as "root@foo.com", which is not local, so dma mails that off to a smarthost. It eventually hits spam filters before being delivered to my mail server. This is fine, except something very strange has happened: the message comes through with the correct envelope-to of root@foo.com, but the To: header
gets changed to "To: root@spamfilter(1|2|3).company.com".

At first I thought the problem was really a bug in my IMAP server, Archiveopteryx, which is known to modify email headers that are not RFC-compliant. This led to a discussion with one of its authors, Arnt Gulbrandsen. The thread in question can be found here: http://archives.aox.org/archives/mailstore-users/4734/thread

After further research I discovered that dma is sending this mail off the server without any domain in the To: header at all, because I'm specifying the alias name not a full email address. It traverses MTAs simply as "To: root" until it hits a Postfix server which will then append its own hostname! This apparently is known behavior; Postfix has done this for years. The real issue at hand is that when I recreate this exact scenario with Postfix, Exim, or Sendmail as the sending MTA on my server the To: header is set to "root@foo.com", my server's hostname.

Below you'll find that this behavior may not be correct anyway, but dma certainly differs from the behavior I expected after working with several other MTAs. The following is the important part of the mailing list thread where Arnt replies to himself to further detail the situation which I will paste below:

It isn't just Postfix, many MTAs do that.
"To: arnt" isn't legal syntax today, but it was legal a few
decades ago and quite commonly used for years after the syntax
changed (in, IIRC, 1982) and various MTAs still contains glue to
support that. I think that's mostly a bug these days. It landed
on the wrong side of the fence when servers learnt to
distinguish between their own users (for whom they will relay)
and others.

To elaborate on that:

In the old days, mail servers didn't really have much of an idea whether
they were serving their own user or someone else. Then came the spammers.
Today each and every mail server is loyal to either the sender or the
recipient of a message.

Ones loyal to the sender know something about the sender, and are willing
to send to the entire net on behalf of that sender. Ones loyal to the
recipient know nothing about the sender, and are willing to send only to
their own (or whitelisted) set of recipients.

My point here is that when the sender isn't authenticated, then there is no
reason to believe that the sender is in any way tied to the MTA's own
domain. If an MTA (for whatever reasons) has to add domains, then it can
use an RFC2606 domain such as buggy-sender.invalid or
unknown-domain.invalid:

To: root@buggy-sender.invalid

To: fred@unknown-domain.invalid

Those are safe and not likely to mislead any human readers. But gluing your
own domain name into mail from unauthenticated sources is bad, bad, bad.
Your own domain should only be used when carrying out the rewrites
mentioned in RFC4409, and that RFC only applies to authenticated senders.

Arnt

At this point I'm not sure what to suggest. Should dma behave as other MTAs do or should it do as Arnt suggests and use buggy-sender.invalid or unknown-domain.invalid? The former will give a more consistent experience, but the latter gives a more compliant experience. I almost feel that compliance is more important, but one thing is for sure -- dma shouldn't send mail off the server without a domain in the To: header.

Activity

  1. corecode commented on Apr 24, 2014

    @corecode
    corecode
    on Apr 24, 2014
    Owner

    DMA is just a MTA - the originating submitting entity should use a
    proper from/to address. I don't know either what to do. So far, DMA
    does not change headers in any way, and I think that's a reasonable
    approach.

  3. corecode commented on Apr 25, 2014

    @corecode
    corecode
    on Apr 25, 2014
    Owner

    Forward files do not change the header field either.

    you could send it to john@localhostname.domain, or directly to
    john.doe@gmail.com.

  5. citrin commented on Jan 15, 2015

    @citrin
    citrin
    on Jan 15, 2015

    +1
    It will be useful to rewrite incomplete To: and From: headers. Like done in Postfix with local_header_rewrite_clients and append_at_myorigin.

    Default Posfix behavior is to rewrite headers for local submitted mail. DMA used only for local submitted mail and may rewrite headers for all messages. It is not useful to send messages without domain in address to external world.

  6. citrin commented on Jan 15, 2015

    @citrin
    citrin
    on Jan 15, 2015

    MAILTO= in your crontab files is bad workaround:

    • it is easy to add N aliases to /etc/aliases like
    www: root
foobar: root
nobody: root
root: sysadmin1@example.org, sysadmin2@example.org
    • it is not easy to edit N crontab files (for www, nobody, e.t.c.) when sysadmin address need to be changed.

    Also it handy to configure other daemons like smartd to send mail to "root" address and then change only /etc/aliases.

  7. emaste commented on Jun 17, 2016

    @emaste
    emaste
    on Jun 17, 2016
    Collaborator

    I don't know either what to do.

    I'm not really sure either, but I think appending to the header fields is probably needed (perhaps under a config file option).

    FWIW this is one of two issues preventing DMA use in the FreeBSD cluster (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208262).

  8. corecode commented on Jun 20, 2016

    @corecode
    corecode
    on Jun 20, 2016
    Owner

    So should we just add localdomain to all unqualified addresses?

  9. emaste commented on Jun 20, 2016

    @emaste
    emaste
    on Jun 20, 2016
    Collaborator

    So should we just add localdomain to all unqualified addresses?

    Sounds reasonable to me

  10. bapt commented on Oct 20, 2016

    @bapt
    bapt
    on Oct 20, 2016
    Collaborator

    I believe this has been addressed 0ecb0eb can the reporter confirm?

  11. emaste commented on Feb 22, 2017

    @emaste
    emaste
    on Feb 22, 2017
    Collaborator

    For reference Debian bug reports:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697871
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830518

  12. gaaf commented on Nov 12, 2018

    @gaaf
    gaaf
    on Nov 12, 2018

    @bapt

    I believe this has been addressed 0ecb0eb can the reporter confirm?

    I'm not the reporter, but this commit does not fix the issue. The issue is about adding a domain to the To: (and From:) header in the email itself. The mentioned commit only changes the envelope-from.

  13. chw90 commented on Jan 28, 2023

    @chw90
    chw90
    on Jan 28, 2023

    Is there any established workaround for this issue considering it's standing since 2014?

  14. corecode commented on Jan 28, 2023

    @corecode
    corecode
    on Jan 28, 2023
    Owner

    Use a correct To: address, (e.g. MAILTO= in crontab), or configure your smarthost so that it will accept those mails.

    @chw90 can you explain what problem you're trying to solve? To: should be just visual and shouldn't be used for mail routing.

  15. chw90 commented on Jan 28, 2023

    @chw90
    chw90
    on Jan 28, 2023

    I was trying to redirect system mails to root via e-mail, but I have just understood and configured things wrong, see here.

    Sorry for the noise.

  16. mij commented on Feb 13, 2025

    @mij
    mij
    on Feb 13, 2025

    As a solutiom:

    Install ssmtp.

    Configure ssmtp:

    # file /usr/local/etc/ssmtp/ssmtp.conf

root=postmaster
mailhub=your.relayhost.com

    Replace dma with ssmtp as default mailer:

    # file /etc/mail/mailer.conf

sendmail	/usr/local/sbin/ssmtp
send-mail	/usr/local/sbin/ssmtp
mailq		/usr/local/sbin/ssmtp -bp
newaliases	/usr/local/sbin/ssmtp

  17. pacija commented on Sep 30, 2025

    @pacija
    pacija
    on Sep 30, 2025

    It's not just about missing domain, it's about only partially respecting /etc/aliases in a way that mail gets forwarded to aliased email address, while To: field in header remains the original receiver.

    We have discussion about this in FreeBSD bugzilla, since FreeBSD recently replaced sendmail with dma as default MTA.

    Is there a chance dma will change To: field to match aliased receiver address sometime in the future or FreeBSD should patch their version on their own if they wish such functionality?

    ssmtp has been unmaintained since 2019, I don't think it's appropriate to advise anyone to use it.

  18. corecode commented on Oct 1, 2025

    @corecode
    corecode
    on Oct 1, 2025 via email
    Owner
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