Missing domain in To: header

[ghost]

Hello,

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

In my /etc/aliases file I have root defined as "[email protected]", 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 [email protected], 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 "[email protected]", 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: [email protected]

To: [email protected]

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.

[corecode]

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.

[ghost]

Do you have a suggestion on how I can change the To: header of an email sent by cron to local user "john" who is aliased to "[email protected]" ? Should we instead be using a .forward file?

[corecode]

Forward files do not change the header field either.

you could send it to [email protected], or directly to
[email protected].

[ghost]

Another approach would be to set MAILTO= in your crontab just before the entries you need to receive email for. (you can set MAILTO multiple times)

[citrin]

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

[citrin]

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: [email protected], [email protected]

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

[emaste]

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

[corecode]

So should we just add localdomain to all unqualified addresses?

[emaste]

So should we just add localdomain to all unqualified addresses?

Sounds reasonable to me

[bapt]

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

[emaste]

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

[gaaf]

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

[chw90]

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

[corecode]

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.

[chw90]

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.