2

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

So assume i have an alias [email protected]

which forwards mail to [email protected] and [email protected]

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:

<[email protected]> (expanded from <[email protected]>): 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 [email protected], 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 [email protected], that is rejected by foo.net server.

Delivered-To: [email protected]
Received: by 10.140.108.54 with SMTP id i51csp86667qgf;
        Thu, 24 Apr 2014 04:54:02 -0700 (PDT)
X-Received: by 10.14.246.1 with SMTP id p1mr2029071eer.20.1398340441786;
        Thu, 24 Apr 2014 04:54:01 -0700 (PDT)
Return-Path: <[email protected]>
Received: from bar.ru (bar.ru. [47.175.193.55])
        by mx.google.com with ESMTPS id p8si7998323eew.276.2014.04.24.04.54.01
        for <[email protected]>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Thu, 24 Apr 2014 04:54:01 -0700 (PDT)
Received-SPF: fail (google.com: domain of [email protected] does not designate 47.175.193.55 as permitted sender) client-ip=47.175.193.55;
Authentication-Results: mx.google.com;
       spf=hardfail (google.com: domain of [email protected] does not designate 47.175.193.55 as permitted sender) [email protected];
       dkim=pass [email protected]
Received: from mx.foo.net (mx.foo.net [144.76.75.247])
    by bar.ru (Postfix) with ESMTPS id BC4E9BC0031
    for <[email protected]>; Thu, 24 Apr 2014 15:54:00 +0400 (MSK)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=foo.net; s=default;
    h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Sr6qzI6M/AdTYgu33PjdinGA745C3GUCsXevUC1TgDI=;
    b=DpO1qnFhn+Srhuuj+2bzi4bUOoMOAr4tSRqK/sbz0gt5Ogp+RK9BJQTpix5oPoebo7M7MYIV+zHlzTdJnpPa0FSa4WTewvYxOE81CX/+k/VLQdK1SPcbdPSRACzKsS3Jq7QE9XKK1maW8s0syGbToGT/KNXHkeBKtP6QhIrUs3Y4=;
Envelope-to: [email protected]
Delivery-date: Thu, 24 Apr 2014 13:54:00 +0200
Message-ID: <[email protected]>
Date: Thu, 24 Apr 2014 14:53:54 +0300
From: Vitali R <[email protected]>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: [email protected]
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: Image for better understanding So the interesting part is this line

Received-SPF: fail (google.com: domain of [email protected] 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 [email protected], 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?

11
  • 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, 2014 at 14:02
  • I substituted IP addresses and domains, not to original, but perhaps to more understanding values.
    – Screatch
    Apr 24, 2014 at 14:12
  • That is even less helpful, as now it's not obvious what has and has not been redacted. See this question for an example of where having the underlying domain name was the only reason the answer was ever found.
    – MadHatter
    Apr 24, 2014 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, 2014 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, 2014 at 14:27

1 Answer 1

3

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.

  1. Don't create aliases with emails in domains you aren't responsible for. It's limiting, but the simplest way to resolve the issue.

  2. Use smtp_generic_maps, this will require creating entries to map the wrong address to a correct address, for example [email protected] [email protected], 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 [email protected] will rewrite any @foo.net address to [email protected], except [email protected]. 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.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .