Message stuck in Microsoft SMTP service Queue
Recently I ran into a problem where emails that were generated using CDOSys were getting stuck in the Microsoft SMTP service outgoing queue. If you are having problems with the Microsoft SMTP service, you may have discovered that it is difficult to troubleshoot. This difficulty is mostly caused by the fact that the service has very little logging available to it. It is true that you can enable logging via the IIS console, but that logging is minimal at best. Errors are not recorded very well in that log.
I did spot in the event viewer some interesting entries that were complaining about internal DNS errors that appeared to be coming from the SMTP service. Upon further research I found that IIS 5.0 running on Windows Server 2000 is not able to make DNS queries via UDP. IIS is only able to query DNS servers using TCP. This poses a problem since TCP is usually only used for zone transfers; therefore most DNS servers have TCP blocked and only allow UDP queries.
This will result in the SMTP service being unable to query DNS at all. In that state SMTP service will initially process mail that is put into the ‘pickup’ directory by CDOSys, and move it into the ‘queue’ directory. From this directory it is normally processed further and sent to the next MTA. However, when SMTP service is unable to query DNS it just leaves the message in the queue directory and begins ‘BadMail’ processing.
How can you test to see if this is the issue you are having? The first step I recommend is using nslookup to verify proper operation of DNS as per the needs of IIS 5.0. Simply run nslookup from the command line (this can be done on either Windows or Linux), and force it to do all queries using TCP. While in nslookup enter:
set vc
Now any queries you enter will be done using TCP. If this fails, try turning off forced TCP and run the query again. If this works you know that the IIS server cannot make TCP DNS queries to it’s designated DNS server. You can turn off forced TCP by using this command in nslookup:
set novc
Also there is a useful tool from Microsoft that runs various mail sending steps and can help you in debugging this and other issues with SMTP service. This tool is called SMTPDiag. Here is a good article that shows a little on how to use SMTPDiag.
If you have determined that your mail is getting stuck because of TCP DNS queries being rejected or dropped, there are essentially three options for you to fix this:
- If your firewall is preventing TCP DNS queries, modify the rules to allow it.
- If possible, change the configuration of the DNS server to allow TCP queries.
- Change the IIS server to use a DNS server that is configured to allow TCP queries.
Use the nslookup procedure shown above to determine both that the firewall rules are configured to allow TCP queries AND that the DNS server that you’d like to use is allowing TCP queries. Once are sure that you have set IIS to query a DNS server that allows TCP queries, simply restart the SMTP service and all mail in Queue should begin to process.
Remember: On Windows Server 2000, you must reboot the server after you changed the DNS servers for a interface in order for the change to take effect.
Just voted for the Fedora 10 codename.
Wow, that was exciting.
I just stopped by and voted for the Fedora 10 codename. There are plenty of really interesting choices to choose from. Remember, this is Range Voting; so you are able to vote for all nine possible names. This allows you to assign a value to each name.
Have you signed the Fedora CLA and are you a member of at least one other Fedora group within the Fedora Account System? Great! Then you are qualified to cast your vote too. This is a great way to play a quick and easy role in what Fedora will look like in the next release. A few minutes of your time will help have an impact on an untold number of people.
So join me and head over to the voting booth that can be found here: https://admin.fedoraproject.org/voting/about/10
And if you have not signed the CLA, or if you have and you still don’t belong to at least one other Fedora group in FAS…what are you waiting for? Get off the fence and pick a group to join and contribute a little where ever you can.
Help test recent xulrunner updates.
Recently there were problems with a new version of xulrunner being sent as an update to Fedora 9. Several packages that are built against xulrunner were not rebuilt to the new version and submitted to the repositories before xulrunner was. This issue would cause a dependency issue resolving error that might look like this:
Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * livna: mirrors.tummy.com * fedora: mirror.anl.gov * updates: mirror.anl.gov Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: gecko-libs = 1.9 for package: Miro --> Processing Dependency: gecko-libs = 1.9 for package: gnome-python2-gtkmozembed ---> Package pilot-link.i386 2:0.12.3-14.fc9 set to be updated ---> Package rsync.i386 0:3.0.3-0.fc9 set to be updated ---> Package totem-mozplugin.i386 0:2.23.2-5.fc9 set to be updated ---> Package xulrunner.i386 0:1.9.0.1-1.fc9 set to be updated ---> Package system-config-language.noarch 0:1.3.1-2.fc9 set to be updated ---> Package selinux-policy.noarch 0:3.3.1-78.fc9 set to be updated ---> Package nfs-utils-lib.i386 0:1.1.1-5.fc9 set to be updated ---> Package xen-libs.i386 0:3.2.0-14.fc9 set to be updated ---> Package binutils.i386 0:2.18.50.0.6-4.fc9 set to be updated ---> Package totem-gstreamer.i386 0:2.23.2-5.fc9 set to be updated ---> Package qemu-img.i386 0:0.9.1-6.fc9 set to be updated ---> Package selinux-policy-targeted.noarch 0:3.3.1-78.fc9 set to be updated ---> Package libvirt.i386 0:0.4.4-2.fc9 set to be updated ---> Package qemu.i386 0:0.9.1-6.fc9 set to be updated ---> Package cpio.i386 0:2.9-8.fc9 set to be updated ---> Package yelp.i386 0:2.22.1-4.fc9 set to be updated ---> Package nspluginwrapper.i386 0:1.1.0-3.fc9 set to be updated ---> Package libvirt-python.i386 0:0.4.4-2.fc9 set to be updated ---> Package device-mapper-multipath.i386 0:0.4.7-16.fc9 set to be updated ---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated ---> Package dmraid.i386 0:1.0.0.rc14-8.fc9 set to be updated ---> Package totem.i386 0:2.23.2-5.fc9 set to be updated ---> Package kpartx.i386 0:0.4.7-16.fc9 set to be updated --> Finished Dependency Resolution gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 from installed has depsolving problems --> Missing Dependency: gecko-libs = 1.9 is needed by package gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 (installed) Miro-1.2.4-1.fc9.i386 from installed has depsolving problems --> Missing Dependency: gecko-libs = 1.9 is needed by package Miro-1.2.4-1.fc9.i386 (installed) Error: Missing Dependency: gecko-libs = 1.9 is needed by package gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 (installed) Error: Missing Dependency: gecko-libs = 1.9 is needed by package Miro-1.2.4-1.fc9.i386 (installed)
There is an update in Bodhi to correct this dependency issue. However, this update needs people to download, install, and test it. Then report on Bodhi what the results were. Usually either that it worked great or that there was issues.
Here are the steps to do the test and report to Bodhi the results:
- Run
yum update
- From the output determine what packages are missing for you, you are looking for dependencies that could not be resolved. For this issue they should all be related to Miro and gnome-python2
- In a web browser go to the Bodhi page for this update: https://admin.fedoraproject.org/updates/F9/pending/Miro-1.2.4-2.fc9,gnome-python2-extras-2.19.1-17.fc9
- Towards the top of the page you will see a section called Builds:. Open a new browser tab/window for each build listed. This will take you to the test build for each package in Koji.
- On the Koji page, look for the section called RPMs. Look for each package of the right architecture that you need.
- Create a temporary directory to download each of these files to. In my case I created a directory called testingUpdates:
[jfenner@localhost Download]$ mkdir testingUpdates [jfenner@localhost Download]$ cd testingUpdates/
- Download all of the RPMs that you need from Koji into the temporary directory. I used wget to do this because I think it’s the easiest way. However, use whatever method works best for you.
- Once you’ve done that, then localinstall all of the packages in the temporary directory.
[jfenner@localhost testingUpdates]$ sudo yum --nogpgcheck localinstall *
- Note: You have to turn off the gpg signing check above, because at this stage the packages have not been signed yet. This will happen once they’ve been pushed to stable.
- Assuming that you were able to install all packages with no errors, now run a normal yum update. This should also run with no more dependency errors.
[jfenner@localhost testingUpdates]$ yum update
- Excellent! Now do a test run of Firefox and Miro, if you have them installed and make sure that they appear to be working right.
- Now you have concluded testing this pending update. The last step is to submit your findings to Bodhi to help get this update sent to the world. Go back to this update’s page on Bodhi. At the bottom of the page, enter your name and click on the appropriate radio button for your findings. If everything worked fine click on Works for Me. Enter a brief comment if you’d like. Fill out the captcha and click Add comment.
That’s all there is to it. You just helped improve QA for the Fedora community. The test you conducted and feedback you provided will help this update go out to all the Fedora repositories fast and of higher quality. I encourage you to check back often at Bodhi and test other packages that appy to your system and provide your feedback. The more of the community that does this, the higher the quality of the updates we receive will be.
Go vote in the FESCo election!
I just went and voted in the Fedora Engineering Steering Committee election. This is the first FESCo election where the number of seats have been changed from 13 to 9. This decrease is meant to create greater competition for seats on this committee.
Numbers have been reported as being low in past Fedora elections. That is why I encourage to take a few minutes out of your day and read over the nominations. Jot down the names of people who interest you with a score next to each. Remember, that Fedora uses range voting; this means that you will vote for each candidate using a numerical score. In the end all scores are summed up and the candidates with the highest scores are the winners. This is really cool, because it means that you can vote for all the candidates if you want to.
Once you have written down the names with the scores, simply head over to the voting booth and place your votes. It’s both fun and educational to do. Not to mention, voting on FESCo is a quick and simple way for you to get involved with the future of Fedora in a very real way.
So join me, and cast your vote today!
