iis smtp nntp: Hi,

I need to set up a TLS connection on an w2k3 sp2 server with IIS6
which is not attached to the domain.
This server will be placed between a mailsweeper box and a remote
relay server at the ISP (i.e. a smarthost).

I need to ensure TLS encryption between the IIS box and the ISP's
server.
There is to be no TLS between the mailsweeper box and the IIS box.

Inbound mail will be accepted from the ISP using TLS for 2 domains
(i.e. the 2 domains my users have email addresses for) and relayed to
the mailsweeper box.
Outbound mail will be accepted for any domain from mailsweeper and all
of this outbound mail will be relayed to the ISP using TLS.

Can anyone please help me decide how to achieve this?

thanks,
Jason

[quoted text, click to view]

Set up Remote Domains for the two exceptional domains (your internal
domains). Allow the server to relay mail to your Mailsweeper box as the
Smart Host for their namespaces. Do not set Outbound Security for these
RDs.

At the virtual server level, set Outbound Security-TLS. Set the ISP's box
as Smart Host at this level, which amounts to the * namespace. Also at
this level, allow relay for your Mailsweeper box's IP (Access-Relay).

Continue at the VS level by setting Access-Authentication to have both
Anonymous and Basic+TLS as options. This covers inbound traffic.

Note that inbound settings apply to all connections. For this reason,
both Mailsweeper and your ISP need to *not* balk at being offered
additional authentication methods that have either higher or lower
security than the method they intend to use. Mailsweeper should press on
with Anonymous submission, and the ISP has to press on with TLS. If they
are both RFC-compliant, and do not have other non-standard fallback
mechanisms, this will not be a problem. If either is broken, though, you
will need to create two separate VSs handling only one type of inbound
auth each; this is not supremely difficult, but it would be best to try to
get along without it first.

On 18 May, 17:04, "Sanford Whiteman" <swhitemanlistens-
[quoted text, click to view]

Hi Sandy,

I think your solution means that if a non tls connection was
initiated, it would be accepted and mail would flow through the VS.
I need to ensure that the TLS connection between my IIS SMTPVS and the
ISP is definitely TLS or I need an NDR needs to be generated.
For this reason, I believe 2 VS's are required. But how to configure
them???
I have read as many articles as I can find but cannot find any that
address my particular need.
Please help!!!!

- Jason

[quoted text, click to view]

Yes, although this is a quite standard setup; if you have an agreement
with a third party to encrypt traffic over the public Internet, it is
incumbent on both sides to ensure encryption, since you are using
protocols that work with and without it.

If you have a public MX that doesn't require TLS and a private MX that
does require TLS, and you want to completely block a certain party from
using the public machine, you have to make sure their source IPs aren't
even allowed to connect. (And what if they change IPs?)

Conversely, if you're not going to publish a public MX *at all*, then
disallow Anonymous on your single VS and restrict that VS (at the
firewall) to only accept connections from their source IPs.

[quoted text, click to view]

NDR? Not really; you want the connection to be rejected by your MX. What
the ISP does next is up to them (I don't think in terms of the final
disposition of the message, just what I do with it).

[quoted text, click to view]

One accepts Anonymous and the other doesn't. It's simple. Although
maintaining the rest of the the two-VS setup is more annoying than one
(two queues, sets of logs, etc.).

On 30 May, 18:34, "Sanford Whiteman" <swhitemanlistens-
[quoted text, click to view]

Thanks Sandy.
I will try using just the 1 VS first.
In doing it this way, if I only open port 465 on the firewall to the
IIS server and not port 25, this should achieve what I need - or is it
the case that port 25 needs to be open for initial communication?

- Jason.

[quoted text, click to view]
=

[quoted text, click to view]
=

[quoted text, click to view]

The idea behind STARTTLS is that you initialize secure communications ov=
er =

an existing application-level connection, then restart the =

application-level conversation. The TCP/IP port does not change.

A session that invokes encryption via SMTP's STARTTLS extension uses =

*only* TCP 25 if a public MX record is used for mailrouting, or if that'=
s =

the port coded in a private mailroute. If an initial, unencrypted SMTP =
=

conversation is allowed to start on TCP 465, followed by STARTTLS, then =
=

*only* TCP 465 will be used. But TCP 465 and STARTTLS have no special =

relationship: conversely, because TCP 465 and SMTPS (see below) *do* hav=
e =

a well-known-port relationship, it's a very bad/misleading practice to =

have an SMTP server that does not *require* start-to-finish encryption =

listening on TCP 465!

Contrast the STARTTLS "as needed" mechanism with a full SSL/TLS connecti=
on =

to a web server listening on TCP 443, where the entire connection is =

encrypted: both sides need to negotiate encryption immediately, and both=
=

sides need to know from the start what they're getting into.
And just as with HTTP, an SMTP + full SSL/TLS ( =3D SMTPS) connection ca=
n be =

created which is completely encrypted (TCP 465 by default) before any SM=
TP =

commands are sent. Just as the https:// prefix tells the web browser to=
=

what it's getting into, the remote SMTP client connecting to 465 would =

need to be pre-configured to start the encryption handshake immediately,=
=

instead of sending any plain-text at all.

Which method is used -- SMTP + STARTTLS or SMTPS -- depends on both =

servers' capabilities.