The content of the Received:
header is defined in Exim by the configuration option received_header_text
. The default setting, from which you can see how your example is constructed, is:
received_header_text = Received: \
${if def:sender_rcvhost {from $sender_rcvhost\n\t}\
{${if def:sender_ident \
{from ${quote_local_part:$sender_ident} }}\
${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
by $primary_hostname \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
(Exim $version_number)\n\t\
${if def:sender_address \
{(envelope-from <$sender_address>)\n\t}}\
id $message_exim_id\
${if def:received_for {\n\tfor $received_for}}
As for changing or remove the header. Beware some best practice advice lies ahead..
Are you sure that you want to remove this information? It's presence allows you to track abuse reports much more easily. The exposure of your internal IP addresses is actually of fairly limited risk.
Technically you can remove this first received header by using headers_remove
but it's certainly not RFC friendly and there is a chance of creating mail loops.
If you must mask the information then you would be best to do so by modifying received_header_text
. For maintainability and the principle of least surprise, even if the MTA isn't performing any other functions, you probably want to make your changes as specific as possible. This would involve putting some additional conditions in those if
statements for facts that you know will always be true, such as whether the sender has authenticated themselves.
The empty MAIL FROM
is used for delivery status notifications. Mail servers are required to support it (RFC 1123 section 5.2.9).
It’s used primarily for bounce messages, to prevent an endless loop. When MAIL FROM
is used with an empty address (represented as <>
), the receiving server knows not to generate a bounce message if the message is being sent to a non-existent user.
Without this, it might be possible for someone to DoS you simply by faking a message to a non-existent user at another domain, with a return address of a non-existent user at your own domain, resulting in a never-ending loop of bounce messages.
What would happen if you block messages with an empty MAIL FROM:
?
- Your users would not get bounce messages from other domains: they would never know if they made a typo when sending mail to a user at another domain.
The empty MAIL FROM:
messages that you are seeing are probably not coming from a spammer.
Instead, a spammer has faked an address at your domain and used it as the return address for a message to another domain. Let’s say you are yourdomain.com
and my domain is mydomain.net
. The spammer sends a message to johnq@mydomain.net
, faking the return address as johnq@yourdomain.com
. Since there is no user johnq
in my domain, my mail server sends a bounce message (MAIL FROM:<>
) to the apparent sender, johnq@yourdomain.com
. That is what you are probably seeing.
Blocking empty MAIL FROM
messages will do more harm than good, in my opinion. Spammers, in my experience, rarely use an empty MAIL FROM:
since they can easily fake a real-looking address. When the message is actual spam, there are far better ways to detect and block it, including RBLs, Bayesian filters, and SpamAssassin.
And finally, you can prevent at least some of the forgeries using yourdomain.com
by setting up proper SPF records for your domain.
Update: After looking closer at your log, someone was able to AUTH
using a valid username and password for your server. This puts it in a whole other category of trouble. However, everything I said about MAIL FROM:
still stands. 99% of the time it’s going to be the result of bounce messages.
Best Answer
Postfix offers the ability to forward to different servers based on the recipient username by using transport tables. These tables can be stored as text files or in a database. For example:
Source: http://www.postfix.org/transport.5.html
Per-user transport tables could be used to enable a smooth gradual migration.
All users who are still using the legacy POP3 system can retain their SMTP settings, as long as that server is doing an MX lookup for users in the same domain. It won't work if their outgoing server is authoritative for the domain. It's possible that users on Exchange Server won't be able to send messages to users on the legacy system because messages will be delivered to the mailbox on Exchange Server.
To make this even more convenient for the sysadmin, Postfix could be integrated with a MySQL database and a web application that allows mail delivery to be toggled for batches of users.