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
---------------- 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.
>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
I would think using a SMTP gateway for all the outbound mail is the best solution.
> 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.
> >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
> I would think using a SMTP gateway for all the outbound mail is the > best solution.
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 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.
> > >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
> > I would think using a SMTP gateway for all the outbound mail is the > > best solution.
>> > 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.
>> > >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
>> > I would think using a SMTP gateway for all the outbound mail is the >> > best solution.
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.
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?
"Kazys" wrote: > 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.
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.
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
> 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.
> 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
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.
> 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.
> 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
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.
> 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.
> > 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.
> > 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
> 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.
"Zuza" wrote: > 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.
> 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:
"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 ?
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.
>> 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:
>> 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 ?
> 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.
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
> 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
> 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
"nicow...@gmail.com" wrote: > Nice. Can anyone confirm that this is a working fix? I implemented it > but I have to wait till something goes wrong (or not)..
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
> "nicow...@gmail.com" wrote: > > Nice. Can anyone confirm that this is a working fix? I implemented it > > but I have to wait till something goes wrong (or not)..
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
> 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
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.
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.
"bobseeksi...@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. > > Bernd
> 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.
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.
> 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
> ---------------- > 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 webb" wrote: > 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.
