Email Forwarding Changes

Email can be forwarded using websockets, webhooks, slack, and catchall. The way email is forwarded has been changed for consistency. Reserved addresses, which are part of a catchall domain, will now be the inbox email is saved to. Catchall forwarding will still take place on websockets, webhooks, and slack webhooks.

Examples:

  • Websocket post to *@domain.com and private@domain.com
  • Webhook post to *@domain.com and private@domain.com
  • Slack Webhook post to *@domain.com and private@domain.com
  • Save email only to private@domain.com

Improved SMTP Responses and Throttling Changes

SMTP Responses

The robustness of our SMTP server has been improved by providing better response codes.

  • Response code 553 when email is missing a recipient
  • Response code 421 when inbound email is being throttled and the server is unable to accept the message until a later time
  • Response code 554 with meaningful error message describing the cause (blacklisting or internal server error)

Throttling Improvements

Incoming SMTP connections will be queued based on system load. The connection will stay open while waiting for system resources. If the SMTP connection cannot be completed in a reasonable period of time the server will issue a response code of 421. This situation may be encountered while sending a large amount of email from a specific server or to Mailsac hosted email address.

API Response Fixes

The status code for reserving an address on the API was returning a 302 in some situations, while the documentation said it was a 200. This has been resolved. This endpoint for reserving an address will also return the address object.

When deleting a private address, the API used to return { "ok": true } with a 200 status code. Now the API will return a 200 a copy of the address object which was deleted.

Official API documentation

(Fixed) Upstream API proxy service network connectivity – workaround

Our upstream provider has indicated there is a full scale outage in their Chicago data center. This affects our API and frontend proxy, but inbound mail is still working as normal. To work around the issue, the following endpoints can be used without HTTPS:

http://acai.mailsac.com

http://goji.mailsac.com

 

Status for our upstream provider can be monitored here (see Chicago):
https://www.vultr.com/status/

As always, the Mailsac status page will indicate when things return to normal:

https://status.mailsac.com

 

Postmortem

Beginning at 2018-07-17 10:39:17 Pacific, our upstream provider had a partial network outage in their Chicago data center. After determining that the API and UI proxy could not talk to the backend endpoints, we started the recovery plan of moving the proxy’s IP to a hot spare proxy. However due to maintenance blocks in our upstream provider’s system, we were unable to make changes to the IP allocations. After 11 minutes, network connectivity was restored.