Exchange --> Greylisting

5114 views
Skip to first unread message

Yizhar Hurwitz

unread,
Mar 4, 2006, 7:58:27 AM3/4/06
to
HI.

I had the same problem that was mentioned here before:
http://groups.google.com/group/microsoft.public.exchange.admin/browse_thread/thread/36cd5a8dabd3663d/09ff07ac14b116db

For those who doesn't know - greylisting is used on some mail servers to
tempfail first attempt of an email, asking the sending server to retry later.

In short (more details will follow) - Exchange 2003 SP2 failes to re-queue
messages sent to some servers that implement greylisting.
This does not happen all the time (some messages go through but sometimes it
fails).
When the problem happens, those emails are hidden in some kind of a black
hole, and the sender does not get an NDR nor Delay notification, even after
those timeouts expire.
Such messsages can remain "lost" for days or even weeks, until the SMTP or
Information Store service is restarted.
After a restart of SMTP service, Exchange suddenly finds those lost emails
(I guess they were in the Mailbox Store), and retries to send them or returns
NDR to the sender.

I have just openned a PSS case about this and working with Microsoft.
However this issue is not easy to re-produce, so I would like to get
feedback from you as well.

My questions to you -
Have you encountered similar problems, such as users complaining that they
got NDR for a message they sent 2 weeks before, or that the recipient calls
them and tell them "why did I got now and email you sent a week ago?"
(And you find out that the recipient server uses greylisting).

Meanwhile I have found those workarounds and currently I don't have the
problem, but it still needs further investigations:

Workaround 1: Send emails to greylisting domains via an ISP Smart Host
(using SMTP connector).

Workaround 2: Use scheduled tasks to restart SMTP service every day.

Workaround 3: Change SMTP virtual server retry timeouts (this does not seem
to help but I changed it anyway to values you can see below).


Here is a more detailed report that I have also sent to Microsoft PSS:


When sending outgoing email to mail server that implement greylisting,
sometimes Exchange retries the message later (as expected),
but sometimes Exchange simply does not retry delivery ,
and neither sends NDR nor Delay notification to the sender.
Two weeks later when I restart the SMTP service for installing security
updates (such as IMF updates),
then Exchange tries again to send those "lost" messages.

The problem seems sporadic - sometime it works, sometimes it doesn't, with
the same configuration.

The problem appears with several different destination domains. The common
thing is that all of them use greylisting.

Description of the server
A single server with the following software:
Primary roles = DC + Exchange + File server.
Windows 2003 Standard SP1 (upgarded from win2000 about 1 year ago).
DC + DNS + FSMO ROLES (This is the only DC in the network).
Exchange 2003 SP2 with IMF configured and enabled.
Symatec Corporate 10.0.2 (file protection) + SMSMSE 5.0.1.208 (mail
protection).

Connection to the internet:
Cisco PIX 501 firewall ver 6.3(1)
ADSL line to the ISP (PPPoE).
ISP name = Bezeq International (www.bezeqint.net)

DNS settings:
The same server is an internal DNS server, and uses ISP servers as
"forwarders" .

SMTP connector settings:
Send using DNS (the default).

SMTP virtual server settings (related to the issue):
Logging = NCSA common log file format.
Delivery retry interval (I have change the defaults):
First retry = 1 minute
Second retry = 2 minutes
Third retry = 15 minutes
Subsequent retry = 30 minutes
Delay notification = 1 hours
Expiration timeout = 2 days

--
Yizhar Hurwitz
http://yizhar.mvps.org


----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=df7bcd16-0306-4787-a358-3888c4e1198f&dg=microsoft.public.exchange.admin

Andy David - [MVP]

unread,
Mar 4, 2006, 9:10:15 AM3/4/06
to


I would think using a SMTP gateway for all the outbound mail is the
best solution.

Yizhar Hurwitz

unread,
Mar 4, 2006, 9:17:26 AM3/4/06
to
HI

> I would think using a SMTP gateway for all the outbound mail is the
> best solution.

I agree, but:

The sepcific ISP smart host servers are problematic and have limits on relay
traffic which causes other problems.

I have found my workarounds, but there is still something to be fixed in
Exchange -
and I would like to help Microsoft find and fix it, to avoid future problems
at other Exchange sites.

Thanks,

--
Yizhar Hurwitz
http://yizhar.mvps.org

Uldry@discussions.microsoft.com François Uldry

unread,
Aug 25, 2006, 6:34:01 AM8/25/06
to
There is clearly a bug with the handling of messages put on hold by the
recipient server.

As a reference, the greylister does this :
Final-Recipient: rfc822;...@...
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp;450 <...@...>: Recipient address rejected: Greylisted
for 300 seconds (see...

Visibly, exchange 2k3 does not handle this SMTP answer properly and then
lose the message until an SMTP restart.

The original post was in April, is there any plan to fix this issue anytime
soon ?

François Uldry

Andy David - MVP

unread,
Aug 25, 2006, 8:16:58 AM8/25/06
to
On Fri, 25 Aug 2006 03:34:01 -0700, François Uldry <François
Ul...@discussions.microsoft.com> wrote:

>There is clearly a bug with the handling of messages put on hold by the
>recipient server.
>
>As a reference, the greylister does this :
>Final-Recipient: rfc822;...@...
>Action: failed
>Status: 4.0.0
>Diagnostic-Code: smtp;450 <...@...>: Recipient address rejected: Greylisted
>for 300 seconds (see...
>
>Visibly, exchange 2k3 does not handle this SMTP answer properly and then
>lose the message until an SMTP restart.
>
>The original post was in April, is there any plan to fix this issue anytime
>soon ?
>

I would open a case with PSS.

Kazys

unread,
Feb 1, 2007, 9:58:00 PM2/1/07
to
I hope this forum is the right way to get Microsoft to place some attention
on this odd behavior. It's Feb 2007, and searching for "GREYLIST" in
microsoft KB comes up with no hits. Will this problem at least be
acknowledged by the QA team ?

I have a recent Exchange 2003 SP2 install that is not a DC, and exhibits the
problem described very well by Hurwitz. It took a full day of analysing the
behavior in SMTP logs and user reports, and then web searching just to got to
this thread.

In particular greylist servers that send the SMTP 451 temporary error,
sometimes trigger this black holing of emails until server restart. In the
past month I had at least 33 messages 'dissappear'.

Here is an example of a message that dissappeared from the SMTPSVC log.
Private data obscured. It is curious that Exchange, in this example, retried
then gave up. The resend never appears again in the logs until after the
server was restarted. Silent non-delivery is a SERIOUS problem.

15:44:21 ###.###.239.218 OutboundConnectionResponse - 25 -
220+l4dupmt2.greylistingcompany.com+ESMTP+Sendmail+8.13.4/8.13.4;+Mon,+8+Jan+2007+09:43:48+-0600+(CST) 0 90 0
15:44:21 ###.###.239.218 OutboundConnectionCommand - 25 EHLO
mail.homecompany.com 0 4 0
15:44:21 ###.###.239.218 OutboundConnectionResponse - 25 -
250-l4dupmt2.greylistingcompany.com+Hello+ip##-###-##-###.z##-###-###.customer.algx.net+[###.###.###.###],+pleased+to+meet+you 0 111 0
15:44:22 ###.###.239.218 OutboundConnectionCommand - 25 MAIL
FROM:<sco...@homecompany.com>+SIZE=4464 0 4 0
15:44:22 ###.###.239.218 OutboundConnectionResponse - 25 -
250+2.1.0+<sco...@homecompany.com>...+Sender+ok 0 53 0
15:44:22 ###.###.239.218 OutboundConnectionCommand - 25 RCPT
TO:<joh...@greylistingcompany.com> 0 4 0
15:44:22 ###.###.239.218 OutboundConnectionResponse - 25 -
451+4.7.1+Greylisting+in+action,+please+come+back+in+00:13:00 0 61 0
15:44:22 ###.###.239.218 OutboundConnectionCommand - 25 RSET - 0 4 0
15:44:22 ###.###.239.218 OutboundConnectionResponse - 25 -
250+2.0.0+Reset+state 0 21 0
15:44:22 ###.###.235.218 OutboundConnectionResponse - 25 -
220+l98upmt1.greylistingcompany.com+ESMTP+Sendmail+8.13.4/8.13.4;+Mon,+8+Jan+2007+09:44:24+-0600+(CST) 0 90 0
15:44:22 ###.###.235.218 OutboundConnectionCommand - 25 EHLO
mail.homecompany.com 0 4 0
15:44:23 ###.###.235.218 OutboundConnectionResponse - 25 -
250-l98upmt1.greylistingcompany.com+Hello+ip##-###-##-###.z##-###-###.customer.algx.net+[###.###.###.###],+pleased+to+meet+you 0 111 0
15:44:23 ###.###.235.218 OutboundConnectionCommand - 25 MAIL
FROM:<sco...@homecompany.com>+SIZE=4464 0 4 0
15:44:23 ###.###.235.218 OutboundConnectionResponse - 25 -
250+2.1.0+<sco...@homecompany.com>...+Sender+ok 0 53 0
15:44:23 ###.###.235.218 OutboundConnectionCommand - 25 RCPT
TO:<joh...@greylistingcompany.com> 0 4 0
15:44:23 ###.###.235.218 OutboundConnectionResponse - 25 -
451+4.7.1+Greylisting+in+action,+please+come+back+in+00:12:25 0 61 0
15:44:23 ###.###.235.218 OutboundConnectionCommand - 25 RSET - 0 4 0
15:44:23 ###.###.235.218 OutboundConnectionResponse - 25 -
250+2.0.0+Reset+state 0 21 0
15:44:23 ###.###.235.218 OutboundConnectionCommand - 25 QUIT - 0 4 0
15:44:23 ###.###.235.218 OutboundConnectionResponse - 25 -
221+2.0.0+l98upmt1.greylistingcompany.com+closing+connection 0 48 0

Yizhar Hurwitz

unread,
Feb 9, 2007, 10:56:00 AM2/9/07
to
HI.

Just some notes to update those that are reading about the problem:


* The workarounds described in my initial post here, worked for me.
I don't know which one of them did the trick.

1. Use "Microsoft Update"/automatic updates to install latest updates for
Exchange (and Windows).

2. Use a batch file to restart the SMTP service every day.

3. Take a look at the other workarounds that I wrote in my previos post here.


* I have openned a case at PSS, about a year ago,
but the case was closed, simply because I wasn't able to reproduce the
problem.
The Microsoft PSS team were a bit small-minded, and focused on my specific
case only.
They didn't try to reserach and contact other sysadmins globaly that had the
same problem,
and they didn't escelate it to the development team.


* Since posting here, I get once in a several weeks an email from another
sysadmin around the world,
facing the same problem.
If someone at Microsoft will take the intiative (or an MVP) -
I will send him a list of the contact sysadmins experiencing this problem
that contacted me about it.


Anyone else have news about this old undocumented bug in Exchange 2003 SP2?

--
Yizhar Hurwitz
http://yizhar.mvps.org

phend...@magnetrol.be

unread,
Feb 12, 2007, 9:30:41 AM2/12/07
to
Hi,

I came to this discussion group because I face the same EXACT problem.
Mails are being sent, but never reach the recipient, nor do they
notify the sender with an error or warning report. They are simply
gone.
But, indeed, after a reboot of our echange, all the mails were either
sent to the receipient or error messages were generated to the
sender.

Here's an extract of our SMTP log:

2007-02-12 12:18:45 195.228.###.9 OutboundConnectionResponse SMTPSVC1
HERCULES - 25 - - 220+mx1##.mail.t-online.hu+ESMTP 0 0 32 0 312 SMTP -
- - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionCommand SMTPSVC1
HERCULES - 25 EHLO - mail.#####.be 0 0 4 0 312 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionResponse SMTPSVC1
HERCULES - 25 - - 250-Requested+mail+action+okay,+completed 0 0 41 0
359 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionCommand SMTPSVC1
HERCULES - 25 MAIL - FROM:<.............@magnetrol.be>+SIZE=1323 0 0 4
0 359 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionResponse SMTPSVC1
HERCULES - 25 - - 250+2.1.0+Ok 0 0 12 0 484 SMTP - - - -
2007-02-12 12:18:45 195.228.240.9 OutboundConnectionCommand SMTPSVC1
HERCULES - 25 RCPT - TO:<emeszm@#####.hu> 0 0 4 0 484 SMTP 2007-02-12
12:18:45 195.228.240.9 OutboundConnectionResponse SMTPSVC1 HERCULES -
25 - - 451+4.2.0+<emeszm@######.hu>:+Recipient+address+rejected:+You
+are+greylisted+for+600+seconds 0 0 98 0 781 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionCommand SMTPSVC1
HERCULES - 25 RSET - - 0 0 4 0 781 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionResponse SMTPSVC1
HERCULES - 25 - - 250+2.0.0+Ok 0 0 12 0 828 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionCommand SMTPSVC1
HERCULES - 25 QUIT - - 0 0 4 0 844 SMTP - - - -
2007-02-12 12:18:45 195.228.###.9 OutboundConnectionResponse SMTPSVC1
HERCULES - 25 - - 221+2.0.0+Bye 0 0 13 0 891 SMTP - - - -

Please, Yizhar, could you show me how you create a batch file to
restart the SMTP service every day? This seems to be a workaround for
the time being, because this a SEROUS BUG!

Thanks and best regards,

Peter Henderickx
Exchange Admin Magnetrol International Belgium

andy webb

unread,
Feb 12, 2007, 10:49:09 AM2/12/07
to
I can also confirm that Exchange 2003 has a problem with 400 level responses
from destination mail servers.


<phend...@magnetrol.be> wrote in message
news:1171290641....@a75g2000cwd.googlegroups.com...

Yizhar Hurwitz

unread,
Feb 12, 2007, 1:55:01 PM2/12/07
to
HI.

The batch file workaround is very easy -

net stop smtpsvc
net start smtpsvc

Save it as a CMD file, and then use scheduled tasks.

I suggest that you contact PSS about this.
I did it myself a year ago, but I couldn't reproduce the problem and the PSS
team were too narrow minded to try escelating or researching the bug further
without reproducing it.

--
Yizhar Hurwitz
http://yizhar.mvps.org

Zuza

unread,
Feb 14, 2007, 9:55:10 AM2/14/07
to
I have exactly the same problem with our Exchange 2003 SP2 (all updates). Up
to tens of e-mails a day disappear and I have no idea how to track it and
recognize it. Each of them seems to be sent, no NDR, empty queues. But after
rebooting, Exchange starts to re-generate those old messages (I mean much
more older then 2 days, the oldest ones disappeared just after the last
reboot) or appropriate NDR´s (4.4.7, 4.7.1, 4.0.0). Affected emails were
usually sent to public mailers (no reliability, mailboxes may be full,
servers may be down..?) or to servers using greylisting (Exchange didn´t
retry..?).

I noticed this behavior last december for the first time. About this time we
made last automatic update of servers - just a coincidence?

It doesn´t seem to me, restarting server every day would be the best
solution. Maybe it reduces effects but it doesn´t solve causes.

Yizhar Hurwitz

unread,
Mar 1, 2007, 4:54:18 PM3/1/07
to
HI.

> I noticed this behavior last december for the first time. About this time we
> made last automatic update of servers - just a coincidence?

The updates caused the SMTP Service (or the whole server) to restart, and
this probably caused you to notice the problem for the first time.
So - the updates are probably not directly related to the problem, but the
services that were restarted.

> It doesn´t seem to me, restarting server every day would be the best
> solution.

It is a very good and effective workaround, that can be combined with other
methods.
Please note that you don't need to restart the whole server, but just the
SMTP service.


net stop smtpsvc
net start smtpsvc

This is a painless and highly recommended workaround until MS will come with
a fix.

> Maybe it reduces effects but it doesn´t solve causes.

Of course it is not the fix.
It took me about 1 year, to try to get MS attention about this problem.
Now finaly I've managed to escelate it to the Exchange team using some
fellow MVPs, and they are investigating it.

You can help them fix it!
You can contact PSS and tell them that you have that same specific problem,
tell them that this problem has already escelated to Exchange team, that you
would like to provide your own experience, and that you would like to test
the hotfix when/if they will provide it.

--
Yizhar Hurwitz
http://yizhar.mvps.org

Yizhar Hurwitz

unread,
Mar 14, 2007, 3:48:05 PM3/14/07
to
HI.

> Have Microsoft any official site/web or something about this problem ?
Not at the moment (as far as I know).

I suggest that you also contact PSS, tell them that your problem has already
escalated to the Exchange product team, and ask them to escalate your
issue/bug report as well without wasting too much of your (and their) time.

Meanwhile try to collect diagnostic data, such as:

SMTP logs:
http://www.msexchange.org/tutorials/Logging_the_SMTP_Service.html

Current event logs,
and future logs with diagnostic logging of MSExchangeTransport .

Then come back here and write your updates about your progress.

--
Yizhar Hurwitz
http://yizhar.mvps.org

"Marcel Glasa" wrote:

> We have also exactly the same problem with Greylisting (SMTP temporary errors
> 4xx) and updated Exchange 2003 SP2.
> I try to use SMTP restart script to solve this problem until Microsoft come
> with
> a fix.
>
> Have Microsoft any official site/web or something about this problem ?

andy webb

unread,
Mar 17, 2007, 2:07:04 PM3/17/07
to
Something I haven't tried yet, but was talking with someone about last week
was setting the Glitch Retry registry key. It's possible this isn't
correctly being defaulted in SP2 or some version of SMTP.

In HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing, create
"GlitchRetrySeconds" as a dword and try a value of 60 or 120. Then restart
the SMTP service.

By default, messages receiving a 4xx SMTP response are processed as a
"glitch" 3 times before being put back into the queue for processing on the
retry interval. It seems like something in this mechanism is failing. So,
if assertively setting GlitchRetrySeconds to a value that allows the
greylisting conditions to be satisfied, voila, a solution.

This is referenced a couple places:
http://technet.microsoft.com/en-us/library/8b43be56-48e6-400b-8014-54c95f87d1de.aspx
http://msexchangeteam.com/archive/2005/04/04/403297.aspx


"Yizhar Hurwitz" <Yizhar...@discussions.microsoft.com> wrote in message
news:A2034FA2-6A56-4EAF...@microsoft.com...

nico...@gmail.com

unread,
Mar 26, 2007, 4:19:59 AM3/26/07
to
Nice. Can anyone confirm that this is a working fix? I implemented it
but I have to wait till something goes wrong (or not)..


On 17 mrt, 20:07, "andy webb" <a...@swinc.com.spamsucks.com> wrote:
> Something I haven't tried yet, but was talking with someone about last week
> was setting the Glitch Retry registry key. It's possible this isn't
> correctly being defaulted in SP2 or some version of SMTP.
>
> In HKLM\System\CurrentControlSet\Services\SMTPSVC\Queuing, create
> "GlitchRetrySeconds" as a dword and try a value of 60 or 120. Then restart
> the SMTP service.
>
> By default, messages receiving a 4xx SMTP response are processed as a
> "glitch" 3 times before being put back into the queue for processing on the
> retry interval. It seems like something in this mechanism is failing. So,

> if assertively setting GlitchRetrySeconds to a value that allows thegreylistingconditions to be satisfied, voila, a solution.
>
> This is referenced a couple places:http://technet.microsoft.com/en-us/library/8b43be56-48e6-400b-8014-54...http://msexchangeteam.com/archive/2005/04/04/403297.aspx

uros....@gmail.com

unread,
Mar 28, 2007, 6:55:06 AM3/28/07
to
yes it worked !!!!!!!!!!!!!!
i made the smtp correction so the first retry is made in 1 minute
and the registry correction so the retry is made in 30 seconds

for me the problem is solved
bye

andy webb

unread,
Mar 29, 2007, 12:28:06 PM3/29/07
to
Excelent. Thanks for posting back your results.

Andy

<uros....@gmail.com> wrote in message
news:1175079306....@y80g2000hsf.googlegroups.com...

nico...@gmail.com

unread,
Mar 29, 2007, 3:31:03 PM3/29/07
to


Thanks.
It also worked for me.

Wolfgang Holesch

unread,
Apr 25, 2007, 10:46:01 AM4/25/07
to
It worked for me too, but I had to create the "Queuing" subkey first and
afterwards the "Glitch Retry" registry key.

Wolfgang

winterfro...@gmail.com

unread,
May 28, 2007, 4:12:12 PM5/28/07
to
We're having the same issue. In our case the recipient was even
"clever" enough to set a retry limit of 5 minutes on their side,
meaning that I've had to set our GlitchRetrySeconds to 3 minutes.
Hopefully it works.

I notice the original poster had Symantec AV for Exchange installed.
We've read elsewhere that these issues may be related to SMSMSE
somehow. I'm curious to know if others who are encountering this
problem are also using Symantec?


On Apr 25, 8:46 am, Wolfgang Holesch <TNMMNBBQK...@spammotel.com>
wrote:


> It worked for me too, but I had to create the "Queuing" subkey first and
> afterwards the "Glitch Retry" registry key.
>
> Wolfgang
>

b.r...@web.de

unread,
Jun 12, 2007, 5:49:34 AM6/12/07
to
We had the same problem and the glitch retry resoved it for this one
server with McAffee Group Shield and GFI Mailessentials so it´s not
connected to SMS but only to Microsoft. It´s actually a scandal that
Microsoft doesn´t react on this issue.
Bernd

bobsee...@gmail.com

unread,
Jun 12, 2007, 3:22:22 PM6/12/07
to

Well, at last I found something. I have had this particular problem
showing up for several months where upon server reboot after an
update, we'd get a bunch of NDRs for very old e-mails, and a bunch of
old e-mails would go out.
I had queried MS's forum about it, and the only suggestion was that it
might be caused by AV software on the Exchange server. Which I did
not have.

For a while, I was restarting the SMTP svc often and watching the
queues to watch for traffic. sometimes there were several and
sometimes none.

I was at a loss. I was noticing that when there were messages we'd
get several refusals from a particular organization we correspond with
a lot who uses greylisting. I had read up on that and concluded that
when the blackholed messages went out enmasse, that the greylisting
system was refusing them.

It happened again today, and when I went looking for more info, I
found this thread. I am releived to find out that it isn't just me
(sorry, guys and gals, but misery loves company).

I have just entered the described Registry key with the rety set for
120.

I'll check back in a couple weeks and let you know if I have seen
anymore blackholed messages.

Thanks a lot.

Bob

Yizhar Hurwitz

unread,
Jun 15, 2007, 5:56:00 AM6/15/07
to
HI.

I have just spoke with MS PSS (second level) about this today.

They would like you to open a PSS case, and reference the case ID which I
have openned.

Here is a quote of what they have asked me to write - please note the
following line:

When you raise your support call, please ask that they link the call to the
EMEA case SRZ060302000872


***** quote from MS PSS: *****

If you are having an issue with greylisting, please review the problem
description below. Should your problem match the description below and the
workaround works for you, Microsoft has advised me to ask you to raise a
support call with them. When you raise your support call, please ask that
they link the call to the EMEA case SRZ060302000872. This way, should a
number of customers be seeing the problem, it can be tracked within Microsoft.


SYMPTOMS
=========
When Exchange tries to send mails to certain domains that implement
‘greylisting’, the mails fail to get delivered, without any intimation to the
sender on the first attempt. Thereafter on either restarting the server or
SMTP service, the mails get delivered to the destination domains. At times,
NDRs for these delayed mails are also generated after rebooting.

PROBLEM
========
The issue is intermittent and occurs only when the destination domains have
greylisting implemented and mail is sent to the greylisted domain the very
first time.

WORKAROUND
============
1. Write a script to restart the SMTP service at least once a day.
2. Modify the registry on the sender Exchange server, to change
the Glitch Retry key.
3. Clarify that there is no 3rd party AV software in the
environment which could be causing the issue.


--
Yizhar Hurwitz
http://yizhar.mvps.org

"bobsee...@gmail.com" wrote:

> On Jun 12, 4:49 am, b.ra...@web.de wrote:
> > We had the same problem and the glitch retry resoved it for this one

> > server with McAffee Group Shield and GFI Mailessentials so it4s not
> > connected to SMS but only to Microsoft. It4s actually a scandal that
> > Microsoft doesn4t react on this issue.

Support@discussions.microsoft.com Diadem Support

unread,
Jul 27, 2007, 4:38:01 AM7/27/07
to
Hi,

I totally agree with this problem as we are using qmail with greylisting
enabled. Some of our client complaints that they sometimes don’t receive
mails from the domains running MS Exchange SMTP Server. But we have found
records in Greylisting database and Server SMTP connection log but not the
mail.

But this is hard to find a relevant solution.

Thanks & Regards,
Diadem Support

dblml

unread,
Jul 31, 2007, 2:30:09 PM7/31/07
to
There is no "\Queuing" ??

Rich Matheisen [MVP]

unread,
Jul 31, 2007, 8:27:53 PM7/31/07
to
dblml <db...@discussions.microsoft.com> wrote:

>There is no "\Queuing" ??

Create the key. Then create the value in the new key.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com

Jack155Q4

unread,
Aug 7, 2007, 4:54:30 AM8/7/07
to
Hi,

Just to say, I am having the same problem on my SBS 2003 SP2 with
Exchange SP2. I have followed the brilliant help and workarounds here
and will monitor progress.
Another user who is very keen on a fix from MS!

Jack

Jack155Q4

unread,
Aug 7, 2007, 4:54:42 AM8/7/07
to

Rich Matheisen [MVP]

unread,
Aug 7, 2007, 9:48:40 PM8/7/07
to

Jack155Q4

unread,
Aug 10, 2007, 5:12:06 AM8/10/07
to
On Aug 8, 2:48 am, "Rich Matheisen [MVP]"
<richn...@rmcons.com.NOSPAM.COM> wrote:

> Jack155Q4 <jackhod...@gmail.com> wrote:
> >Just to say, I am having the same problem on my SBS 2003 SP2 with
> >Exchange SP2. I have followed the brilliant help and workarounds here
> >and will monitor progress.
> >Another user who is very keen on a fix from MS!
>
> Try this:http://support.microsoft.com/kb/934709/en-us
>
> --
> Rich Matheisen
> MCSE+I, Exchange MVP
> MS Exchange FAQ athttp://www.swinc.com/resource/exch_faq.htm

> Don't send mail to this address mailto:h.p...@getronics.com
> Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcphucknuc...@getronics.com mailto:melvin.mcphucknuc...@pinkroccade.com

Thanks Rich,
I have installed this and will keep a close eye on the server.
Jack

ralfthewise

unread,
Aug 23, 2007, 11:19:21 AM8/23/07
to
We use greylisting as well and have the same problem when people try
to email us from exchange boxes. Is there anything we can do if we're
on the receiving end of this problem? Very frustrating when a poorly
implemented server on MS part prevents the use of an anti-spam tool.
Does it happen with all 4XX SMTP codes? Maybe we could use something
other than 451 and exchange would handle it better.

On Jul 27, 1:38 am, Diadem Support <Diadem


Supp...@discussions.microsoft.com> wrote:
> Hi,
>
> I totally agree with this problem as we are using qmail withgreylisting
> enabled. Some of our client complaints that they sometimes don't receive
> mails from the domains running MS Exchange SMTP Server. But we have found

> records inGreylistingdatabase and Server SMTP connection log but not the


> mail.
>
> But this is hard to find a relevant solution.
>
> Thanks & Regards,
> Diadem Support
>
> "Yizhar Hurwitz" wrote:
> > HI.
>
> > I had the same problem that was mentioned here before:

> >http://groups.google.com/group/microsoft.public.exchange.admin/browse...
>
> > For those who doesn't know -greylistingis used on some mail servers to


> > tempfail first attempt of an email, asking the sending server to retry later.
>
> > In short (more details will follow) - Exchange 2003 SP2 failes to re-queue
> > messages sent to some servers that implementgreylisting.
> > This does not happen all the time (some messages go through but sometimes it
> > fails).
> > When the problem happens, those emails are hidden in some kind of a black
> > hole, and the sender does not get an NDR nor Delay notification, even after
> > those timeouts expire.
> > Such messsages can remain "lost" for days or even weeks, until the SMTP or
> > Information Store service is restarted.
> > After a restart of SMTP service, Exchange suddenly finds those lost emails
> > (I guess they were in the Mailbox Store), and retries to send them or returns
> > NDR to the sender.
>
> > I have just openned a PSS case about this and working with Microsoft.
> > However this issue is not easy to re-produce, so I would like to get
> > feedback from you as well.
>
> > My questions to you -
> > Have you encountered similar problems, such as users complaining that they
> > got NDR for a message they sent 2 weeks before, or that the recipient calls
> > them and tell them "why did I got now and email you sent a week ago?"
> > (And you find out that the recipient server usesgreylisting).
>
> > Meanwhile I have found those workarounds and currently I don't have the
> > problem, but it still needs further investigations:
>

> > Workaround 1: Send emails togreylistingdomains via an ISP Smart Host

> >http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...


Rich Matheisen [MVP]

unread,
Aug 23, 2007, 9:39:38 PM8/23/07
to
ralfthewise <ralft...@gmail.com> wrote:

>We use greylisting as well and have the same problem when people try
>to email us from exchange boxes. Is there anything we can do if we're
>on the receiving end of this problem? Very frustrating when a poorly
>implemented server on MS part prevents the use of an anti-spam tool.

It doesn't prevent your use of greylisting at all. The problem lies on
the sender's side, not the recipient's.

What do you do about sending servers that only retry so infrequently
that the greylist "memory" expires and every retry on their part is
greylisted?

>Does it happen with all 4XX SMTP codes? Maybe we could use something
>other than 451 and exchange would handle it better.

I doubt it.

--
Rich Matheisen
MCSE+I, Exchange MVP

MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm


Don't send mail to this address mailto:h.p...@getronics.com

Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com

ralfthewise

unread,
Aug 27, 2007, 3:18:01 PM8/27/07
to
On Aug 23, 6:39 pm, "Rich Matheisen [MVP]"
<richn...@rmcons.com.NOSPAM.COM> wrote:
> It doesn't prevent your use ofgreylistingat all. The problem lies on

> the sender's side, not the recipient's.
Yes, but when I go to management and tell them, "There's this helpful
practice to reduce spam called greylisting, but some mail sent from
Exchange systems may silently get dropped", they tell me no way.

> What do you do about sending servers that only retry so infrequently
> that the greylist "memory" expires and every retry on their part is
> greylisted?

Well, we haven't encountered that problem yet, but I guess you could
just increase the retry window to accomodate them. That may not scale
well for really large sites, but any company with less than a couple
thousand employees would probably be fine.

Rich Matheisen [MVP]

unread,
Aug 27, 2007, 8:40:08 PM8/27/07
to
ralfthewise <ralft...@gmail.com> wrote:

>On Aug 23, 6:39 pm, "Rich Matheisen [MVP]"
><richn...@rmcons.com.NOSPAM.COM> wrote:
>> It doesn't prevent your use ofgreylistingat all. The problem lies on
>> the sender's side, not the recipient's.
>Yes, but when I go to management and tell them, "There's this helpful
>practice to reduce spam called greylisting, but some mail sent from
>Exchange systems may silently get dropped", they tell me no way.

You have a problem explaining things. :-) You forgot the word
"malfunctioning" between "from" and "Exchange".

http://support.microsoft.com/kb/934709

Your Exchange server is already quite happy to send malformed MIME
messages to Internet recipient. What do they say to that? How do you
explain to them that Exchange is quite happy to accept malfomed MIME
messages that can't be read by anyone?

Blindly accepting every email sent your way is bad news. You're not
responsible for the maintenance of the Internet. You'll find buggy
MTAs in lots of places. :-(

>> What do you do about sending servers that only retry so infrequently
>> that the greylist "memory" expires and every retry on their part is
>> greylisted?
>Well, we haven't encountered that problem yet, but I guess you could
>just increase the retry window to accomodate them.

. . . assuming that's a configurable value. :-)

>That may not scale
>well for really large sites, but any company with less than a couple
>thousand employees would probably be fine.

Or you could ask them to retry a bit more frequently, especially
during the 1st 60 minutes, or so.

Deidok@discussions.microsoft.com Antje Deidok

unread,
Sep 3, 2007, 11:38:06 AM9/3/07
to
Hi,

we are having the same problem.
We found it last week and this is a very strange issue!

I hope there will be a fix in the near future.
At this point of time we are restarting the inetinfo service every night.


Antje

goog...@pelitech.com

unread,
Sep 5, 2007, 7:06:13 AM9/5/07
to
Hi all,

Like many, I've just come across this issue. A few questions for
those in the know...

1) Some of my remote recipient mailservers are setting their
greylisting retry to 600 seconds. Do I therefore need to set my
GlitchRetryValue to > 200, to get it over the 600 second limit with 3
retries? I set it to 220 but, JUST did it, so don't have any results
yet. I also am restarting SMTP nightly just in case.

2) I see a hotfix in that MSDN link above...is it worth getting, or
will this workaround do the same thing?

I'm interested in other results...this has been a very, very upsetting
issue for my client.

Thanks, Markus

Lackey@discussions.microsoft.com Eric Lackey

unread,
Sep 15, 2007, 8:38:00 PM9/15/07
to
We're seeing the same thing here with Exchange 2003 SP2. After server
reboot, users complaining of old email (from July) sent again.

Andy David {MVP}

unread,
Sep 15, 2007, 10:24:55 PM9/15/07
to

http://support.microsoft.com/default.aspx?scid=kb;EN-US;934709
"On a Windows Server 2003-based SMTP gateway server, some messages may
remain in the queue folder until the SMTP service is restarted"


Yizhar Hurwitz

unread,
Sep 16, 2007, 6:46:00 PM9/16/07
to
HI.

> 1) Some of my remote recipient mailservers are setting their
> greylisting retry to 600 seconds. Do I therefore need to set my
> GlitchRetryValue to > 200, to get it over the 600 second limit with 3
> retries?

No (as far as I understand).
If the message will fail greylisting during the "glitch" time but thereafter
will go to the queue, this is fine.

> I set it to 220 but, JUST did it, so don't have any results
> yet. I also am restarting SMTP nightly just in case.

Good.


> 2) I see a hotfix in that MSDN link above...is it worth getting, or
> will this workaround do the same thing?

Yes.
The following hotfix might help, as far as I understand:


On a Windows Server 2003-based SMTP gateway server, some messages may remain

in the queue folder until the SMTP service is restarted:
http://support.microsoft.com/default.aspx/kb/934709/en-us


> I'm interested in other results...this has been a very, very upsetting
> issue for my client.

Indeed.

joachim...@akdae.de

unread,
Oct 8, 2007, 9:32:13 AM10/8/07
to
On 17 Sep., 00:46, Yizhar Hurwitz
<YizharHurw...@discussions.microsoft.com> wrote:

> > I set it to 220 but, JUST did it, so don't have any results
> > yet. I also am restarting SMTP nightly just in case.
>
> Good.
>

Foreword: [Same Problem - Thankyou for this excellent information
page!!!]

My Question:
I there anybody who can tell me what the best setting for the "glitch"
entry is? I've heard 60, 120, 220... Does anybody has results?

Thankyou!

Rich Matheisen [MVP]

unread,
Oct 8, 2007, 8:31:57 PM10/8/07
to
joachim...@akdae.de wrote:

The answer is "not too short, and not too long". Too short and the
greylisting server will just sent another 4xx status. Too long and
you'll start to create a performance problem on your server.

The interval at which you retry depends on the greyliting servers you
deal with, not something on your server.

Yizhar Hurwitz

unread,
Oct 21, 2007, 1:11:01 PM10/21/07
to
HI.

> My Question:
> I there anybody who can tell me what the best setting for the "glitch"
> entry is? I've heard 60, 120, 220... Does anybody has results?

It doesn't realy matters, as long as your server can re-queue and resend the
message.
I think that 60-120 is reasonable.

The following hotfix is supposed to fix the underlying bug:

On a Windows Server 2003-based SMTP gateway server, some messages may remain
in the queue folder until the SMTP service is restarted:

http://support.microsoft.com/?kbid=934709

--
Yizhar Hurwitz
http://yizhar.mvps.org

baj...@gmail.com

unread,
Oct 29, 2007, 6:41:28 AM10/29/07
to
Big thanks for Yizhar for excellent thread. I was loosing my mind with
that issue.

barberless

unread,
Dec 5, 2007, 12:35:28 PM12/5/07
to
Thanks for this information. The same problem has occurred on our Exchange
2003 Server SP2 for the past couple of months, but only started in the past
few months. This is a critical issue for us. I hope that MS resolves it
soon. I did a registry search for a "glitch retry" key as suggested in
another post, but there is no key on my server. Searches through the mskb
return no hits for greylisting or glitch retry. Restarting smtp each day is
not an elegant solution.

"Yizhar Hurwitz" wrote:

> HI.
>
> I had the same problem that was mentioned here before:

> http://groups.google.com/group/microsoft.public.exchange.admin/browse_thread/thread/36cd5a8dabd3663d/09ff07ac14b116db
>
> For those who doesn't know - greylisting is used on some mail servers to

> tempfail first attempt of an email, asking the sending server to retry later.
>
> In short (more details will follow) - Exchange 2003 SP2 failes to re-queue
> messages sent to some servers that implement greylisting.
> This does not happen all the time (some messages go through but sometimes it
> fails).
> When the problem happens, those emails are hidden in some kind of a black
> hole, and the sender does not get an NDR nor Delay notification, even after
> those timeouts expire.
> Such messsages can remain "lost" for days or even weeks, until the SMTP or
> Information Store service is restarted.
> After a restart of SMTP service, Exchange suddenly finds those lost emails
> (I guess they were in the Mailbox Store), and retries to send them or returns
> NDR to the sender.
>
> I have just openned a PSS case about this and working with Microsoft.
> However this issue is not easy to re-produce, so I would like to get
> feedback from you as well.
>
> My questions to you -
> Have you encountered similar problems, such as users complaining that they
> got NDR for a message they sent 2 weeks before, or that the recipient calls
> them and tell them "why did I got now and email you sent a week ago?"
> (And you find out that the recipient server uses greylisting).
>
> Meanwhile I have found those workarounds and currently I don't have the
> problem, but it still needs further investigations:
>

> Workaround 1: Send emails to greylisting domains via an ISP Smart Host

> --
> Yizhar Hurwitz
> http://yizhar.mvps.org
>
>

> ----------------
> This post is a suggestion for Microsoft, and Microsoft responds to the
> suggestions with the most votes. To vote for this suggestion, click the "I
> Agree" button in the message pane. If you do not see the button, follow this
> link to open the suggestion in the Microsoft Web-based Newsreader and then
> click "I Agree" in the message pane.
>

> http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=df7bcd16-0306-4787-a358-3888c4e1198f&dg=microsoft.public.exchange.admin

Andy David {MVP}

unread,
Dec 5, 2007, 9:21:21 PM12/5/07
to
On Wed, 5 Dec 2007 09:35:28 -0800, barberless
<barbe...@discussions.microsoft.com> wrote:

>Thanks for this information. The same problem has occurred on our Exchange
>2003 Server SP2 for the past couple of months, but only started in the past
>few months. This is a critical issue for us. I hope that MS resolves it
>soon. I did a registry search for a "glitch retry" key as suggested in
>another post, but there is no key on my server. Searches through the mskb
>return no hits for greylisting or glitch retry. Restarting smtp each day is
>not an elegant solution.


http://support.microsoft.com/kb/934709/en-us

RRamos

unread,
Dec 6, 2007, 1:21:01 PM12/6/07