VirtuProbe Studio
VirtuProbe Studio
The thing that makes VirtuProbe powerful is that it lets you drive the protocol conversation yourself: send the exact EHLO, the malformed MAIL FROM, the command a library would never emit. That is also, for most people testing an integration, precisely the thing they don't want to do. Action Mode is the answer to a tension we'd been living with: state the outcome you want, let the tool drive the conversation, and keep the raw commands one click away.
Picture the most common test in the world for a mail integration: did signing up send the welcome email? In VirtuProbe as it stood, answering that meant opening an SMTP probe and assembling a command sequence by hand: EHLO, then STARTTLS, then EHLO again, then AUTH, then MAIL FROM, RCPT TO, DATA, the body, QUIT, each step configured individually. If you know SMTP, that's a precise, powerful instrument. If you're a backend developer who just wants to know whether your provider is wired up right, you've been handed a protocol exam for a yes/no question.
That command-by-command editor is the right tool for what it was built for: fuzzing an SMTP server, sending a deliberately broken sequence, controlling exactly what hits the socket. Those uses are the reason the probe exists and the reason the stack is hand-written. But they're the exception, and we'd made the exception the default. Every user, for every routine "does this work" check, was paying the protocol tax up front.
You can see the same shape across the stateful probes. To check whether a message arrived you'd drive an IMAP session: LOGIN, SELECT, SEARCH, FETCH. To verify a directory login you'd hand-build an LDAP BIND. In each case the question is an outcome, did the mail land, does this password work, and we were making people express it as a transcript.
Action Mode flips the default. The SMTP, IMAP and LDAP probes now open on a form that asks for the outcome, and VirtuProbe compiles that into the protocol conversation for you, in the module, at send time:
EHLO → STARTTLS → AUTH → MAIL FROM → RCPT TO → DATA → QUIT handshake runs underneath; you never type a verb.Authentication comes from the shared credential store, so the password never sits on the probe, and every field takes {{variables}}. An action is a first-class chain step and a first-class scripting target rather than a lesser mode. New probes open in Action; the old command-list probes keep working exactly as they did.
The point that mattered most in the design: Action Mode adds a floor, it doesn't lower a ceiling. Above every action form is an Action / Advanced toggle, and Advanced is the same raw command editor it always was. The moment you need to send the malformed sequence, you're one click from it.
There's a bridge between the two, too. An Edit as commands button takes the outcome form and reconstructs the underlying command sequence into Advanced mode, which turns out to be the best way to learn the protocol: fill in the friendly form, then look at exactly what it was going to send. The on-ramp to fuzzing and the teaching tool are the same button.
It would be easy to assume Action Mode is a cosmetic layer, a form that expands into a fixed snippet of commands. For SMTP and LDAP that's nearly true. For IMAP it isn't, and that's the part worth the detail.
Consider "fetch the latest message matching this search." You cannot write that as a static command list, because the command you need to send depends on an answer you don't have yet. SEARCH returns a set of message ids at runtime; the FETCH has to target the one the search just found. A canned sequence can't reference a value that won't exist until the sequence is halfway run.
So the IMAP action isn't a macro. It's a small imperative task executor living in the module: log in, select the mailbox, run the search, look at what came back, decide which message to fetch, fetch it, shape the answer to what the form asked for (exists / count / latest body / latest header). That runtime decision, SEARCH feeding FETCH, is exactly what a flat command list can't express, and it's the reason this is a genuine Action Mode and not a snippet library.
Because the IMAP action exposes what it found through two extractors, IMAP_MATCH_COUNT and IMAP_MESSAGE, the humble "did the mail arrive" form becomes the backbone of the test everyone actually wants to write:
Sign up over HTTP, find the mail over IMAP without knowing a single IMAP verb, pull the six-digit code out with a regex, and drive the confirmation, a real cross-protocol flow expressed the way you'd describe it to a colleague. The outcome form did the protocol work so the chain could be about the flow.
Action Mode widens who can pick up the tool without narrowing what the tool can do. The backend developer checking an integration gets a form and an answer. The security tester who wants to feed a mail server a broken DATA terminator flips one toggle and has the raw conversation back. The same probe serves both, and neither is asked to become the other. Powerful for the people who need the power; quiet for everyone else, with EHLO available exactly when, and only when, you want it.
The HTTP probe is free forever, the whole thing. No account, no cloud, no expiry, on macOS, Linux and Windows. The stateful integration probes covered here, SMTP, IMAP and LDAP with Action Mode, are part of the Engineering tier, alongside the credential store, scripting and the MITM proxy.