Lost psa-request results

Note: Due to a disk crash (and possibly other causes), the Web submission script failed through most of July, rendering the server inacessible except via email. Service resumed on 4 August 2005. We apologize for the inconvenience.

Note: Due to a server upgrade late on 28 April 2005, the server was unavailable for nearly 48 hours. Mail requests submitted during the interval were queued and eventually processed, but the server Web submission form incorrectly rejected requests from valid addresses. Service is now back to normal, and we apologize for the inconvenience.

Note: Since at least late April 2004, two-thirds of all requests submitted for sina.com addresses have been undeliverable due to repeated "Connection died" problems. This could be due to server overloading on their end, or possibly just configuration problems (though that wouldn't explain why they were intermittent). Regardless of the real cause, please choose another e-mail address; the server will think that "sina.com" is a commercial address, and will limit your access to the server as a result.

Note: Since early December 2004, the psa-request server has been getting bounce messages from a server-based spam-rejection system that quickly decides that the first few emails from psa-request are spam, and blocks all subsequent messages from that address. These are the ones in the list below with the "psa@darwin.bu.edu is disable" [sic] message; presumably, the related requests with different bounce messages are the ones that caused the spam filter to decide that psa@darwin.bu.edu is a spammer in the first place. Ironically, the system in question appears to be one from Barracuda Networks that uses a Bayesian filter and claims to "adapt automatically to changes in spam." Unfortunately, like all Bayesian methods, this is guaranteed to fail at least some of the time. We believe that probilistic e-mail filters are intrinsically broken, and recommend that this site use an approach such as whitelist-based filtering (e.g. TMDA); failing that, we would advise our psa-request user to find an ISP that doesn't lose their messages.

The psa-request server is sometimes unable to return results to the user. This is usually due to an error in entering the e-mail address; the Web interface to the server has limited ability to check that the e-mail address it is given actually works, short of using it. These cases are noted below with "User unknown" in the "Reported problem" field.

Sometimes, even though the address is valid, the remote mail system is temporarily unable to accept messages, and delivery fails. This can happen for any number of reasons, including user storage quota exceeded, server resources exhausted, and various configuration errors on the remote server. For an example of the latter, if mail.random.edu has been told to forward mail for "joe.user@mail.random.edu" to bio.random.edu, but bio.random.edu has been told to forward it to mail.random.edu, then joe.user isn't going to be able to get mail from anybody until one system or the other is configured to accept them. These remote mail system problems are reported with whatever explanation the remote mail server gave for being unable to deliver the message, enclosed in double quotes ('"'), with any additional information enclosed in parentheses.

Another all-too-common problem is that the mail system may be unable to reach the remote host, or the remote host may be overloaded and unable to handle the connection. These problems are reported as "Connection timed out," "Connection died," "Connection refused", or "Unable to establish an SMTP connection" (i.e. they all have "connection" in the "Reported problem"). If a connection cannot be established, our mail system will keep trying for up to a week before it finally gives up. Because of this, such errors won't be posted here until at least a week after the submission. If that happens, it could mean that your ISP or mail service is blocking all connection attempts from our mail server in a misguided attempt to limit spam. If so, you will need to find another email address to use for making psa-request submissions.

Shown below are all failed requests since 1 December 2005:

The request ID is the number quoted on the PSA Submission page in response to submitting an interactive request, and referenced by all subsequent correspondence. When a sequence is submitted, either by mail or by Web interface, the mail server will send an acknowledgement within a few minutes. If you do not receive such a message (allowing for possible delay in mail delivery), that means that either the server is down, or was unable to get the results back to you. In either case, you should check this page.

This page was last updated at Sat Jun 10 10:36:35 2006; the database of lost requests was updated at 2006-06-10 10:36 . Ideally, it would be updated at the end of each working day, but recently the updates have been more sporadic. Eventually, if your results have still not appeared, the request ID should show up on this list. If, after a reasonable period of time, it does not, or if you find that the posted reason does not help you to correct the problem, please send e-mail to Bob Rogers, referencing the request ID.

Go to:

• Submit a sequence analysis request.
• List of topics about the PSA server.
• The BMERC Home Page.

Please direct your questions and comments about these Web pages and the PSA e-mail server to: