[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-net
Subject:    Re: Mail relay
From:       Glynn Clements <glynn () sensei ! co ! uk>
Date:       1999-01-31 6:32:59
[Download RAW message or body]


Reuben Farrelly wrote:

> > > > http://www.sendmail.org
> > > > 
> > > > the most widely used mail transport agent.
> > > 
> > > I would suggest qmail ...:(
> > 
> > The last time that I checked, qmail would only send mail to non-local
> > addresses if it originated from the local host.
> 
> No, not quite correct.  By default it does this, but it's very easy to change
> the default behavior, using config files.

OK, then it's changed recently. The last time that I looked, the only
references which I could find regarding using it as a relay involved
adding entries to inetd.conf, so that the connection appeared to
originate locally.

> > It is possible to get around this by running a forwarder via inetd,
> > and using tcpd (or ipfwadm) to control who can access it. However,
> > such users are then impossible to distinguish from users which are
> > really local.
> 
> Allowing any host to relay is as simple as adding a "RELAYCLIENT=x.x.x.x" to
> hosts.allow.

`RELAYCLIENT=x.x.x.x' does not conform to the required syntax for the
hosts.allow file. Entries in hosts.allow (and hosts.deny) must be of
the form

	server:		pattern pattern ...
or
	server:		pattern pattern ... : extension

(the latter form is only available for programs which support the
extended options, e.g. those which use a version of tcp_wrappers which
was compiled with -DPROCESS_OPTIONS).

And adding entries to hosts.allow only affects applications which
actually check that file (e.g. those which use tcp_wrappers, such as
tcpd).

As I pointed out, it is trivial to forward connections in such a way
that they appear to originate from the local host. Consequently, it is
possible to grant arbitrary remote systems the same privileges as
local processes, without any support from the application in question.

However, by incorporating the remote relaying functionality into the
main program, sendmail allows you to select between multiple relaying
policies, depending upon the specific IP address from which the
connection originated.

This isn't possible with the `forwarding via inetd' technique which
was proposed as a method for allowing qmail to function as a relay.

> There are patches available on the qmail web site which allow authenticated
> SMTP relaying.  Check them out at http://www.qmail.org/ (pick your closest
> mirror).

Unfortunately, authentication is an ESMTP extension, which many
clients do not support. For the time being, the client's IP address is
the only attribute which can be used in relaying decisions if
portability is required.

> > This is probably sufficient for many cases (i.e. where you wish to
> > grant specific remote users full use of the mail relay, as if they
> > were local users). However, it appears to be impossible to get the
> > same degree of control that you can with the check_* rulesets in
> > sendmail.cf.
> 
> Apparently you can do just as much with qmail as sendmail, and in my somewhat
> limited experiences of this it's certainly much easier to learn and use.

Unless qmail has recently gained the equivalent of sendmail's
rulesets, then you certainly can't do as much with qmail as with
sendmail. Whilst qmail may be sufficient for straightforward setups,
sendmail isn't going to disappear whilst there remain systems with
which simpler MTAs can't cope.

-- 
Glynn Clements <glynn@sensei.co.uk>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu

[prev in list] [next in list] [prev in thread] [next in thread]