6 messages in net.sourceforge.lists.courier-usersRE: [courier-users] Virtual domain pr...
FromSent OnAttachments
Andrew A.Nov 21, 2004 1:12 am 
Markus SchiltknechtNov 21, 2004 2:29 am 
Andrew A.Nov 21, 2004 2:45 am 
Gordon MessmerNov 21, 2004 10:34 am 
Andrew A.Nov 21, 2004 11:45 am 
Andrew A.Nov 21, 2004 12:25 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:RE: [courier-users] Virtual domain problemActions...
From:Andrew A. (aath@cloakmail.com)
Date:Nov 21, 2004 12:25:28 pm
List:net.sourceforge.lists.courier-users

Ok, your suggested setup works. But only AFTER I fixed what should have been a
rather obvious problem (sorry): The Courier rpm installs with various auth modules enabled. The pgsql module was failing. I
removed all but the authpam and authuserdb modules.

The authpgsql module was apparently causing address resolution to fail--for some
addresses. I suppose what was happening is that if an address didn't exist on the local system, then the prior auth* modules
failed, and then hit the pgsql module, which failed (rather than passing through) when unable to login to the sql server.

Therefore, I also suspect my prior setup would have worked (.courier files in
home dir), once unresolved addresses passed through the auth modules rather than receiving an explicit failure from pgsql.

A.

-----Original Message----- From: cour@lists.sourceforge.net [mailto:cour@lists.sourceforge.net]On Behalf Of Andrew A. Sent: Sunday, November 21, 2004 2:41 PM To: Gordon Messmer Cc: cour@lists.sourceforge.net Subject: RE: [courier-users] Virtual domain problem

Thanks! I will try this.

Unless I missed it, the aliasdir directory is not mentioned in the courier
installation docs, leaving new users thinking that $HOME based .courier files are the way to go. Based on your suggestion, it seems the
$HOME based .courier files are read too late in the address resolution process to handle my desired situation.

Your warning is spot on. I am (unfortunately) well aware of the spam issues,
since I am replicating the current setup (including defenses against said problem). Interestingly, the majority of spam comes to
addresses that have occured in the wild, not to addresses guessed by spammers.

A.

-----Original Message----- From: Gordon Messmer [mailto:yiny@eburg.com] Sent: Sunday, November 21, 2004 12:55 PM To: Andrew A. Cc: cour@lists.sourceforge.net Subject: Re: [courier-users] Virtual domain problem

Andrew A. wrote:

(1) I want all outbound mail to "masquerade" (envelope, headers, esmtp protocol entries, etc.) behind memeplex.com

I don't believe you can do this with Courier.

(2) I want the local server to be memeplex.com

That's easy enough.

(3) I want all mail sent to users that don't exist on the local host to go to the user "aathan" I don't want such mail to generate bounces or be delievered as part of an error report; I want it to show up as if the sender got the address right.

You can do that, but you'll regret it later. The way to do it would be to create a file named ".courier-default" in etc/courier/aliasdir/ and put your own username in that file. All addresses which don't resolve to an existing user or alias will go to you. Your mailbox will fill up with spam and viruses.

If you leave out the .courier-default file, then mail sent to addresses that don't exist will not be accepted by Courier. They will be refused outright during the SMTP conversation. They won't be bounced by your server, or be delivered as part of an error report. They will never be your problem.

I've tried several permutations, none of which work. The important ones are:

None of your permutations specified what you'd done with "locals" or "hosteddomains", so I assume you've got them wrong. Get rid of the "@memeplex.com: aathan" alias, since the dot-courier file will do the address redirection that you want. Create a file called "locals" in your "esmtpacceptmailfor.dir" directory containing "memplex.com", symlink "etc/courier/locals" to "esmtpacceptmailfor.dir/locals", and run 'makeacceptmailfor'.

That should get local delivery working properly, which will put you in a better position to start testing options. If you are pursuing a virtual domain setup, you can create a userdb or sql/ldap db later and then destroy the locals files and replace them with the appropriate hosteddomains files.