Hi Justin,
A new "abort" feature was just released for email programs sending in recipient timezone. See Abort Delivery of Email Programs Scheduled with Recipient Time Zone - Marketo Docs - Product Documen...
But for a "send email" flow step under delivery, I am afraid that is still not possible. Deleting the smart campaign might have some effect, but I do not want to send an erroneous email to 200k people just for the sake of testing it 
-Greg
I hear Sanford Whiteman saying, "whatever the wait duration", it will never cover 100% of the cases
Another situation where I put a wait step is on operational email that are fired to either confirm or dismiss registration to an event. Imagine you wanted to dismiss the person and you wrongly sent the "confirm" email... Oops.
-Greg
There are a few reasons why this isn't very feasible. Let's start with stating the obvious, that an email is really just a text file shipped from one ESP to another, routed to your user account and stored there. The emails are received regardless of who they're from - there's no middle-ware gatekeeping the email from shipping from one box to another.
Once it arrives, the ESP chooses what to do with it: deliver, block, or move to a folder (ex: Spam). There's some validation done to see if it's really from that sender (DKIM, DCAR) but in reality most emails are received unless the IP sending it is blocked.
Now you have the email somewhere in your email program, be it an inbox, spam folder, etc. Most email programs then take the step of downloading it to your device so you have it for off-line reading.
This is one MAJOR barrier to recalling. You can recall, but I'm on a plane not connected to internet. I'm going to receive that message.
Another reason is that, as you know, anyone can say that an email is from anyone else. Any one of us here could quite easily send, for example, your mom an email from your email address and she'd be none the wiser. Because there's no REAL credential matching and because Marketo is often used to send emails from different email addresses, there's no way to know that the request to delete the email is real.
For such technology to work, you'd need a way to verify to my email service provider that you delivered the email and that you want to delete it. As stated earlier, an email is nothing more than a text file delivered from one IP address to another and in many cases a person can switch IP addresses at any point in a day so there's no way to certify that you're authorized to delete it.
Now, these two come down to a MAJOR security no-no, which is authorizing a system to remotely delete files from a device without authorization. If technology existed (and I'm not saying it doesn't...) that would allow me to access storage on your phone and choose to delete a file without your consent then what's to stop the Evil Russian Hackers 
from accessing other files and deleting or downloading them?
In reality, it's very much similar to postal mail. If you accidentally send me a blank check for $10,000 that you meant to send to someone else, you don't exactly have permission to break into my house and take it back, nor am I obligated by anything other than my morals and scruples to return it to you upon request.
Now, these two come down to a MAJOR security no-no, which is authorizing a system to remotely delete files from a device without authorization.
In the interest of completeness ... it's not always like remote deletion in the sense of "making an outbound connection to somebody's mailbox to fish out an email."
That kind of extreme (and of course impossible) action would be necessary when, as with Marketo, you send unsigned SMTP messages.
But if you send signed S/MIME SMTP messages, even over the public net, you can revoke the certificate associated with the message, which is remote invalidation. Soooo... not the same as remote deletion, but it would mark the message as bad and unreadable.
.png)