Re: MTAs: rejecting senders with exim and delivering responses to rejected senders
On Tue, Jul 24, 2001 at 10:02:29AM +1000, Sam Varghese wrote:
> On Sun, Jul 22, 2001 at 02:15:36PM +0200, Hans Wilmer wrote:
> > Well, better solutions are appreciated :) I've been looking for
> > providers of mailhosting yesterday evening because things would be
> > easier if I had my own domain, but I couldn't find an appropriate
> > offer yet. To have my own domain with a multidrop mailbox with a quota
> > of at least 50 MB would be nice.
>
> In your exim.conf add a line like this:
>
> host_reject_recipients = lsearch;/etc/mail/block/hosts
I've set: sender_reject = /etc/exim.reject
Specifying lsearch; seems to make a difference (unless this is the
default lookup method). How does your file look like, and what's the
reason for using lsearch?
> I have added it in the main configuration settings part,
> just after the smtp_verify option.
Hm, I did the same, though I don't know what the VRFY command does. I
guess it was enabled in the default configuration file and I left it
untoched.
> Basically, this is telling exim that the IPs to be blocked
> are in a file called hosts
> located in /etc/mail/block; the lsearch means it is a text
> file and a linear search has to be carried out to identify
> IPs which have to be blocked.
IPs? Then you must be blocking whole hosts instead of certain
senders. I'm just specifying the sender addresses and make use
wildcards where appropriate.
The disadvantage seems to be that the checking is performed on
adresses given in the MAIL command which I don't neccessaryly see when
examing the mail headers (with mutt). Therefore, some mails get
through that shouldn't.
> (If you have a large number of IPs, it may be better to
> create a database; for that, refer to the exim documentation
> at www.exim.org)
just a few adresses, yet
> Then create this file (hosts) in /etc/block/mail (you
> can create it in any other location, change the
> path accordingly. I chose this because it was listed as
> the default).
Hm, you seem to be using a different version of exim. What
distribution are you using?
> It works for me. YMMV.
Thank you very much for your help! :) Meanwhile, I've started thinking
about using ETRN (with my own official domain) as it seems to fit my
needs the best.
But I couldn't figure how client authentication is done with ETRN
yet. The only way to do it seems to be making use of fetchmail with
the preconnect option to establish an ssh authentication/connection,
but it seems that the SMTP connection the server may establish to the
client after receiving the ETRN command is in no way related to the
ssl connection other than that fetchmail won't send the ETRN command
if the authentication fails. Thus, I can't ever be sure that the
server spools the mails to my client and not to somwhere else. Even if
the server gets the current IP of the client to establish the SMTP
connection and sends mail to me, my dial-up connection might be
interrupted during the transfer. In that case, some other host could
get the same IP I was using a few seconds ago and my mails would be
sent to someone else :/
How is ETRN actually used? RFC 1985 says it was developed for use with
transient connections and with security in mind, but what kind of
actual security does it provide?
Well, I'm a bit confused ... Can it be that there's no good method to
receive mail for user@own.domain.net, user@sub-1.own.domain.net,
user@sub-2.own.domain.net, etc., from a remote server that collects
all mail for *@*own.domain.net, allowing you to dial-up every now and
then and fetching it? Using multidrop seems to have crucial
disadvantages; ETRN is of very questionable security --- what could I
use?
GH
--
Nieder mit der Mineralölsteuer!! Senkt die Benzinpreise!!
http://www.congressonlineproject.org/email.html:
> Timely, in-kind responses to e-mail provide the high-quality service
> that e-constituents expect, and failing to deliver it reflects poorly
> on Members of Congress.
Reply to: