I would like mail sent to unknown users to simply disappear - i.e., no NDR
(which fills up the Badmail folder) just reject it, delete it, whatever. Is
there a setting that will make this happen? I still want to get NDRs for
messages I send.

[quoted text, click to view]

Mail sent to unknown users should never be accepted by your server; it
should always be rejected at the SMTP envelope stage.

Check the recent posts about 5xxSink and download here:

http://www.imprimia.com/products/software/freeutils/5xxsink/download/release

[quoted text, click to view]

I'm using 5xxSink and can confirm that it works perfectly and will do
exactly what you are after as I was in the same boat!
Now I don't have anything stuck in the queue folder and the badmail folder
is typically empty :-)

Best!
Marvin

[quoted text, click to view]

I searched (using find in Outlook Express) and didn't see any other posts
regarding 5xxSink. However, I did download and install it. Unfortunately, it
also seems to prevent *me* from sending mail to anyone *not* in the list
(i.e. in other domains). Although the documentation doesn't specifically
state this, it seems to imply that I need a separate virtual server for
inbound and outbound mail to get around this problem. Is that correct?

[quoted text, click to view]

Hmm, weird, they're in Google Groups.

[quoted text, click to view]

OK.

[quoted text, click to view]

That's right.

5xxSink is designed for MXs, as opposed to submission servers. It
disregards relay-by-auth and relay-by-IP permissions on the virtual
server that it's bound to. So it would indeed be necessary to have a
second virtual server for submissions.

On that note, it is advisable for several reasons to manage
submissions separately from deliveries.

For one, many ISPs do not allow users to submit mail to 3rd-party
servers on port 25, because these submissions look largely the same as
(spam) deliveries. They will allow connections to the standard
submission port 587. Yes, you could bind :25 and :587 on the same
virtual server in IIS, but splitting them across two different
virtuals is just as easy.

Second, having separate queues for different types of mail helps you
distinguish traffic by origin and have different queue retry cycles
for each. For example, if you are gatewaying for a variety of remote
mailbox servers, you may want to guarantee store-and-forward for 24
hours to those domains, while for other remote domains, you can set a
15 minute/4 hours retry cycle.

Third, you can enforce SSL encryption (SMPTS) on your submission
server without affecting the MX, which must by allow unencrypted
sessions. This gives you a good-faith way of offering secure channels
to all of your mobile users.

[quoted text, click to view]

I'll search Google then.

[quoted text, click to view]

I assume you meant SMTPS - would I need to get a SSL certificate in order to
set that up?

[quoted text, click to view]

Oops, typo. Yes, you need a cert, though you can use an internally
generated (and free) cert if you have a means to distribute CA certs to
your users (and if they're good at following orders). Same as HTTPS.

[quoted text, click to view]

OK, I implemented a submission server on port 587 per your suggestion.
Everything seems to be fine except for one small problem: I am unable to
send to other users on my own domain. I checked and the message I sent is
sitting in the Drop folder. Did I err by using the same domain name for the
submission virtual server? What domain name should I use for it, or indeed
does it matter? Could I use a subdomain like submit.mydomain.com?

[quoted text, click to view]

Yep, that makes it the Local (Default) domain.

Give it exactly the same name as the other VS. It's on the same IP, after
all, and hostnames don't change based on ports.