Email from RunMyB

RunMyB, Inc. sends email from two domains it owns and operates, and from nowhere else. It is all account and transactional mail: the platform's own, and the mail that applications hosted on the platform have it send to their own users. RunMyB is not an email service provider: no customer, tenant, or third party can choose a sending domain, import a recipient list, or send through our domains in any way other than by asking the platform for one of the messages described below, which the platform renders and sends itself. The one other sender on our domains is the identity provider that signs people in to the RunMyB console, which sends its own sign-in messages from account@mail.runmyb.com (below).

The two streams

Those two sending domains are fixed in the platform's code, not configured per customer. A hosted application never gets a sending domain of its own; its name appears only in the friendly display part of the From line, always followed by (via RunMyB), so a recipient can always see who actually sent the message.

Notices about an account

The administrators of an account are emailed, at the address each of them signs in with, when a card in the console waits for their decision, when one of the account's products is published, its go-live request is declined, its own messages to its users are switched off (below), its background jobs are paused by RunMyB, a file it stores is withheld because the platform's scan found malicious software in it, files it stores cannot be scanned, or someone writes to it through its contact form or by email to its own address (below), when one of its runs finishes, fails or is stopped at a limit, when the account's credits run low or run out, and when the account nears or reaches its daily credit limit. Cards that arrive close together are gathered into one message. The notice that someone wrote to a product that only one member of the account can see in the console goes to that member alone, whether or not they are an administrator, and they can choose for it as an administrator can (below).

Each administrator can choose, in the console under Account → Notifications, whether each kind of these notices — cards waiting, products going live (the notices that an application's own messages were switched off, that its background jobs were paused by RunMyB, or that files it stores cannot be scanned, among them), runs that did not finish, finished runs, spending and credits, and messages to products — reaches them at once, in a daily summary, or not at all. Until they choose, finished runs come in the daily summary and the rest at once. Each of these notices ends with a link to that page, and its List-Unsubscribe header points there too. The notice that a file was withheld has no such setting and comes at once, unless the law requires, or a public authority asks, RunMyB to delay it.

The administrators of every account also receive RunMyB's own notices about the service itself — for example a change of the providers that process data for it, which the Data Processing Addendum promises to announce this way. These are never marketing.

Every notice is plain text and says what happened; a notice about an account links to the console, where anything it concerns is decided. Replying to a notice decides nothing. A notice about an account carries a reply address of the platform's own: a reply to it from the address the notice went to, by a member of the account, is kept, as text, as a message to that member in their Messages in the console, where nothing acts on it and no assistant is shown it; any other reply to it is deleted, and nothing of it is kept. The notice that someone wrote to a product, a daily summary that includes one, and RunMyB's notices about the service itself carry no reply address. The wording is the platform's own: a notice names what it is about as the console names it — a card's title, for example — and that text goes only to that account's own administrators, or, for a notice about a product that only one member of the account can see, to that member. A notice that someone wrote to a product names the product and carries nothing of what was written, nor the name or address the writer gave. When a decision waits for RunMyB's own administrators, they are told the same way, and that notice names the account by its identifier and the product by its short name, and carries no other text written in the account. No notice carries the material attached to a card. RunMyB's own notices about the service itself have no such setting: they are part of the service for as long as the account exists; to stop them, close the account (below).

What an application can and cannot put in a message

The platform renders every message itself. An application can ask it for two kinds of sign-in message, both worded by the platform: an address verification for a new account and a password reset. For each, it supplies only the address to send it to and a link into itself, which the platform validates before it is used. In the message, that link is wrapped in the platform's own link, on the application's address on runmyb.app, which, when opened while it is valid, records that the address is confirmed for that application (below) and then opens the application's link.

An application can also have the platform send its users messages of its own, written by its owner as templates the application carries: a subject and a plain text with named blanks, each blank declared as a piece of text, a number or a link, and, if the owner wishes, a formatted version of its message (below). Before each version of the application is published, the platform checks the form of its templates — their parts, their length, that every blank is declared and used — and never their wording. To send one, the application names the template, one address and a value for each blank. A web address written with ://, starting with www., or written as a domain name followed by a path (such as example.com/page), may appear neither in a template nor in a piece of text the application fills in: every link is a blank declared as a link, and its value must lead to the application's own address on runmyb.app. The platform renders the message as plain text — and, where the template carries one, as its formatted version too — and adds its own last lines to each, which no template can remove or change: that the message was sent to an address confirmed for the application, that RunMyB sends it on the application's behalf, with a link to this page, and an unsubscribe link. The platform does not judge what a template says, and a template made almost entirely of blanks lets the application choose nearly all of a message's words; what it cannot do is make one of its links lead to another site, attach a file, or send one message to more than one address. These messages may only be transactional — about the recipient's own dealings with the application, or asked for by the recipient — and never marketing: the Terms of Service bind the application's owner to that, and the owner answers for what the messages say.

A formatted version. A template may also carry a formatted (HTML) version of its message. The platform does not send that version as its owner wrote it, but as it rebuilds it from a fixed set of formatting of its own — such as paragraphs, headings, lists, tables, bold and italic text, and the colour, size and alignment of text — leaving out what a full web page carries around its content, such as its head. Before the application is published, it refuses a template whose formatted version uses any other formatting; before each message is sent, it rebuilds the version again, the same way, with the values the application fills in. A formatted version can hold no image and nothing that a mail program would load from elsewhere when the message is opened, and the platform does not record whether a message is opened. Its words follow the rules above for a template's text, and every link the application puts in it is a blank declared as a link, under the same rule. The platform's own last lines end it, with the same links as in the plain text. Every message carries its plain-text version, whether or not it also carries a formatted one. When the formatted version, as filled in, would show no text of the application's own, or is longer than the platform sends, the message goes as plain text alone; a message whose formatted version is longer still is not sent.

An application cannot send email through the platform in any other way, cannot attach files, and cannot import a recipient list.

The platform does not know who has signed up to an application, so it limits how many sign-in messages it will send to one address each day, from one application and from all applications together, and each application also has its own daily limit on them. An application's own messages have daily limits of their own, for each application and for each address from each application; and the applications of one account have one daily allowance for their own messages and another for their sign-in mail, so that their own messages do not draw on the account's allowance for its sign-in mail. The platform keeps these counts in its database, so a restart does not reset them.

An address verification is sent whether or not the address is confirmed, but the platform sends a password reset only to an address confirmed for that application (except from a preview — below): one at which one of the platform's links, in a message from that application, was opened while it was valid, or one to which that application's address verification or password reset, sent before those messages carried the platform's link, was delivered. When an application asks for a reset for an address that is not confirmed, the platform does not send the reset. It sends that address one message of its own instead, asking for the address to be confirmed by opening the platform's link in it; once that link is opened, the application's next request for a reset for that address is sent. That message counts within the same limits as the reset would have. None of these messages goes to an address that has unsubscribed from the application (below).

The platform sends an application's own message only to an address confirmed for that application, in the same sense. When an application asks for one for an address that is not confirmed, the platform does not send the message and does not keep it. It sends that address one message of its own instead, saying that the application would like to send it messages and asking for the address to be confirmed by opening the platform's link in it; if that address was already sent a request to confirm it for that application in the past week, nothing is sent. Once the link is opened, the application's later messages to that address are sent. That request counts within the application's daily limit for its own messages and, like an address verification, within the daily limits per address. None of these messages goes to an address that has unsubscribed from the application.

Mail from a preview. On a preview of an application — a copy of it at a web address of its own, which a member of its account starts from the console — the platform sends the application's mail only to the person who started that preview: a message the application asks for — a sign-in message or one of its own — is delivered only when it is addressed to the address that person signs in to RunMyB with, without first asking that address to confirm itself, and every other message stays on the preview, unsent, with nothing sent in its place; the preview's own mail page lists it, where the application has that page. A message delivered this way says in its last lines that it comes from a preview; the application's links in it lead to the preview, without the platform's own link around them; it carries no unsubscribe, but the platform sends none of these messages to an address that has unsubscribed from the application; and it counts within the preview's own limit and within its account's daily allowance for mail from previews and, for a sign-in message, within the daily limit on sign-in messages to one address from all applications together, never within the application's own daily limits. Mail from a preview stops when the preview is closed or expires.

Messages to an application

A person can write to an application hosted on the platform through the application's contact form, or by email to the application's own address (below). For a message written in the form, the application's own server hands the platform the message, the address the person gave for a reply and, if they gave one, their name, and the platform keeps them for the application's owner, who reads them in the application's inbox in the RunMyB console. An application the platform hosts with a server of its own may do this; one whose form does not hand its messages to the platform receives none this way. A message is not sent on as email, and the platform sends nothing to the address the person gave: any answer comes from the application's owner, from their own email. The account's administrators — or, for an application that only one member of the account can see in the console, that member — are told by a notice that a message arrived (above), which names the application and carries nothing of the message.

The inbox shows each message as plain text, with any link shown as text, to the members of the application's account who can see the application, with the name and the reply address as the person gave them. The platform takes a message written in the form from the application's server, not from the person, and does not check who wrote it or what it says: not for viruses, not for spam, and not whether the name and address are that person's own. No AI model, and none of the platform's assistants, reads a message, and the platform acts on nothing a message says. The platform takes messages from an application's form only within daily limits, for the application and for each reply address, and takes none while the application's inbox is switched off in the console or its account is suspended or terminated; it keeps nothing of a message it refuses, and the application is told why. A message written on a preview of an application stays on that preview and is not taken. The platform deletes each message after 90 days, and sooner when the application's owner deletes it.

By email. An application the platform hosts with a server of its own may also have an email address of its own, made from its address on runmyb.app: an application at name.runmyb.app receives email at name@in.mail.runmyb.app. The RunMyB console shows the address to the people who run the application, and the application may show it on its own pages; email sent to it reaches the application's inbox whether or not the application shows it, and an address the application no longer has receives nothing. The platform's mail provider receives each message and scans it for viruses and spam. The platform delivers a message to the inbox only when that scan found neither, when the message is within the platform's size limit, and when its sender's address passes the email authentication of its own domain, or of a domain related to it — which shows that the message came through a mail service that domain allows, not who wrote it; the sender's name is not checked. It delivers none while the application's inbox is switched off or its account is suspended or terminated, and only within daily limits, for the application and for each sender's address.

The inbox shows an email's sender's address and name, its subject and its text as plain text, with any link written out as text; formatted email is turned into plain text, and a very long message is cut. Attached files are listed by name and size. The platform keeps only files of a few common kinds — PDF, PNG, JPEG, GIF, WebP and plain text — whose contents match the kind they state; it never opens or runs them, and the people who run the application download each one under a name the platform gives it from the kind it verified. Any other file is listed as not kept. A kept file is deleted with its message, is not part of the account's data export, and can be downloaded while it is kept. The platform sends nothing back: no reply, and no notice that a message was not delivered. A message it does not deliver is deleted, and the application's owner sees in the console how many were not delivered that day, and why. The platform deletes each email as it was received as soon as it has delivered it or counted it.

Marketing mail

We do not send marketing email. There are no campaigns, no newsletters, no purchased or rented lists, and no "we noticed you visited" mail. Writing to us does not put you on a list. If that ever changes, it will be a separate, opt-in choice with a working unsubscribe, and it will never ride the account-mail streams described above. An application hosted on the platform may not have it send marketing either: its own messages may only be transactional (above).

How sending is controlled

• One chokepoint. Every message the platform's own code sends — platform or application — leaves through a single code path. The only other messages sent from these domains are the console's sign-in messages, which our identity provider sends itself (above), through the same mail provider and from account@mail.runmyb.com; the platform keeps the mail provider's reports on them in the same record as its own, and the suppression below applies to them too.
• Suppression. Addresses that hard-bounce or report a message as spam are recorded and suppressed; the platform will not send to them again. The identity provider's console sign-in messages are suppressed for them too: such an address receives no invitation and no code from it until RunMyB lifts the suppression, which its owner can ask for. Other bounces, such as a full mailbox, are recorded too, and an address that keeps bouncing that way is paused on that stream for a few days for the platform's own messages, after which it can receive them again.
• Unsubscribe. Every message the platform sends on an application's behalf (except mail from a preview, which goes only to the person who started that preview from the console — above) carries an unsubscribe link, in the message and in its List-Unsubscribe header, with one-click unsubscribe for the mail programs that offer it. Opening the link shows a page and changes nothing by itself. Unsubscribing, on that page or from the mail program, stops every message the platform sends on that application's behalf to that address, sign-up messages and the platform's requests to confirm the address included, until it is undone on the same page.
• Per-tenant limits. Each account has its own sending ceiling, so no single account can generate volume on the platform's reputation; its applications' sign-in mail and their own messages each have a ceiling of their own (above).
• A per-account send block. Sending for any account can be switched off, and the block is enforced in the send path itself, before any message reaches the provider.
• A switch on each application's own messages. An application's own messages are switched off automatically when the platform receives enough spam reports about them, or about the platform's requests to confirm an address sent in their place, and RunMyB's administrators can switch them off too. Only RunMyB's administrators switch them back on. While they are off, the platform sends none of them and no request to confirm an address in their place; the application's sign-in mail is not affected.
• What an application's owner sees. The platform keeps its own record of the messages it sends or refuses to send, and of what became of each, identifying the address only by a hash made with a secret key, and deletes it after 13 months. In the RunMyB console, the members of an application's account who can see the application see that record for the application's messages — delivered, bounced, reported as spam, or not sent and why — without the addresses they went to, and can type one address to see what became of the application's messages to it, including whether the person reported one as spam. The platform does not keep an address typed there.
• Authentication. Both sending domains publish SPF and DKIM and are covered by a DMARC policy, so a receiving mail server can verify that a message claiming to be from us really is.

If you received something you did not expect

• A message from an application on runmyb.app that you never signed up for, or did not expect from it — unsubscribe with the link in it, which stops every message the platform sends on that application's behalf to your address, and forward it to abuse@runmyb.com. We will investigate it under our platform rules and can suspend the application.
• A message that looks like it is from RunMyB but you doubt it — forward it to security@runmyb.com. We never ask for a password, and we never ask you to send credentials by email.
• Anything about your personal data, including asking us to delete it — privacy@runmyb.com, and see the Privacy Policy.
• To stop account mail entirely — close the account. Write to support@runmyb.com. Notices about an account's work can be turned off in the console, under Account → Notifications; RunMyB's notices about the service itself, the notice that a file one of the account's products stores was withheld, invitations, and the notices about data requests and account deletion have no such setting while the account exists, and closing it ends them.

Reports to abuse@runmyb.com are handled the way the report-a-problem page describes: we confirm receipt, review notices in a timely, diligent, and non-arbitrary way, and tell you what we decided.