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 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], etc., from a remote server that collects all mail for [EMAIL PROTECTED], 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.
