Government Contracts Monitor

When Relying on Technology, Trust but Verify

November 1, 2017

Usually, the failure to timely submit a proposal to a procuring agency results from poor planning, administrative error, or a lack of proper attention to detail on the part of the offeror. But sometimes the “failure” to meet the proposal submission deadline is largely beyond the offeror’s control. As the Government Accountability Office (GAO) decision in the recent case of ManTech Advanced Systems International, Inc., B-414985 (October 20, 2017) makes clear, even if you seem to do everything right, technical glitches on the agency’s side can ruin your day.

The protest involved a decision by the Department of the Air Force not to consider ManTech’s task order proposal responding to a request for proposals (RFP) for cloud migration assessment of National Geospatial-Intelligence Agency activities. The solicitation required offerors to submit task order proposals electronically via e-mail no later than 1:00 p.m. Central Time (2:00 Eastern) July 17^th and provided that the Air Force would acknowledge proposal receipt by return e-mail.

ManTech e-mailed its proposal to the address designated in the RFP at 1:25 p.m. Eastern on July 17^th and received confirmation of completed delivery through its Microsoft Outlook delivery receipt feature. Seven minutes later, at 1:32, having still not received an e-mail receipt confirmation from the agency, ManTech contacted the Air Force and was informed that the proposal was not in the designated mailbox within the agency’s system. At 1:37, ManTech then re-sent the proposal via e-mail directly to the Air Force employee it had spoken to, as well as the contract specialist. ManTech received another Outlook confirmation receipt at 1:40, but at 1:49 it was again informed by the agency that the proposal had not reached the designated mailbox. At 1:59, ManTech removed the cover letter and again re-sent the e-mail with the proposal. It received an Outlook confirmation receipt on minute later, at 2:00. At 2:01, the contracting officer instructed ManTech not to send further e-mails because the deadline for the receipt of proposals had passed. Subsequently, the contracting officer informed ManTech that the agency had not received its proposal in the designated mailbox and, therefore, ManTech was not considered for award.

ManTech timely protested, asserting that the Air Force should be required to consider its proposal because the proposal was timely sent to the agency’s designated e-mail box, and ManTech received confirmation from its Outlook delivery system that it had been received. In support of its argument, ManTech went beyond the mere timing of e-mails and Outlook confirmations. It reviewed the tracking record for the first sent e-mail and found that its Cisco IronPort system opened a Simple Mail Transfer Protocol (SMTP) connection with the Air Force system at 1:28, and received the SMPT remote response at 1:31, three minutes later. ManTech explained that the recipient’s server had the ability during those three minutes to deliver or reject the transmittal and reasoned that, since it received no bounce back indicating that the e-mail containing the proposal had been rejected, it must have been accepted by the agency’s e-mail exchange server. According to ManTech, the Air Force should be required to consider its proposal because the e-mail made it beyond the initial point of entry to the government’s IT infrastructure.

In response, the Air Force noted that ManTech’s proposal was never received in the designated mailbox. The agency explained that when an e-mail is sent to any recipient within the Department of Defense, it is first scanned by the enterprise e-mail security gateway (EEMSG) for malicious content and then delivered to the recipient’s e-mail exchange server if no malicious content is found. The recipient’s e-mail exchange server then performs additional scans based on the specific policies of the recipient organization. Based on this further assessment, the recipient’s server can block, quarantine, drop, or deliver the e-mail to the recipient’s e-mail box. According to the Air Force, the e-mails sent by ManTech were received by the EEMSG system, which scanned them and attempted to deliver them to the specified Air Force e-mail address, but they were rejected by the recipient’s e-mail server based on their content. ManTech did not receive a bounce back because the EEMSG inbound system cannot initiate a connection to the internet. The Air Force also reported that six other offerors successfully submitted proposals to the mailbox as required and that the e-mails sent to the agency personnel at 1:37 never reached them either.

As is often the case, the GAO took a strict approach to proposal submission deadlines, first noting that an offeror is responsible delivering its proposal to the proper place at the proper time. The GAO then pointed out that where, as here, timeliness becomes an issue, the protester has the burden of showing that it timely delivered its proposal to the agency at the specified address. The GAO reiterated that an agency is not required to consider a proposal where there is no evidence that the proposal was “actually received.” In this case, while ManTech demonstrated that it timely sent its proposal to the agency, and that it reached the EEMSG server, it failed to establish that its proposal was actually delivered to the agency’s designated e-mail prior to the time set for the receipt of proposals. Thus, ManTech failed to meet its burden and the agency could not consider the proposal. The GAO denied the protest.

Given that the communications problem here involved technical details essentially beyond ManTech’s control (i.e. whether the agency’s e-mail server accepted a message from another internal agency server), what can be done differently to avoid such an outcome? Yes, hindsight is 20/20, but we can learn from it and several options come to mind. First, if you can complete your proposal and attempt to submit it sooner, you will have more time to troubleshoot the problem and, potentially, find a solution. Given the practical realities of proposal preparation, however, it would be unwise to rely on having enough time to diagnose and fix communications problems that may arise. A better approach would be to test the communications system well before the proposal due date. Such tests are not foolproof (here, the e-mail was rejected due to its content, something that might be difficult to test), but they are better than adopting hope as a strategy. Lastly, you can simply ask the procuring agency to describe any e-mail characteristics that would lead to the rejection of a message. Adopting a combination of these three strategies will help you avoid ManTech’s fate.

Attorneys

Lindsay Simmons