Good Morning,

I had another question regarding unwanted traffic. I have installed 5xxsink
and it works beautifully, however; is there any way to implement an
(additional) actual whitelist of approved domains (to be used in conjunction
with 5xxsink) that we would accept email from?

I am currently searching, but I have not found anything yet.


Thanks in advance.

Curious

[ Post a follow-up to this message ]

Sandy,

I wanted to mention that we are not using mailboxes due to certain
sharepoint 3 document library configurations, which when named can receive
email. So, no internal mailboxes.

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?

Thanks for you advice. It is appreciated.

Curious

[ Post a follow-up to this message ]

> 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?

You  seem  to  be  combining  concepts  of a sender whitelist (allowed
sender  users/domains)  and  a  recipient whitelist (allowed recipient
users/domains).

Out-of-the-box, IIS SMTP supports a form of recipient whitelist, since
you  can  configure  it  to only accept mail sent in _unauthenticated_
sessions  for its local and alias domains and a specific list of relay
remote  domains.  All  other  remote  domains  will not be serviced in
unauthenticated  sessions.  You  can also choose whether authenticated
sessions  will  be  allowed higher privileges so that they may send to
unlisted remote domains.

With  5xxSink,  the  recipient  whitelist  is enhanced greatly by only
accepting  mail  to  a  list of specific _users_ @ serviced domains --
instead  of  initially  accepting mail to any username @ local, alias,
and remote domains *regardless* of whether a mailbox exists.

As  far  as  a  sender whitelist, 5xxSink has no participation at that
level  (the MAIL FROM part of the SMTP convo).

IIS  SMTP  on  its  own can restrict connections at the stack level by
source  IP (so no one else can even start a convo with the server); it
can  restrict  delivery  to  both local/listed and unlisted domains by
always  requiring  an authenticated session; or it can allow anonymous
sessions to deliver to local/listed domains, while requiring an auth'd
session  to  send to unlisted domains.

If  you  only want to accept mail from specific partner domains, it is
best  to  require  incoming  authentication  for all mail and not even
publish  an MX record. Otherwise, you're just inviting people to forge
one  of  your  allowed  sender  domains, easily foregoing any apparent
security;  further,  publishing  an  MX in the public DNS for a server
that,  in  reality,  accepts  mail only from a private list of allowed
servers is misleading.

If you did not want to require a login and password -- by the way, you
*can*  log  in  to  IIS  SMTP  regardless  of whether you have a local
mailbox;  you  just  need to exist in the SAM or AD -- but you want to
have  non-forgeable  protection,  you'd  gather  the source IPs of the
outbound  mailservers  of  your  allowed  domains  and allow anonymous
connections  only  from  those  IPs.  Problem  with  this  approach is
maintenance;  logins  and passwords are portable once you provide them
to  a  partner, while their source IP would have to be changed on your
end if it ever changes on theirs.

Does that spell things out any better?

--Sandy

[ Post a follow-up to this message ]

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

It certainly does. If we were a larger company, it sounds as though
puchasing exchange would have been costly, although more effective. I guess
it depends on how that would interoperate with WSS 3 though.

Thanks again for the response Sandy. Your input is valued.

Curious

[ Post a follow-up to this message ]

> 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?

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.

--Sandy

[ Post a follow-up to this message ]

> More effective at what?

->Mainly, Windows Integrated Authentication

> 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.

->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.

->This SMTP Server also hosts the SharePoint sites, so the SMTP function was
implemented as a requirement for that aspect. This server does not have an
external MX record associated with it.

->My other SMTP server (residing on another server) does have an MX record
and it is used to "relay" the mail to our SharePoint domain.

Side Note: I am getting confused as I try to put this into words
categorically, nonetheless...it functions, only anonymously. I currently hav
e
your 5xxsink installed
nad it work's great.

->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.

Lastly, if I were to create the new "users accounts", I would only do it for
real users and not document libraries, otherwise the mailbox would fill with
mail when I send it to a doc library.

So, it is working the way it is now (especially with your program), I just
don't have the Integrated Windows Authentication.

Thank you again,

Curious

[ Post a follow-up to this message ]

>> 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

[ Post a follow-up to this message ]

Hmm. I appreciate your clearly deep understanding of SMTP and IWA. I thought
"Well, I am not using a mailbox on the system, so IWA would be ignored".

I am glad it is not the case then. I misunderstood how it worked and thought
it only was representative of having a mailbox associated with the AD
account, thereby using the IWA when checked (only IWA checked) in SMTP Serve
r.

Here is my current setup for the sharepoint SMTP server:
1. Anonymous checked - no other auth type selected
2. Connection - All except the list below - empty
3. Relay - Only the list below with 2 domains and some IP's

Other SMTP Server - Has MX Record pointing to static IP on sharepoint server

1. Anonymous checked - no other auth type selected
2. Connection - All except the list below - empty
3. Relay - Only the list below - 2 domains some IP's

Currently using my original domain account.

So far I have not had any client that could not send email to one of the
email enabled document libraries, as long as they have the address, and as
long as I leave Authentication on anonymous. I routinely post successfully
with an external account myself. When I enable IWA and try sending mail. No
Dice.

If I create a new mailbox with associated user under the sharepoint domain,
then log into windows with the new account, I can send email to external
sources, as well as to the document libraires on sharepoint.

Of course with no MX record for the sharepoint server I can't receive the
external emails, but that's another story. If I leave the IWA selected and
log back in with my existing AD account, I can't send email to the document
libraries.

When I revert back to anonymous authentication, I can obviously send just
fine.

While I understand 5xxSink's purpose I have found it to be quite valuable
and will continue using it. I have also implemented the TarpitTime as an
extra "thwarting" measure. Either way, it works nicely...with anonymous
enabled.

I appreciate your patience, expertise and guidance Sandy. It has been
interesting trying to get my head around it all. I'm not certain I am there
yet though.

Thank you again for your input sir. It is greatly appreciated.

Curious

"Sanford Whiteman" wrote:
 
>
> 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?
> 
>
> 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).
> 
>
> 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
>

[ Post a follow-up to this message ]