Emil CHERICHES

Emil CHERICHES

modern days aliases

February 11, 2014 Emil C
No Comments

Asuming we have on a mail server(that hosts domain1.com) some external aliases, like user1@domain1.com has an alias for user1@domain2.com, which is hosted on a different server, probably on a different mail provider. Typically when a mail is sent to user1@domain1.com, it’s sender’s mail server sends the mail to the MX which hosts domain1.com the mail is accepted, but being an alias the domain1.com MX tries to send it again to user1@domain2.com.

This didn’t used to be a problem few years back when methods like SPF or Sender-ID didn’t existed and the server hosting the domain2.com email would not check if the server identifying as the original sender’s mail server is legit or not.

Sadly, nowadays this wouldn’t work, the domain2.com MX would reject the mail just because the domain1.com MX is not the MX for the original sender.

So, the domain1.com mail server needs to alter this email so that domain2.com’s MX believes the mail comes from user1@domain1.com.

In Postfix this type of configuration is quite simple. The first thing to set the virtual_alias_maps table and put into it user1@domain1.com as an alias to a local account, something like

user1@domain1.com user1

The next step is to modify the local alias map, typically situated in the file /etc/aliases and put something like:

user1:  "|/opt/redirector user1@domain1.com user1@domain2.com"

Then we need to create the /opt/redirector script, which has only two lines:

#!/bin/sh
/usr/sbin/sendmail -bm -f $1 $2

the script needs to be executed

chmod +x /opt/redirector

some database update

postmap /etc/postfix/virtualnewaliases

restart postfix(probably not really necessary) and voila!

 

Image credits.

Tips & Tricks Postfix
Previous Post

RedHat and CentOS

Next Post

Linux still sucks (in 2014)

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recent Posts
  • Debian on BTRFS with subvolumes
  • NixOS TIP: OTP in Gnome login screen
  • Arch to Manjaro – the dirty way
  • The anatomy of a smart bulb
  • OpenVPN on 443
Categories
  • from the web
  • just blog
  • linux
    • Debian
    • NixOS
  • phones
  • Phones & Tablets
  • programing
  • security
  • Smart Home
  • Tips & Tricks
  • Uncategorized
  • Web development
  • Windows
Blogroll
  • cheriches.fr
Subscribe by Email
Recent Posts
  • Debian on BTRFS with subvolumes
  • NixOS TIP: OTP in Gnome login screen
  • Arch to Manjaro – the dirty way
  • The anatomy of a smart bulb
  • OpenVPN on 443
Categories
  • from the web (3)
  • just blog (1)
  • linux (20)
    • Debian (1)
    • NixOS (1)
  • phones (1)
  • Phones & Tablets (2)
  • programing (1)
  • security (2)
  • Smart Home (1)
  • Tips & Tricks (16)
  • Uncategorized (1)
  • Web development (1)
  • Windows (1)
Blogroll
  • cheriches.fr
Tags cloud
adb ADS aircrack-ng Android Apache apt-get Arch BTRFS CentOS Chrome Cluster CSS debian Docker Firefox firmware flashing GNOME Google Authenticator High Availability HTTPS javascript KVM linux Manjaro MySQL OpenBeken OpenBK7231T OpenVPN OTP php piwik Postfix Proxy_ARP release RHEL Samba ssh Tuya ubuntu UEFI VPN VRRP windows Youtube
Recent Comments
  • Greg M on The anatomy of a smart bulb
  • The anatomy of a smart bulb #LED @EmilsBits « Adafruit Industries – Makers, hackers, artists, designers and engineers! on The anatomy of a smart bulb
  • Emil C on The anatomy of a smart bulb
  • David Brower on The anatomy of a smart bulb
  • 智能灯泡的解剖 - 偏执的码农 on The anatomy of a smart bulb
Proudly powered by WordPress | Theme: Fmi by Forrss.
Manage Cookie Consent
We use cookies to optimize our website and our service.
Functional cookies Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}