Solo ads sellers / Blog / Pipelining

Solo ads blog

A faster pipe is not permission

Answer A faster pipe is not permission. RFC 2920 defines SMTP command pipelining. When a server says it supports the extension, a client may send a batch of commands without waiting for a reply after each one, and then read the replies in order. The point is to waste less time on round trips. The reader never sees the batch. The reader did not agree to anything because the session was efficient.

Cream stationery and a teal accent on a dark navy desk
A quicker hand does not change what the card says.

The note that started this: RFC 2920, SMTP Service Extension for Command Pipelining, RFC 2920.

You will hear speed sold as seriousness. We can move a million before lunch. Maybe they can. The million is still a million addresses, each of which needed a reason to be on the file. If you buy solo ads for affiliate marketing, the affiliate still has to convert a person. A pipe does not convert. It carries.

The extension is negotiated. A server that does not advertise it is talked to the slow way, one reply at a time. Both ways can deliver mail people want, and both ways can deliver mail people do not want. Throughput is a property of the conversation between two servers. Permission is a property of the relationship between a sender and a person. Keep the properties on the correct nouns.

What is SMTP command pipelining?

RFC 2920 lets a client send several SMTP commands without waiting for each reply, when the server supports it. The point is throughput on the session. It does not grant permission to mail anyone.

Without pipelining, the client speaks, waits, speaks, waits. With it, the client can speak a short run of commands and collect the answers after. The answers are still individual. One recipient can be accepted while the next is refused. The batch is a packing method, not a group verdict. A seller who says the server accepted the batch is compressing a log you should want to see row by row when something looks wrong.

Nothing in this note is a guide to pushing more mail through a reluctant server. If a server is slow because it does not want the mail, the remedy is to stop and find out why, not to tune the conversation until the reluctance is harder to notice. A buyer who is offered a speed trick in place of a list explanation should walk.

Does a faster send mean the messages were delivered?

No. Pipelining changes how commands are batched on a connection. Each recipient is still accepted, deferred, or refused on the merits of that transaction. Speed is not a delivery receipt.

Accepted by the next server means that server took responsibility to try. It does not mean the person read the creative. Deferred means try later. Refused means this transaction did not go through, for a reason that should be in the reply. A fast session can produce all three outcomes in one batch. The clock on the wall is unrelated to which outcome you got.

Ask for the outcome counts on your solo after it runs. How many accepted, how many deferred, how many refused, and a sample of the refusal text. Those counts are the send. The time it took is a footnote. A footnote that tries to become the headline is hiding the counts.

Should a solo ad buyer shop for pipelining?

No. Shop for the list, the domain, the creative, and the refund line. Pipelining is an operator detail. A seller who leads with it is selling a pipe instead of a person.

Operators should know whether their software pipelines. That knowledge belongs in their runbook. It does not belong in the first paragraph of a quote to a buyer. When it shows up there, ask what problem of yours it solves. If the answer is that you get your clicks sooner by minutes, ask whether those clicks are from people who asked for the mail. Minutes do not repair a list. They only spend it faster.

RFC 2920 made a chatty protocol less chatty. Be glad the operators have it when they need it. Then ignore it on the invoice. Permission is the slow fact. It does not get faster because the pipe did.