Email Messages always stuck in queue foder

[CQ]

Hi there,
We setup the default smpt virtual server on Windows Server 2003 SP 2 IIS 6,
and we have a web application installed to send out bulk emails about 1000
every week, and a few other web applications sent out customer feedback
emails from time to time on request basis about 5 - 10 emails every week.
but we found out the email messages always stuck in the queue folder for a
few days, there is no new email can be sent out until we restart the SMTP
service, and this happens 1 - 2 times a week.
Below are some SMTP Virtual Server configurations:
1. Limit number of connections to: 500
2. Connection time-out(minutes) 10
3. Limit message size to 4096 KB
4. Limit session size to 10240 KB
5. Limit number of messages per connection to: 10
6. Limit number of recipients per message to: 100
7. Maximum hop count: 15
8. First outbound retry interval 12 minutes
9. 2nd retry outbound interval 20 minutes
10. 3r retry interval 65 minutes
11. subsequent retgry interval 240 minutes
12. delay notification: 12 hours
13. expiration timeout: 2 days
14. Local Delay notification: 12 hours
15. Expiration timeout: 2 days
and the bandwidth is about 10 MB.

Any suggestion is appreciated.

Best Regards
Chen Qiang

[Sanford Whiteman]

There are a couple of possible causes for this problem as described.
Unfortunately, one of the most likely is also one that you can't fix: IIS
SMTP has a bug in dealing with some remote servers that implement
greylisting, and in these cases the queue becomes stuck until service
restart. Although I don't experience this bug anymore at my client sites,
I'm told that the bug has never been satisfactorily fixed for all possible
cases.

Check the related hotfix from here:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;934709

More optimistically, the same behavior can come from a virus scanner that
is erroneously set to scan the queue folder. None of the SMTP service
folders should be scanned.

Finally, ensure that all of your DNS servers are functioning without
error. Note that this pertains to the DNS servers used _by your
mailserver_ -- not necessarily the DNS servers used by your personal
workstation. Try installing a local caching DNS server on the IIS SMTP
box itself if you have not already done so.

--Sandy

------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
------------------------------------

[CQ]

Thanks Sanford, I will try the hotfix then.

[Brian Z]

I just troubleshot this type of problem for 2 days and finally figured it
out. One the OUTBOUND server, you need to chck the box that uses SSL
security TTL I think? There should already be a default certificate on the
server. We had this issue where anonymous worked, but basic auth did not.
Also check your relays are added (like local host) Lastly, ping your machine
name. If you are using basic auth, you can telenet and use Base64 translator
to enter the password.

"CQ" <C...@discussions.microsoft.com> wrote in message
news:91637ECB-B018-4F34...@microsoft.com...

[Sanford Whiteman]

> I just troubleshot this type of problem for 2 days and finally figured it
> out. One the OUTBOUND server, you need to chck the box that uses SSL
> security TTL I think? There should already be a default certificate on
> the
> server. We had this issue where anonymous worked, but basic auth did not.
> Also check your relays are added (like local host) Lastly, ping your
> machine
> name. If you are using basic auth, you can telenet and use Base64
> translator
> to enter the password.

The way this problem was described, it has nothing to do with outbound
TLS. "Bulk e-mails" are rarely sent to remote servers that require an
encrypted connection.

When messages are stuck in the queue, that means they were already
accepted for relay.

You're also mixing together SSL/TLS and SMTP AUTH terminology, which are
not necessarily related at all.

-- Sandy

[Brian Z]

Have you set up an IIS7 server with SMTP basic authentication and then tried
to relay? If the 2 are not related, why is the checkbox on the outbound SMTP
tab? I was just trying to give the guy suggestions to try, because using
the SSL cert worked for me.

"Sanford Whiteman" <swhitemanlis...@cypressintegrated.com> wrote
in message news:op.uzmv6...@gw02.broadleaf.local...

[Sanford Whiteman]

> Have you set up an IIS7 server with SMTP basic authentication and then
> tried to relay?

We've configured IIS5-7 SMTP hundreds of times and relay millions of
messages daily through IIS SMTP servers.

Relay permissions in any modern mailserver relate to inbound connections.
That's because the meaning of "relay" is "accept and queue a message with
a non-local recipient domain". Once a message has been queued and is
waiting to be serviced by an outbound connection, relay has been allowed.
You would have to have a complex, deliberate, and misguided policy set to
allow messages to be accepted and queued, but be ignored by outbound
connections because the submitting connection did not fit a requirement --
a requirement that you did not bother to enforce during the inbound stage.

> If the 2 are not related, why is the checkbox on the outbound SMTP tab?

The checkbox for outbound TLS and the radio buttons for outbound AUTH are
not mutually exclusive nor interdependent. That's why there are two
different interface widgets. That they are both "related" to mail
transmission and therefore to each other is obvious... and that they would
appear on the same Outbound Security form is unsurprising because they are
different forms of security.

If you are communicating with remote MXs that require authentication, you
would know it. You don't send "bulk mail" to domains that require this
level of special handling, and such domains should be hard-coded as
individual Remote Domains if the server may connect to any server that
does not have this requirement.

If you are communicating with remote MXs that require explicit encryption
(STARTTLS), you would also know it, and those domains should be hard-coded
as Remote Domains as above. Also note that RFC 2487 prohibits a
publicly-referenced mailserver from requiring STARTTLS.

> I was just trying to give the guy suggestions to try, because using
> the SSL cert worked for me.

TLS and AUTH are independent factors, as are inbound relay and outbound
connection requirements.

Telling somebody to use TLS and/or AUTHed outbound connections to unknown
remote domains is going to cause more problems than it solves.

Telling them to install a server cert (which is only necessary for the
inbound connection) when messages are already being successfully queued
does not follow.

-- Sandy