Postfix alias and "impersonating" issue

Question

I recently started configuring addresses on my postfix server and stumbled into an issue with my colleagues.

So assume i have an alias testing@bar.ru

which forwards mail to somedude@gmail.com and vitali.r@foo.net

In case we send to the same domain, the alias is, everything works perfectly well and email is delievered, but lets dig deeper into otherdomain issue as email immediately bounces back with this error:

<vitali.r@foo.net> (expanded from <alias@somedomain.com>): host
mx.foo.net[144.76.75.247] said: 550 You must be authenticated (in
reply to RCPT TO command)

Fortunately, owners of this otherdomain are my colleagues, so I addressed this question to them first. We did some digging and figured it out, that email is not just simply sent from vitali.r@foo.net, but rather is sent impersonating some one else.

To get a better understanding in this issue, I advise you to take a look at the headers of delivered email to somedude@gmail.com, that is rejected by foo.net server.

Received-SPF: fail (google.com: domain of vitali.r@foo.net does not designate 47.175.193.55 as permitted sender) client-ip=47.175.193.55;
Envelope-to: testing@bar.ru
Delivery-date: Thu, 24 Apr 2014 13:54:00 +0200
Message-ID: <5358FB52.8040508@foo.net>
Date: Thu, 24 Apr 2014 14:53:54 +0300
From: Vitali R <vitali.r@foo.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: testing@bar.ru
Subject: hello world this is alias test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

testest

Image for better understanding: So the interesting part is this line

Received-SPF: fail (google.com: domain of vitali.r@foo.net does not designate 47.175.193.55 as permitted sender) client-ip=47.175.193.55;

And he will be correct, 11.111.111.11 indeed does not designate to otherdomain.com, as 47.175.193.55 is the IP of server, through which the email was sent (via alias).

So simply speaking, server impersonates itself that email is sent from vitali.r@foo.net, while in reality it was sent from bar.ru and my colleague server rejects a letter because of that.

I understand this may seem confusing but see at this way. You can send a letter to pretty much any server, telling server that you sent it from an email, that you clearly do not has access to. This is pretty much what happens with alias issue here.

How would you react to this kind of issue and do you think that rejecting email is appropriate here?

It's quite hard to follow what's going on with all these redacted domains. Please seriously consider editing your question to be the real domains and IP addresses back in. The usernames are of less interest and can probably be left out, but the domain names are often a big help in working out what's going on. — MadHatter, Apr 24 '14 at 14:02
I substituted IP addresses and domains, not to original, but perhaps to more understanding values. — Screatch, Apr 24 '14 at 14:12
That is even less helpful, as now it's not obvious what has and has not been redacted. See [this question](http://serverfault.com/questions/485137/lame-dns-server) for an example of where having the underlying domain name was the only reason the answer was ever found. — MadHatter, Apr 24 '14 at 14:18
The SPF fail says foo.net (whatever it is really) is saying that 47.175.193.55 (bar.ru in your headers) is not an address that should be sending email claiming to come from foo.net. — NickW, Apr 24 '14 at 14:22
This is exactly what is happening with aliases, this happens when you send email via alias, sender gets substituted to the alias server, instead of original sender and therefore rejected by my colleagues server. I am deeply sorry for changing out domain names but I can't really throw it out in public, sorry. My question is basically, is it appropriate to reject these kind of emails, in your opinion? — Screatch, Apr 24 '14 at 14:27
That is fairly normal, otherwise, anyone could claim to be sending mail for foo.net, which is what spf was created to hinder. In your example, Gmail accepted the message, because there are situations when this could happen (an aliased message, or a badly configured spf record, to name a few). Foo.net doesn't want to accept mail that claims to be from foo.net because it allows only authenticated users to claim they are from foo.net. — NickW, Apr 24 '14 at 14:27
Or try sending from `screatch@gmail.com` to `testing@bar.ru` — NickW, Apr 24 '14 at 14:31
Any particular guide how to do this with postfix / dovecot configuration for aliases? Yeah and I can't send it directly as it is sent via alias, the question is with alias here. — Screatch, Apr 24 '14 at 14:31
It would be helpful to have the real domain names/IP addresses in question here. See [What information should I include or obfuscate in my posts?](http://meta.serverfault.com/q/963/126632) — Michael Hampton, Apr 24 '14 at 16:33

score 3 · Accepted Answer · answered Apr 24 '14 at 16:00

The way that postfix is receiving the mail and forwarding it to the aliases is completely correct. Of course, since the sender is from an external domain, and you have created an alias to an external domain, the receiving server will note that you really shouldn't be sending mail from a domain which you are not responsible for. Some servers object to mail being sent to them, claiming to come from a domain for which they are responsible. This isn't unreasonable, and given the amount of spam sent nowadays maybe even wise.

There are multiple ways to resolve this.

Don't create aliases with emails in domains you aren't responsible for. It's limiting, but the simplest way to resolve the issue.
Use smtp_generic_maps, this will require creating entries to map the wrong address to a correct address, for example vitali.r@foo.net vitali@bar.ru, of course, this will require an entry for each email you want to map, and a generic one for emails you don't know: @foo.net info@bar.ru will rewrite any @foo.net address to info@bar.ru, except vitali.r@foo.net. This has the side effect of eliminating the original sender.. which isn't great, if you'd like to reply to the person who sent the original message.
If the server that the alias is being sent to is your account, sender_dependent_relayhost_maps could be a valid solution, as it allows postfix to provide the authentication the remote server asks for in that case. Shortcomings: it will only provide authentication when the sender is the one configured in the map, and of course, it will only resolve the issue of that single server. If you only have a few examples of situations like this, it might be the best way of going about it however..

Postfix alias and "impersonating" issue

1 Answers1