Exchange --> Greylisting
Yizhar Hurwitz
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.
Andy David - [MVP]
I would think using a SMTP gateway for all the outbound mail is the
best solution.
Yizhar Hurwitz
> 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
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
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
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
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
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
from destination mail servers.
<phend...@magnetrol.be> wrote in message
news:1171290641....@a75g2000cwd.googlegroups.com...
Yizhar Hurwitz
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
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
> 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
> 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
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
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
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
Andy
<uros....@gmail.com> wrote in message
news:1175079306....@y80g2000hsf.googlegroups.com...
nico...@gmail.com
Thanks.
It also worked for me.
Wolfgang Holesch
afterwards the "Glitch Retry" registry key.
Wolfgang
winterfro...@gmail.com
"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
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
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
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
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
Rich Matheisen [MVP]
>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
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
Rich Matheisen [MVP]
Jack155Q4
<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
Thanks Rich,
I have installed this and will keep a close eye on the server.
Jack
ralfthewise
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]
>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
<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.
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]
>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
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
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
reboot, users complaining of old email (from July) sent again.
Andy David {MVP}
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
> 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
<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]
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
> 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
that issue.
barberless
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.
>
Andy David {MVP}
<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
resolution to this issue. We started experiencing this glitches last month
and continue to frustrate our end users as well as myself. Glad to have
encountered this discussion group and find some answers.
I will try to apply the fix you all have suggested especially creating the
glitch retry interval.
Thank you very much,
Robert R.
goo...@grossfurtner.com
Working on a SBS2003 I applied the MS-Patch as well as the
modification of the glitch retry intervall to the server in October.
First impression after intense monitoring in the first month: troubles
are gone.
But now - after a maintenance restart last evening I notice, that I
get notifications of undelivered emails again, starting at the end of
November.
I checked the Logfiles but did not notice any change within the system
around this time - not even an update that has been installed.
Is there anyone sharing my experience - returning troubles in spite of
the solutions applied?
Best regards,
Christof Grossfurtner
Yizhar Hurwitz
> Working on a SBS2003 I applied the MS-Patch as well as the
> modification of the glitch retry intervall to the server in October.
> First impression after intense monitoring in the first month: troubles
> are gone.
Have you applied the supposed fix:
http://support.microsoft.com/kb/934709/en-us
???
Yizhar Hurwitz
If you came accross this discussion, please also take a look at the follow
up here:
Subject: Exchange 2003 SP2 Greylisting bug - survey
http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.exchange.admin&mid=fc8bb613-1304-4e9d-89dd-8e9fd467c234&sloc=en-us
For those looking for the botton line, this update from MS seems to fix the
problem but it is not yet confirmed:
http://support.microsoft.com/kb/934709/en-us
"On a Windows Server 2003-based SMTP gateway server, some messages may
remain in the queue folder until the SMTP service is restarted"
My suggestion is to apply that update, but also keep monitoring your server
logs,
and restart SMTP service daily (or at least weekly).
This is quick and painless.
Other workarounds can also help if you still have the problem, such as the
glitchretry setting.
Hmmmm....
More then two years since I and other people had the problem (nov 2005), and
this discussion and others are still active.
Let's see how long it will go in 2008... 2009... nnnn...
Unknown
>
> Have you applied the supposed fix:
> http://support.microsoft.com/kb/934709/en-us
>
yes, I did apply that and also confirmed that the replaced "aqueue.dll" is
now Version 6.0.3790.4094, dated 6th of June 2007.
GlitchRetrySeconds is 300, PerMsgFailuresBeforeMarkingAsProblem is set to
five.
The weird thing is that in todays logfiles (w3) all messages seem to be
handed absolutely correct:
First try:
2007-12-17 10:34:24 xxx.xxx.xxx.xxx SMTPSVC1 SERVER01 - 25 - -
450+<xxxxx...@xxxx.gv.at>:+Recipient+address+rejected:+Policy+Rejection-+Greylisted+for+00:05:00,+please+try+again+later.+See:+http://www.wien.gv.at/ma14/mails.html 0 0 167 0 141 SMTP - - - -
The next try is logged with exactly the same recipient, same time
(2007-12-17 10:34:24), same 450 rejection message, followed by the third try
at 2007-12-17 10:45:24. (I had set the glitch retry for todays testing to 660)
Which is confirmed with:
2007-12-17 10:45:30 xxx.xxx.xxx.xxx SMTPSVC1 SERVER01 - 25 - - 250+Ok 0 0 6
0 6093 SMTP - - - -
Also todays nightly restart did not bring up any unsent messages.
So now - under observation everything works smooth, but when the server
restarted last week, there were 33 emails from the last four weeks that had
not been sent with the same configuration :-(
best regards,
Christof Grossfurtner
Yizhar Hurwitz
> So now - under observation everything works smooth, but when the server
> restarted last week, there were 33 emails from the last four weeks that had
> not been sent with the same configuration :-(
Yes - this bug is indeed strange, sporadic and very dificult to track or
anticipate.
What you wrote is similar to the symptoms I have seen (2 years ago) ,
one day it looks fine and then one day you get the plump...
However I realy though (or hoped) that KB 934709 will put this saga,
and what you are writing seems to contradict that assumption.
My suggestion -
in addition to all the fixes, workarounds and logging,
keep the daily SMTP Service restart active.
And - let us know if it got better in 2008.
Happy new year!
--
Yizhar Hurwitz
http://yizhar.mvps.org
Steve Howden
It's baaaaa-aaack!
Same problem here. I have the hot fix applied and glitchretry at 120 secs.
All was seeming to be good for a few months but yesterday after a server
restart, the dreaded delayed mail NDRs popped up again
Looks like I'll have to put my SMTPSVC restart batch file back into action.
This is silly that it has been going on for so long.
We can only live in hope that a fix will turn up. (maybe the fix is called
Exchange 2007)
Happy New Year, Steve
Yizhar Hurwitz
> It's baaaaa-aaack!
> Same problem here. I have the hot fix applied and glitchretry at 120 secs.
I suggest that you contact PSS and provide your experience.
You can reference my initial case which is:
EMEA case SRZ060302000872
You can also reference this case ID:
SRQ070620601190
Take a look here also:
http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.exchange.admin&mid=fc8bb613-1304-4e9d-89dd-8e9fd467c234&sloc=en-us
Tell the person who answers you that this issue has already been escelated,
and you should ask to speak directly with 2nd level support team or higher.
Ask them also to forward your case to Mister:
> Looks like I'll have to put my SMTPSVC restart batch file back into action.
Good idea.
> This is silly that it has been going on for so long.
Yes indeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeed.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--
Yizhar Hurwitz
http://yizhar.mvps.org
Rodney
to someone in India? I have been having the same problem for the last year
and have gotten no where with them.
Thanks
"Yizhar Hurwitz" wrote:
> --
> Yizhar Hurwitz
> http://yizhar.mvps.org
>
>
Yizhar Hurwitz
> Is there an easier way to get this hotfix without waisting two hours speaking
> to someone in India?
Yes.
You can contact your local MS office in your country, they should send you a
form and then the hotfix itself,
without the need to open a PSS case.
But if you have already opened a PSS case, you can refer to the case I have
opened long ago,
that have already been escalated (BTW - I didn't close that case yet, but
they have seemed to forget about it).
This is a quote from MS:
******** Begin quote **********
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.
.....
******** End quote **********
The full quote and more information are available here:
Exchange 2003 SP2 Greylisting bug - survey
--
Yizhar Hurwitz
http://yizhar.mvps.org
kenko
I have the same problem on a SBS2003. I made a support call and mentioned
the support call id but it was closed.
I received the hotfix and installed it. Wait and see
Koen
Belgium
James@discussions.microsoft.com Gary James
correlate with reboots of the server and/or updates (which inevitably result
in a reboot). Not only do we get NDRs, but we also get duplicate messages
sent out to destination email servers. Thus the phone calls and email come
back saying: “Why are you sending me this again?"
In many cases the NDRs are a month or more old. We are opening a case with
MS for a permanent solution.
"andy webb" wrote:
> > --
> > Yizhar Hurwitz
> > http://yizhar.mvps.org
> >
> >
> >
efri...@gmail.com
Windows Server 2003 SP2
Exchange Server 2003 SP2
DC, DHCP, DNS
Set the glitch retry
applied the MSFT hotfix (which now states that its not to be used on a
server running Exchange, only a stand alone Windows 2003 box.)
Altered my retry intervals
Restart the SMTP service.
I took the process slowly. Making 1 change at a time. For the past
month things have been fine but now I have SMTP service issues. The
SMTP service is not restarting properly. It hangs on restart. I've
got no indication why from the event logs. Only killing the inetinfo
process will then free SMTP to startup correctly. This is
particularly bad because I restart the SMTP service daily with a
scheduled task (or did until I decided that I could not reliably run
the task).
So far I've found nothing to indicate what my problem with SMTP may
be.
Any thoughts? Has anyone else had this problem?
Tom
I wonder is there anyway we request companies that use greylisting to add a
domain to a whitelist?
Rich Matheisen [MVP]
alaskann
notifications lost in a black hole. I noticed that when we rebooted the
server for other issues, the notification messages suddenly showed up. We
were planning to implement a regular reboot of the server, but after reading
your post, instead we will use workaround 2.
Jamestechman
the glitch retry other times the culprit is the SPAM app.
James Chong (MVP)
MCITP | EMA; MCSE | M+, S+,
Security+, Project+, ITIL
msexchangetips.blogspot.com
On Jun 5, 3:37 pm, alaskann <alask...@discussions.microsoft.com>
wrote:
> Thank you for your workarounds. I have had the same problem with delay
> notifications lost in a black hole. I noticed that when we rebooted the
> server for other issues, the notification messages suddenly showed up. We
> were planning to implement a regular reboot of the server, but after reading
> your post, instead we will use workaround 2.
>
>
>
> "Yizhar Hurwitz" wrote:
> > HI.
>
> > I had the same problem that was mentioned here before:
> >http://groups.google.com/group/microsoft.public.exchange.admin/browse...
> > to help but I changed it anyway to values you can see below).- Hide quoted text -
>
> - Show quoted text -
Yizhar Hurwitz
Finally, Hopefully, beter late the never, etc...
MS acknoledge the problem, and now provides the bug fix.
Here it is:
E-mail senders do not receive an indication that some messages have been
held by Exchange Server 2003 until the SMTP service, the Microsoft Exchange
Information Store service, or the Exchange server is restarted
http://support.microsoft.com/kb/950757/en-us
Almost 3 years after the bug was introduced at October 2005, hmmmm.....
Please reply here and write if you installed the hotfix KB950757 and if it
solved the problem.
Xenophane
particularly to one host. But I tried the GlitchRetrySeconds workaround
before I installed the patch, so I dont know if I have to delete that key
after installing the patch..
(I restart SMTP every night, to catch mails stuck in the queue)
I will have to do some more research, I will get back.
Nielsen@discussions.microsoft.com Lars Nielsen
http://support.microsoft.com/kb/950757/en-us
"Yizhar Hurwitz" wrote:
> HI.
>
> I had the same problem that was mentioned here before:
> --
> Yizhar Hurwitz
> http://yizhar.mvps.org
>
>