Dangers with emailed proposals
Earlier this year, I posted about how an emailed proposal was ruled late and therefore not eligible to be considered for evaluation.
Another offeror has had a similar problem. So I relate this sad cautionary tale with this advice: Be careful when submitting proposals by email.
The U.S. Air Force issued a request for task order proposals (RFTOP) to migrate computer services to the “cloud.” The RFTOP was issued under an indefinite-delivery, indefinite-quantity (IDIQ) contract for the National Geospatial-Intelligence Agency.
Attempts to submit proposal
The protester reported—and the Air Force didn’t dispute—that the protester emailed its proposal at 12:25 p.m. central time on July 17 to the correct email address. The protester received confirmation from Microsoft Outlook that delivery had been completed.
When the protester didn’t receive an email message from the Air Force, it contacted the Air Force at 12:32 p.m. At that time, the Air Force said the proposal was not in its email box.
At 12:59, the protester once again sent the proposal and received confirmation of receipt through Outlook.
At 1:01 p.m., the contracting officer instructed the protester not to send any more emails because the deadline for receipt had passed. Later on, the contracting officer informed the protester that its proposal would not be considered and a protest was filed.
At no point in this process did the protester receive a bounce notice indicating that the email messages didn’t go through.
Government’s explanation about why the proposal wasn’t received
The Air Force explained that when any email is sent to an address at the Department of Defense, the enterprise email security gateway (EEMSG) scans the message for malicious content. When the message reached the EEMSG, Outlook gets a confirmation of receipt. If the EEMSG clears the message, it then next goes to the Air Force’s server, where additional scans are performed. The Air Force confirmed that the proposal did indeed reach the EEMSG, but the Air Force’s server rejected the message. The EEMSG doesn’t send bounce messages.
Another fact important to understanding this decision
In case you’re wondering about whether the Air Force’s email box was operating properly, the Air Force successfully received six proposals at the designated email box.
The offeror is responsible for delivering its proposal to the proper place at the proper time. Furthermore, the offeror has the burden of showing that it delivered the proposal to the proper place at the proper time. Because the protester failed to show that the proposal was delivered to the proper place at the proper time, the Air Force didn’t have to consider its proposal.
Although no evidence was presented during this protest about why the proposal didn’t get past the Air Force’s server, the most likely explanation was the presence of a virus or some other type of security flaw.
Therefore, to prevent this type of problem from occurring, we suggest government contractors—
- Plan on submitting their email proposals at least 1 day ahead of time.
- When they don’t get a confirmation, have their information technology experts scan the proposal file to see whether any viruses or other securities are involved.
- With an extra 24 hours to react to the situation, they will probably be able to coordinate with the requesting agency to resolve the problem.
As the online entrepreneur John Rampton once observed, “Procrastination doesn’t work for everything. For instance, waiting to buy plane tickets at the last minute will typically end up costing you more.”
For more information, see Man-Tech Advanced Systems International, Inc., Government Accountability Office decision B-414985 (October 20, 2017).
Items on this web page are general in nature. They cannot—and should not—replace consultation with a competent legal professional. Nothing on this web page should be considered rendering legal advice.