A very large reply no longer stalls your inbox sync

A single oversized incoming email used to stop your mailbox sync, holding up every reply queued behind it. Large messages are now handled without blocking anything.

What changed

FirstSales reads your connected mailbox to detect replies. That is how a prospect answering your email becomes a reply in the product, how a campaign knows to stop sending follow ups to someone who has already answered, and how bounces get recorded.

The sync reads messages in order. When it hit a message too large to process, it stopped rather than skipping. It then retried the same message on the next cycle, hit the same limit, and stopped again. Every message behind it stayed unread for as long as the oversized one sat at the front of the queue.

In practice this meant one prospect sending a large attachment could freeze reply detection for an entire mailbox. Genuine replies from other prospects were sitting in the mailbox, unread by the product, while campaigns continued sending follow ups to people who had already answered.

The sync now handles oversized messages instead of stopping on them. It records that the message exists, notes that its full contents could not be read, and continues to the next one. The queue keeps moving.

How to use it

There is nothing to configure. The fix applies to every connected mailbox.

If you had a mailbox that seemed to go quiet on replies for a stretch, and the replies then arrived in a burst later, this was probably the cause. Those replies were never lost. They were waiting behind a message the sync could not get past.

It is worth checking any campaign that ran during a period like that. A follow up may have gone to someone who had already replied, because the reply had not been read yet at the time the follow up was scheduled. Reply detection was correct in principle, and simply had not seen the message.

Why it matters

Reply detection sits underneath a lot of behaviour that only works if it is reliable. Follow ups stop when someone answers. A reply moves a lead out of the sending sequence. Bounces feed into deliverability monitoring. All of that depends on the product having actually read the mailbox.

A sync that stops is worse than a sync that is slow, because it fails silently and gets further behind the longer it stays stopped. Nothing errors in a way you would notice. Replies simply stop appearing, and the natural reading of that is that nobody replied.

The specific damage is sending a follow up to a prospect who already answered. That is the single most visible way an outreach tool can look careless to the person on the other end. They answered your question, and then got a message asking whether they had seen your earlier email. It undoes the work the reply represented.

What happens to the oversized message now

The message is recorded as received. Its headers, sender, subject, and timestamp are read normally, which is enough to detect that the person replied and to stop follow ups going to them. What is not read is the full body, if the body is beyond the size the sync can process.

That means the reply still counts as a reply. The sequence stops. The lead moves out of the sending flow. You will see the message in the thread with a note that its full contents were too large to load, and you can read it in your own mail client where no such limit applies.

This is the right trade. The important thing about a reply is that it happened, and that information is now never lost to a size limit.

How common was this

Uncommon per mailbox and disproportionate in effect. Most prospects do not send large attachments in a reply to a cold email. When it happened, it took out reply detection for that entire mailbox until the message aged out of the sync window, which could be days.

That shape, rare but total, is the reason it took a while to identify. A mailbox affected by it looked like a mailbox where nobody was replying, which is not an unusual thing to see in outreach and not something that prompts a bug report.

How to tell if a mailbox is behind

Compare what you see in your own mail client against what the product shows. Open the connected mailbox directly, look at the most recent message that arrived, and check whether it appears in FirstSales.

A gap of a few minutes is normal, since the sync runs on a cycle rather than continuously. A gap of hours, with messages visible in the mailbox and absent from the product, means the sync is not keeping up, and that is worth reporting.

The connectors screen also shows the last successful sync time for each mailbox. A timestamp that stops advancing is the clearest single signal that something is stuck, and it is worth glancing at whenever a campaign's reply rate looks lower than you expected.

What else changed alongside this

The same work made the sync more careful about how it handles a message it cannot fully process for any reason, not only size. A malformed message, an unusual encoding, or a message with a damaged structure used to have the same effect of stopping the queue.

All of those now behave the same way: record what can be read, note what could not, and continue. The general principle is that one bad message should never be able to block the messages behind it, and that now holds regardless of what is wrong with it.