Rockliffe interpreted the database wrong originally, as noted below.
I'm
not sure of the status of this in 3.2, but I'll CC them on this message
and try and get a reply from them on it.
> -Todd Hutchinson
>
> Quote from Earlier Discussion
>
> There was a discussion in the past about this, and it has to do with
> how Mailsite interprets things. The old proc would do what you want,
> but Mailsite wasn't handling checking the domain correctly. Let me
> show the new proc first:
> CREATE PROCEDURE VerifyMailUser @username varchar(32), @domain
> varchar(32), @esid integer AS
> Select Login, Shell, Email, d.MailDomain, Password, HomeDir
> From MasterAccounts ma, SubAccounts sa, Groups g, Domains d,
> AccountTypes at1
> Where ma.CustomerID = sa.CustomerID
> AND ma.GroupID = g.GroupID
> AND g.DomainID = d.DomainID
> AND at1.AccountType = sa.AccountType
> AND at1.ExternalSystemID = @esid
> AND d.MailDomain = @domain
> AND ( ((Login=@username OR Shell=@username) AND d.MailDomain=@domain)
> OR Email = @username + "@" + @domain )
> AND DateAdd(Day, (ma.Extension+ma.OverDue+1), maExpireDate) >=
> GetDate()
> Because we added the "d.MailDomain = @domain" in the new proc, thats
> forcing
> the domain, regardless of the email field. You must remove that line to
> do what you want (allowing users in one domain to have email fields in
> another).
> What Mailsite is NOT doing, is handling the precedence order correctly,
> the
> way Emerald was designed. They simply look at the login field to find
> the
> user's name to put the mail in. So for example if you have this
> configuration:
> Login: joeuser
> Domain: domain1.com
> Email: joeuser@domain2.com
> So if you send mail to joruser@domain2.com, it fails unless you have the
> line above removed. If you remove the line, mailsite delivers the mail
> to joeuser@domain1.com, and ignores the email field we return of
> joeuser@domain2.com.
> You might be able to make a more complicated proc that would return the
> login/domain if the match is to the login and the split the email into a
> login/domain and return that if the match is to the email field. I'd
> prefer mailsite to not ignore the email field and use that if its not
> blank, as we original talked to them about doing when developing the
> Emerald ODBC connection and stored procs. Our EmerAuth.DLL *DOES*
> correctly handle the multiple domains this way with NTMail and IMail.
>
> -----Original Message-----
> From: Dale E. Reed Jr. [SMTP:daler@iea-software.com]
> Sent: Friday, March 12, 1999 10:55 PM
> To: emerald@iea-software.com
> Subject: Re: [Emerald] Mailsite.
>
> Todd Hutchinson wrote:
> >
> > Rockliffe has a new version of mail site, and we where hoping
> that this
> > would solve our problem of not being able to set up users emails under
> > different domains then the billing groups domain.
> >
> > Billing groups domain billinggroup.com
> >
> > user Joe
> > Pass Joespass
> > email Joe@joesdomain.com
> >
> > with these setting in the services isn't this suppose to allow joe to get
> > mail from the domain joesdomain.com, and login as joe and Joespass?
> >
> > It still doesn't work even with mailsite 3.2. So is this still a
> problem
> > with rockliffe?
>
> You can get it to work by changing the VerifyMailUser stored procedure,
> as mentioned in the earlier thread about this.
>
> --
>
> Dale E. Reed Jr. Emerald and RadiusNT
> __________________________________________
> IEA Software, Inc. www.iea-software.com
>
> For more information about this list, including removal,
> please see http://www.iea-software.com/maillist.html
>
> For more information about this list, including removal,
> please see http://www.iea-software.com/maillist.html
--Dale E. Reed Jr. Emerald and RadiusNT__________________________________________IEA Software, Inc. www.iea-software.com
For more information about this list, including removal,please see http://www.iea-software.com/maillist.html