61–70 of 217 posts
There's another much more important limits on AWS SES that the article doesn't mention if you try to do this for normal email, the 10MB message size limit, which translates to about a 6MB maximum attachment size. It works fine for transactional mail and most newsletters, but quite a few users expect to be email larger files than that.
Earlier quoted context omitted.
All very good info that as far as I know is all pretty unique to SES regarding the default/sandbox vs the upgraded production capabilities. The set up makes a lot of sense to prevent abuse and it works just fine out of the box for dev purposes. The production version also operates way more how you'd actually expect an email service to work. All that said, I don't know of any other services that have this "production"…
Sandbox mode is also great for low-volume internal mail like notifications from cron. My guess is that the main argument for sandbox mode is that it requires you to explicitly say you don’t spam and will handle reports, giving them carte blanche to yank your account if you do. Given how slimy email marketing is I suspect someone at AWS didn’t want to deal with people lying to their support people all of the time.
I feel like the current methods for spam filtration are getting so many false positives that it makes email unnecessarily difficult for users with good intentions. I also don't know how much of this is unethical behaviour by the big email providers, forcing you to sign up for their cloud email solution instead of doing your own. It sure would be nice to be able to run one's own email server without having to stress o…
Reading it I get that AWS now by default restricts email by - 200 mails per day max. 1 per second. - Can only send mail to verified addresses. Not sure how they verify though. - Can only send mail from the domain you own and verified. All these are good steps. Guess that will gradually take AWS IPs out of all those mail blacklists. And while we are on the topic, I find IP based mail blacklist services such as BRBL ob…
A serverless server? It is a great illustration of how the term "serverless" has shifted from literally no server (ex: sqlite database) to "somebody else's computer".
I literally had one of the heads of a crucial flight system project loudly exclaim to me in front of the senior managers. "It's serverless - there is no server!" To which I honestly, just kept my mouth shut and stood aside.
I can never keep my mouth shut in these situations. Sometimes it leads to promotions, but I suspect it puts a ceiling on how high I can climb the corporate ladder.
Our service doesn't require a user to sign-up with any existing identity (like email or phone number), and so, when they make payments, we send the invoices from the payments-processor to an email (corresponding to the customer-id) on our subdomain that goes to SES which promptly plonks it into an S3 bucket set up to life-cycle it out after 60 days, encrypting it with keys associated with customer-id. This encryption serves us well when the customer chooses to rotate / delete their pseudo-anonymous identity (and the keys along with it), as then all data in our systems associated with their id (the archived emails, for example) is essentially tombstoned.
The reason we prefer serverless over other solutions is not because of its scale or low-cost, but high-availability.
[0] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiv...
A serverless server? It is a great illustration of how the term "serverless" has shifted from literally no server (ex: sqlite database) to "somebody else's computer".
> serverless server? This isn’t a contradiction. “Server” is an overloaded term and the “server” in “serverless” refers to a different meaning of “server” than the “email server” bit. “Serverless” means there is no physical or virtual hosts to manage, you just supply the request handler i.e., the email server . It's amusing because it sounds like a contradiction, but it's not one.
Yes it is. The "server" in "serverless" means no need to low-level manage/provision a server (computer) and its lifecycle. While "server" in "A serverless email server" means actually "service" as in "A serverless email service on AWS using S3 and SES". Which makes much more sense. The linked repo lets you have an "email server" just like GSuite gives you a "serverless email server".
Earlier quoted context omitted.
> serverless server? This isn’t a contradiction. “Server” is an overloaded term and the “server” in “serverless” refers to a different meaning of “server” than the “email server” bit. “Serverless” means there is no physical or virtual hosts to manage, you just supply the request handler i.e., the email server . It's amusing because it sounds like a contradiction, but it's not one.
I disagree with your assessment, email is a service and not a server . A service can run on a server, or ephemerally as in this article (which still has servers underneath it, you're just not running them). S3 and SES are services running on servers.
There's another much more important limits on AWS SES that the article doesn't mention if you try to do this for normal email, the 10MB message size limit, which translates to about a 6MB maximum attachment size. It works fine for transactional mail and most newsletters, but quite a few users expect to be email larger files than that.
They shouldn’t. Most ISP email providers don’t support more than 10mb.