> Does that spell things out any better?
> --Sandy

> If we were using mailboxes, then the authentication part would be a
> breeze. Without mailboxes, are the relay restrictions effective? I
> mean is that not similar to a builtin whitelist?

> More effective at what?

> Please spell out your functional requirements and we can see whether
> IIS SMTP, with or without plug-ins, can fill the bill. Based on our
> convo thus far, I wouldn't know what req is or isn't met.

> It certainly does. If we were a larger company, it sounds as though
> puchasing exchange would have been costly, although more effective.

>> More effective at what?
>
> ->Mainly, Windows Integrated Authentication

> ->I have 2 SMTP servers. One is solely for the purpose of
> transferring email messages to document enabled libraries. There are
> no mailboxes associated with the pop3 service, although there is a
> default domain. Hernce, no WIA here.

> ->Initally we had no intentions of ever considering the
> possibilityof hosting our own email, or purchasing exchange server;
> so we never set up the mailboxes. Accounts were created within
> Active Directory and usernames were thusly established.
>
> ->If I understand this correctly, (in order to utilize Windows Integrated
> Auth) I would need to do one of two things.
>
> 1. Create additional users associated with the mailboxes (name changes
> would
> not be acceptable) or...
>
> 2. Remove each original account from AD, then create mailboxes.

"Sanford Whiteman" wrote:

> >> More effective at what?
> >
> > ->Mainly, Windows Integrated Authentication
>
> But IIS SMTP supports Integrated Windows Authentication (IWA) in
> standalone installations *and* with Exchange installed.
>
> In both cases, IWA is implemented using the AUTH NTLM or AUTH GSSAPI
> SMTP authentication mechanisms. You can easily see the offered AUTH
> mechanisms in both installation types same by telnetting to your SMTP
> port and typing 'EHLO'.
>
> Perhaps you're confusing IWA with something else? In terms of SMTP
> AUTH, IWA offers (a) a secure AUTH handshake, from which passwords
> cannot be read, and (b) integration with existing local security
> databases or Active Directory, instead of requiring a separate list of
> usernames and passwords. Some might even say that IIS SMTP's IWA
> support is *too* robust, in that it comes at the expense of any other
> secure handshake mechanisms.
>
> In overview... SMTP AUTH can be extended by either proprietary or
> open-standard mechanisms. IIS offers the standard, primitive LOGIN
> mechanism--but passwords can be easily snooped from LOGIN sessions.
> IIS also offers the proprietary NTLM hash mechanism, which is secure
> but which is not available to non-Microsoft clients. And at the "high"
> end, IIS offers the advanced GSSAPI mechanism, which is quite cool and
> non-proprietary (it's a form of Kerberos), but which in practice is
> not supported by non-Microsoft software at this point (.NET's mail
> components, for example, support GSSAPI, so there's nothing technical
> to stop someone from writing a compatible mail client using the
> Framework).
>
> Left out of the available mechanisms are the entry-level, standard
> secure hash mechanisms like CRAM-MD5. These are the types of secure
> mechanisms supported by non-Microsoft mail clients, along with
> insecure LOGIN. Unfortunately, the lack of support on the server side
> means that if you have a 3rd-party mail client, you end up ratcheting
> down to LOGIN. For that reason, IIS SMTP is not suitable as a mail
> server for ISPs that support a range of multi-vendor clients but which
> need to enforce secure authentication. However, for corporations in
> which compatible mail clients can be mandated, IIS SMTP -- *with IWA*
> -- is a fine choice.
>
> So that gets us back to what _you_ need an SMTP server to do for you
> vis-a-vis authentication. Integrated Windows Authentication can't be
> the only thing you need. Is there a particular client that you are
> expecting to do the IWA handshake that isn't?
>
> > ->I have 2 SMTP servers. One is solely for the purpose of
> > transferring email messages to document enabled libraries. There are
> > no mailboxes associated with the pop3 service, although there is a
> > default domain. Hernce, no WIA here.
>
> See, I think that's where you're losing track of what IWA is. A user
> does get offered IWA in SMTP whether or that user has a corresponding
> POP3 mailbox. The question will be what SMTP *clients* can support
> that IWA mechanism (the POP3 docs note this in their comments on SMTP,
> but the comments about the SMTP side in fact apply whether or not POP3
> is activated).
>
> > ->Initally we had no intentions of ever considering the
> > possibilityof hosting our own email, or purchasing exchange server;
> > so we never set up the mailboxes. Accounts were created within
> > Active Directory and usernames were thusly established.
> >
> > ->If I understand this correctly, (in order to utilize Windows Integrated
> > Auth) I would need to do one of two things.
> >
> > 1. Create additional users associated with the mailboxes (name changes
> > would
> > not be acceptable) or...
> >
> > 2. Remove each original account from AD, then create mailboxes.
>
> No, there's no need to do either one of those things in order to use
> the IWA SMTP extension.
>
> A user in the local SAM (if the SMTP server is a standalone,
> non-member server), the SAM or AD (if a member server), or AD (if a
> DC) can use IWA.
>
> But I think there are still some factors you're not expressing fully,
> otherwise you wouldn't be thinking of 5xxSink as an alternative to
> IWA. It's not -- and some might say they contradict each other, since
> the SMTP VS *that has 5xxSink bound to it* will ignore attempts to
> relay to domains that 5xxSink doesn't know about, *even* if it's in an
> IWA session that appears to be permitted to relay anywhere it wants.
>
> --Sandy