Re: [SLE] SMTP authentication

Hylton Conacher (ZR1HPC) wrote:

Network planning mode ON :)

Postfix merely tries to send a mail off. This might require an internet connection when the mail is destined for an external server. Now it is your task to decide how the system should react:

- either defer all outgoing mails until you connect to the internet, then flush out all the mails in the queue. That would be appropriate for a dial-up connection. Postfix should not accept mails directly from the internet in that case. That should be done by the ISP that is hosting your mail domain. Your local server would use an external program like fetchmail to poll the mailserver of your ISP, download the mails and feed them to Postfix.

This is the method I would use.

Please take into account that this is a bit of a hack, that means a mailserver was never intended to only have a temporary connection. Though it should work without much problem.

On the other hand, you won't get most of the advantages of a permanent mailserver. The restrictions that I have set on my mailserver allow me to post freely to all the mailing lists and yet stay free of spam. Those restrictions are only possible with a mailserver, that is directly receiving the mails.

The check "reject_unauth_destination" is one of the most important checks when you configure Postfix. This check rejects all mails that Postfix can not deliver locally and would have to send out to the internet!
"unauth_destination" in this case are all recipient addresses that Postfix itself is not responsible for. All other recipient addresses are rejected. The log then says "Relay access denied".

In other words, this test separates the trusted clients that either belong to mynetworks or have authenticated and thus are allowed to relay mails through this server, or the untrusted clients that may only send mails that this server feels responsible for.

There is a bit of confusion creeping in here when you say that the SMTP is not responsible for. An SMTP server is responsible only for sending

That is not correct. A mailserver usually is responsible for sending AND receiving Mails. Postfix has several different classes of domains that he recognises as domains he (the local server) is hosting locally and therefore should accept mails for such a domain.

For example, my mailserver is responsible for the domain "". When a client is sending a mail with a recipient address xxx@xxxxxxxxxxxxxxxxxxxxxxx" to my server, my server is configured to accept the mail, provided there is no other reason to reject it. The client does not need to authenticate to my server.

email. If my SMTP server is the only SMTP relay server between the host and destination, that "reject_unauth_destination" is a little cruel as then the message will be rejected. Would it be rejected to the SMTP server that sent it to me and that SMTP server would have to find, via DNS, an alternate route to the destination?

An example to clear up the misunderstanding:

A mailserver is contacting your local server and asks your server to accept a mail for xyz@xxxxxxxxxxxxxx Your server is not configured to accept mails for that domain, so the mail is rejected and the contacting server still has the mail and is responsible for it.

In this example there are two questions you might ask the contacting server:

Question 1:
Why would that idiot of a server ask MY server to accept the mail?

Question 2:
Why is my server even listening on the internet for idiots like that when I don't plan to receive mails directly?

Let's have a look at Question 1:
The way a mailserver tries to find a responsible server for a recipient address is to query the DNS for an entry that says: "This server is assigned to accept mails for that domain".
The DNS knows a specific DNS entry for that kind of query, the MX entry.

You can do that manually with tools like "dig" or "nslookup".

# dig mx +short

Well, look at that, that domain actually exists! This means that these two servers will accept mails for the domain Okay, so why is that idiot trying MY server to deliver the mail??
All the more reason to reject such a mail.

Sometimes you encounter an obvious misconfiguration like
1. DNS query says "server xxx is responsible for that domain"
2. Server xxx does not know he is responsible an rejects the mail.

Often that is happening because the domain changed owner and the new owner didn't think about configuring a mailserver.
When no MX entry is configured for a domain in DNS, the mailserver tries to find an ip address that is mapped to that domain (A entry in DNS). Often a webserver is using that ip address but it will not accept mails. Shit happens...

If that happens the mail is not deliverable and will bounce after a certain time.

Back to Question 2:
When you configure your server to use fetchmail (or getmail or whatever other tool) to download the mails from your provider you don't need to have that server listening on the internet because your server will not receive mails directly, only via fetchmail or from your local little network.

All tests after that check only apply to external (or internal) untrusted clients.

It is also the reason why that check should come immediately after the checks for the trusted clients in the order of restrictions.

Frequently you encounter badly configured servers that trust clients when they claim "I have your ip address" or "I belong to your domain". The spam zombies try to find these servers and often try to impersonate such trusted clients. That is the reason why you should only trust clients that have proven their identity in a way you can trust. The ip address is practically impossible to fake during the course of such a smtp communication. You can trust that the ip address of the client is actually the ip address the client is really using.

OK, I'll try and remember though Whew, the brain is spinning. I'm going to need a new brain when I actually start setting this Postfic server up :)

Take it easy, even if some people claim that it is very simple to configure a mailserver, it is a completely different beast to have a real understanding how a mailserver should work.

Thankfully I trust no-one, with very few exceptions.

Spammers don't ask for your trust, they merely want to exploit your server. (^-^)

Often they abuse a script on a webserver to send their spam.

List replies only please!
Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com

Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at
Please read the FAQs: suse-linux-e-faq@xxxxxxxx