[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [exim4] mixed up about terminology



Harry Putnam <reader@newsguy.com> writes:

> Jerry Stuckle <jstuckle@attglobal.net> writes:
>
>> The first question - why do you think you need to relay to other
>> networks, even if they're your own?  Do you have other SMTP servers
>> running on those networks?
>
> Good question and apparently thee is no reason.  It stemmed from a deep
> seated confusion about what relaying means.

Don't confuse relaying with "listening on interfaces".  "Listening on
interfaces" merely means what it says, quite literally.

Imagine I'd call you on the phone and you put the hook aside:  You can't
hear what I'm saying because you're not listening on that interface (the
hook).

Or you could put me through to someone else, thus relaying my call.  To
do that, you first need to listen to find out to whom I'd like to talk
to.

> All I really want is to be able to do this:
>
> On my lan machines:
>
> HOST-1
> HOST-2
> [...]
> HOST-mail-server now being configured
>
> HOST-[12...N] would have the server host above listed as smarthost in
> there respective mail config.
>
> So they would all be sending mail by way of server host.
>
> I guess that is not what is meant by relaying?

Before anything else, I strongly recommend that you set up a name
server.


There is a hard distinction between incoming messages and outgoing
messages, as seen from the MTA.  This is an important distinction you
need to be clear about.


An MTA can either be the final target of a message, or it can hand a
message over to another MTA (or it could do something else which isn't
relevant here).  You can consider both these cases as a type of
delivery, i. e. local delivery (like to you) vs. delivery via another
MTA (remote delivery, to someone else than you).

In case an MTA has accepted a message, it must either deliver the
message, or it *must* send an error message to the sender of the message
(see RFC 821).  (This means that your MTA must not accept messages from
unreachable addresses because it cannot send error messages to such
addresses.  This part can be somewhat difficult.)


Relaying usually means that an MTA will handle messages on behalf of
some type of client.  A client to the MTA can be your MUA or another
MTA.

When your MTA uses the ISPs MTA as a so-called smarthost, the MTA of the
ISP is relaying messages for your MTA.  Your MTA becomes a client to the
MTA of the ISP.

Your ISP should have made sure that all clients their MTA relays
messages for must authenticate before such clients can use the ISPs MTA
as a relay:  Authentication is taken as proof that the client is
authorised to use the MTA (as a relay).

You also *must* make sure that /your/ MTA relays messages exclusively
for authorised clients.  Otherwise, unauthorised clients ---
particularly spammers --- could use /your/ MTA to relay messages
(i. e. SPAM messages).  When unauthorised clients can use your MTA as a
relay, you have what's called an "open relay".

That the MTA of your ISP requires all clients to authenticate does *not*
protect you in any way from your MTA being used as an open relay.  This
is so because your MTA will authenticate itself to the MTA of your ISP
to perform remote (as seen from your MTA) deliveries, and the MTA of
your ISP is not to decide which deliveries it shall perform on behalf of
your MTA and which ones not.  Hence all messages to remote destinations
from _unauthorised_ clients of /your/ MTA shall be delivered just the
same as all messages from _authorised_ clients of /your/ MTA via the MTA
of your ISP.  You (your MTA) must make the distinction between who is
authorised and who is not; your ISP (their MTA) can not and are (is) not
supposed to do that (once you (your MTA) has proved that it is
authorised by authenticating (itself)).


Suppose you want to send a letter to someone.  You put it into an
envelope, put a stamp on it and hand it over for delivery at the post
office.  The stamp has authorised you to send the letter.  The postmen
shall not open your letter to check whether it's SPAM or not but deliver
it.

Having an "open relay" would mean that arbitrary people randomly give
you letters and you put stamps onto the envelopes and hand these letters
over for delivery at the post office.


Since you have several different LANs, it may be a good idea to specify
the hosts for which your MTA should relay messages explicitly instead of
specifying whole networks which implicitly allows all clients on such
networks to use your MTA as a relay.  Besides other advantages, a name
server comes in very handy for this, provided you have configured it
correctly.

Another option is to set up your MTA so that it requires authentication,
just as your ISP has set up their MTA.


Instead of using the automatic configuration, you may want to look at
the configuration examples exim comes with and use
'/usr/share/doc/exim4/examples/example.conf.gz' as a starting point to
create your own configuration.  The documentation of exim[1] is
outstanding and gives you a lot of insight.


[1]: http://www.exim.org/docs.html


-- 
Hallowed are the Debians!


Reply to: