Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [SLE] SMTP authentication
  • From: "Hylton Conacher (ZR1HPC)" <hylton@xxxxxxxxxxxx>
  • Date: Sat, 29 Apr 2006 13:57:59 +0200
  • Message-id: <445354C7.40205@xxxxxxxxxxxx>
Sandy Drobic wrote:
Hylton Conacher (ZR1HPC) wrote:

Carlos E. R. wrote:

The first SMTP sever may ask questions, of course. Any SMTP server in the chain, except the one of the destination address may ask for authentication of some sort; ie, your ISP SMTP server may ask for it, because it will _relay_ your mail to somebody else......

OK, understood. What tyoe of authentication could a SMTP server say 3 down the line ask for? Would its request be answered by the second SMTP server or would SMTP-3 try and contact the original dialup server which may not be currently connected?

Authentication, when it is required, will alway happen between the server that currently has the mail and the server that is contacted to receive the mail.

Let's just use an example how a mail will progress when you send it off at your company:
OK, Goody :)

Your mailclient is configured to send all mails to the mailserver of the department/company. Your mailclient uses your username/password to authenticate to the company mailserver.

Now the company mailserver does not have the right to send the mail directly to the internet. Only the mailgateway is allowed by the firewall to send directly to the internet. So the company mailserver sends the mail to the mailgateway. In order to prevent other clients in the company from sending directly to the mailgateway, the mailgateway also is configured to require authentication to relay mails. So the company mailserver authenticates itself to the mailgateway using his own user/password or maybe a client certificate. This authentication has nothing to do with how you authenticate to the company mailserver.
The mailgateway could be configured to send the mail either to the ISP mailserver or directly to the next mailserver that is responsible for the recipients domain. When it uses the ISP mailserver as relay it might have to authenticate again with an independent user/pass to authenticate itself (the mailgateway) to the ISP mailserver.

How many hops the mail has to pass within the recipients internal network is another question. There could also be several mailservers involved which might ask for authentication.

I admit this is going a bit overboard with the authentication but it could happen nevertheless.
Sandy, the above paragraphs were pivotal to my understanding. Free beer/fruit juice on the house for Sandy.

So eventhough my local SMTP server dials up to the internet with a certain username and password, that same username and password would not be used as authentication between my local SMTP server and the ISP's one, should it be used as a relay?


I don't know what you are trying to say. (^-^)
Sorry me neiter :)

The easiest way to test it is to set up several mail accounts in your mailclient and configure each account to send with the same user/pass to your ISP mailserver.
Sorry, I didn't see that I was able to specify the name and password the new SMTP server I had added. :()

I've added a new entry for and used my gmail username to authenticate. It didn't request a password so I assume that will come up when I send the message.

Are these methods also used if the sender is a SMTP server or are different criteria used? ie see above just below OR.

Which restrictions are used mostly depends on what kind of recipient address the email has. I'll give you a Postfix example:

Your server has the following configuration:

mydestination =
mynetworks =
smptd_recipient_restrictions =

Now, a client in your internal network with the ip connects to your server and wishes to send an email to user@xxxxxxxxxxxxxxxx
Postfix examines the restrictions and evaluates one restriction check after another if a check is returning a value of either "OK, PERMIT" or "REJECT".

The first check in smtpd_recipient_restriction is "permit_mynetworks". It checks, if the connecting client is in the same network as has been defined in mynetworks. In this case, the client is indeed within the network, so the check returns "OK" and the mail is accepted. No other checks need to be evaluated.

Next, a client with the ip address connects from the internet to your server and wants to send an email to unknown@xxxxxxxxxxxxxxxxxxx

Postfix first checks again "permit_mynetworks". This time the check comes up empty because the client ip is NOT in mynetworks.
I thought it would have rejected after the mynetworks check as it did not match. It doesn't matter if it meets anything else, mynetworks says the client must be in a certain IP range, finished

So Postfix tries the next check: permit_sasl_authenticated. Well, the client did not authenticate, so this check also returns an empty result. The next check, "reject_unauth_destination" evaluates if the recipient address is in a domain that Postfix is responsible for, otherwise it returns "REJECT" as result.
In this case, the domain is not in mydestination, so the check returns "REJECT" and the mail is rejected.

What kind of restriction checks are configured for a mailserver is completely up to you and your requirements.
I fully understand your example although I cannot see in the example why the "reject_unauth_destination" variable needed to be checked.

mmm, I've seen email headers and understand this. What i didn't know was that there are normally only a maximum of 2 SMTP servers ie sender and receiver.

Normally there is a minimum of two servers. Though here's an example where only one server is involved:

Your mailclient is sending to the isp mailserver, The recipient's maildomain is also hosted on that server, so the server directly delivers the mail to the mailbox of the recipient, end of story. (^-^)

If the recipient's maildomain is not hosted on the server that you used to send your mail to, then the mail will have to be send at least to another server.
Given the above explanation in tandem with what I have received from Carlos et al, this is all starting to make sense.

Thank you all

< Previous Next >