You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Lee Ting Zien <tz...@ionbits.com> on 2003/03/10 23:51:18 UTC

James for multiple domains

Matthew,

Your friend is not entirely right. Yes, it is true that Qmail, Postfix,
etc supports a login id that goes like "user@domain", but its just the
result of some mapping. The way qmail works is that you deliver mails
for user@domain1.com through some preprocessor that maps it to a user
"domain1.com-user" and stores the files in a Maildir somewhere in the
disk, then you tell the POP3 daemon to retrieve mails from
"user@domain1.com" from the same Maildir on the disk.

As you can see, this is an extremely messy mapping and really separates
the user accounts in the POP3 daemon from the SMTP daemon. There's lots
to argue about the pros and cons of such a separation, but let's not
touch on that.

Here's one example from my qmail's mapping file in
/usr/local/qmail/users/assign

	domain.com-user:mail:8:12:/home/mail/domain.com/user:::

Basically, the e-mail addr. user@domain.com is automatically mapped to a
"virtual" user in Qmail called "domain.com-user", and incoming mails are
stored in "/home/mail/domain.com/user"

And here's an entry from /usr/local/qmail/users/poppasswd, a file which
the POP3 daemon reads to retrieve mail, get a user's passwd, etc.

	user@domain.com:<passwd>:mail:/home/mail/domain.com/user

As you can see, it's just another form of mapping.

I'm sure there are lots of other "hacks" to Qmail that does almost the
same thing but in a different way, but they're all just mappings, really
-- the tools out there basically simplify the process by automating the
creation of these files, managing the mappings and hiding some
processing layers from you.

James and Sendmail does exactly the same thing -- mapping.

I've done the same user@domain login with Sendmail and Qpopper
successfully on a production machine. However, it required some
modifications to the Qpopper source.  Qpopper strips off the "@domain"
part if you supply the login as "user@domain" so I had to get rid of the
chunk of code that does the string truncation.

How did I do it?

Basically, I added a UNIX user account "user@domain" and mapped incoming
e-mails to user@domain to the user "user@domain". When this happens,
your POP3 login would be "user@domain", wouldn't it be? Not sure if it
would work in James, but you could check it out.

One suggestion to James is that they break the RFC rules (I'm not sure
if it's due to some RFC conformity) and break up the "user@domain" into
two "user" and "domain" parts. Once this is done, virtual hosting would
be pretty neat. Mailets can  then choose to ignore the domain, or take
them into consideration during processing. Correct me if I'm wrong.

Regards,
Ting-Zien Lee

--
From: Matthew Schuyler Peck <mp...@xapsolutions.com>
Subject: James for multiple domains
Date: Mon, 10 Mar 2003 11:19:19 -0800
Content-Type: text/plain;
	charset="us-ascii"

I checked with a mail admin friend of mine. According to him, sendmail
is as
you say. Exim, qmail, and postfix, on the other hand, support multiple
<user>@ for multiple domains. Should we take a look at these three to
see
how they do it?

Matthew Schuyler Peck


---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org


Re: James for multiple domains

Posted by bill parducci <bi...@parducci.net>.

Danny Angus wrote:
>>actually, james wouldn't have to 'break' the rfc. passing the 
>>rcpto (mailfrom while you're at it :o) information to mailets as 
>>they are invoked 
> 
> 
> it is passed as the Mail.recipients, how do you think we manage to send mail onwards??!

kinda what i thought (but i don't write mailets, so needed confirmation ;o) so, if _envelope_ information is being passed to the mailets then i don't understand what the original problem is (multiple domain handling). with this information you can do *anything*.

b


---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org


RE: James for multiple domains

Posted by Danny Angus <da...@apache.org>.
> actually, james wouldn't have to 'break' the rfc. passing the 
> rcpto (mailfrom while you're at it :o) information to mailets as 
> they are invoked 

it is passed as the Mail.recipients, how do you think we manage to send mail onwards??!

d.


---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org


Re: James for multiple domains

Posted by bill parducci <bi...@parducci.net>.
> One suggestion to James is that they break the RFC rules (I'm not sure
> if it's due to some RFC conformity) and break up the "user@domain" into
> two "user" and "domain" parts. Once this is done, virtual hosting would
> be pretty neat. Mailets can  then choose to ignore the domain, or take
> them into consideration during processing. Correct me if I'm wrong.

actually, james wouldn't have to 'break' the rfc. passing the rcpto (mailfrom while you're at it :o) information to mailets as they are invoked would do allow developers to take action based upon the SMTP envelope as they saw fit. not sure if this is possible now, but i am sure one the mlist gurus could answer that (and the likelihood/desirability of implementing it).

b


---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org