This feels like it's pushing the TOS for Github Actions a bit by using it for post deployment, live operations. Like the hourly health check and your dead letter queue scheduler.

It made me curious, so I looked at their TOS[1], and they seem somewhat permissive about things like this. Though vague about where/when you cross the line.

Like, this seems clear:

"should not be used for...any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used."

But then:

"but a low benefit Action could be ok if it’s also low burden"

[1] https://docs.github.com/en/github/site-policy/github-terms-f...

Also note that Github will deactivate cron actions if there is no activity in the repo for 60 days.

https://github.community/t/do-disabled-scheduled-workflows-r...

But you do get an email warning you, with a button to say 'no, keep going'.

(I maintain docker images for gocryptfs & mergerfs - https://github.com/OJFord/docker-gocryptfs https://github.com/OJFord/docker-mergerfs - that check for updates to those respective projects and push an updated image; if there's no new upstream version for a while then I get that email and have to click it to keep it running.)

Obviously you can automate that with another repo that has a cron job to push a dummy commit every 30 days.

In fact, they can play ping pong and keep each other going forever :)

You don't need seperate repository for that. You can use Personal Access Token & self-push.

I have a crown action which commits its own log. So, always active!

Perhaps for the virtual machine. If this concerns you this could be used with GitHub Actions Self-Hosted Runners.

SHRs let you use github workflows while performing operations from local machines.

These machines can be set behind a firewall.

Perhaps some of the novelty of this project is that it doesn’t require any paid cloud resources other than AWS.

But it does not take much to set up a self hosted runner locally.

Interesting. I use Github Actions to tag incoming bugs with a "needs-triage" tag. That is not related to production, testing, deployment, or publication, so I guess I'm not in compliance.

Seems like a lot more hassle than using purelymail[0] for $10 a year, which has full Sieve and SpamAssassin and sub-addressing.

0. https://purelymail.com/pricing

Purelymail does look great for personal use. But, be aware it wouldn't be economical for something like a big mailing list.

Try the calculator at https://purelymail.com/advancedpricing and put in some large number of outbound email sends, like 2 million in a year, and the cost gets into the thousands.

Purelymail sent emails are $2.03/1000 plus $0.18/GB. Compare to SES, which is $0.10/1000 plus $0.12/GB.

This is great! Thank you.

There is also https://forwardemail.net/ which is a different service.

Was just about to post this. I've been using it from the beginning for all of my "pre-launch" domains and it has been flawless.

I also use forwardemail.net and pay for premium. It's fantastic, although I haven't made use of the APIs yet so can't speak to that.

Also anonaddy.com which provides better privacy at 1$/month for custom domains.

The complexity of setting up forwarding with AWS Simple Email Service/handling incoming messages without using their WorkMail is why I moved off it for my next project. There is no real option for this, although Amazon does provide a tutorial for rolling your own using a combination of S3 and a Lambda Function. [0] You'd think instead of creating a tutorial basically asking users to copy and paste their code, they may just want to add it as a feature.

In fact, I find almost everything on AWS overcomplicated. I ended up moving to a combination of MailJet for outgoing transactional mails and Zoho for incoming emails. This combination also happens to be free while in development.

0: https://aws.amazon.com/blogs/messaging-and-targeting/forward...

Would be more accurate to say "Hosting your own email forwarding service on AWS", as the README does. The GitHub Actions piece is for managing it.

This is not objectively less complicated than running your own mail server and certainly requires no less prerequisite knowledge, just different.

I get doing this for the fun of figuring it out and I'm all for that kind of project.

If you just want something easy, https://forwardemail.net/ has a free tier that would cover this need nicely without having to learn much at all.

edit: typos

This is a poor strategy

Not only is it a deep violation of their TOS, but also, they're just gonna shut you off at random when your 3000 hours run out

Doing this right on a VM costs less than two dollars a month

This is a ticking time bomb, and may cause Microsoft to be less generous in the long run

Somewhat off topic but how does one make that cool 3D architecture diagram?

very cool looking but a bit hard to read, at least in the maildog readme

Totally! The isometric view is impossible to read.

A fair amount of that seems fixable with better color choices and fonts/size. It's curious to me that cloudcraft hasn't improved it. Lightish orange on a white background, for example?

Very cool! My friends and I built https://m8l.me/ which is very similar and we've been using it for the past year. Instead of forwarding to email address like maildog, m8l.me forwards all emails to your server (or any server) as a POST request. If you don't receive many emails a month you could use the free AWS EC2 instance and store the emails in sqlite, thereby creating unlimited custom email addresses on your domain for free.

M8L looks great, nice work! Are you able to give any insight into the architecture? I'm always paranoid when putting free tools online that they're going to suddenly get a wave of users & cost me a ton.

Another alternative is https://github.com/arithmetric/aws-lambda-ses-forwarder which is purely AWS lambda based.

I used to use it before now. Now, I run my own email forwarding service at https://hanami.run to expose a nice UI and a Rest API so I can `curl` my emails.

Please, oh please, do not forward email.

https://www.tidbitsfortechs.com/2018/06/email-forwarding-is-...

^ I am the author of that article. If this is a different kind of mail forwarding, then please educate me as to how. Thanks :)

Interesting article, I'm not sure if it applies to my situation or not. I use ImprovMX to forward several domains to one of my other domains.

I think one thing the article doesn't really mention is that the domain sending the email is only one (potentially small) factor in classifying email as spam or not. Gmail has done just fine classifying different emails as spam that are being forwarded from the same domain. After all think of how much spam is sent from the gmail.com domain.

I am not sure how common this is, but my domain registrar does this for me. In case someone else is looking for a simpler way to do this.

Doesn't Google Domains do this at no extra charge if you host with them, or am I nuts?

(I may be nuts, its almost a certainty actually)

Yes, they do.

I run email for two companies. In both cases, everything from SES goes straight to quarantine and users never see it. I would just reject SES altogether but once in a while something legit comes in and someone asks me to release it. I see a massive amount of spam from SES and pretty much all email service providers.

> I see a massive amount of spam from SES

Okay.

> and pretty much all email service providers.

Uh, how do you handle email then? Which provider do you use / can you recommend?

I don't see it as a which provider issue. If you receive email you will receive spam from all over. On the receiving end, I treat providers differently based on what we get. I see a lot of phishing and advertising from SES but we use Amazon so I can't reject it. I almost exclusively see phishing attempts from SendGrid so I outright reject email from SendGrid. So many things and people use gmail that I can't block gmail but I do increase its spam score. I see phishing attempts from gmail accounts almost every day, I report them to Google. Its the phishing that worries me most, seems incredibly easy to sign up for a service like SendGrid and start phishing people. Not one of these email service providers can/will globally block recipients in its network - one is forced to play a game of whack-a-mole, which means the bad guys always win.

In terms of outbound email, I have a very Dilbert answer for you. The marketing guy picked Constant Contact and we use that. I have no idea how good deliverability is with CC vs anyone else. We use an opt-in email list, don't send a lot of communications, and immediately honor opt-outs.

neat!

I usually just use gsuite + aliases/groups, which includes spam filtering, web console and a lot more. Granted, it's ~$6/mon, doesn't scale to 20,000 email addresses and you have to be cool with Google.

There something else I'm missing out on?

Yours isn't a DIY hack for fun.

I don’t understand how this is any better than flipping on email forwarding on most domain registrars. Or why you wouldn’t use plenty of other services for a few dollars a month

Taking Amazon SES to production can be a little tricky, I think I am talking to robots with templated messages. Maybe I don't have luck or didn't explain myself well enough.

I didn't have any trouble with getting them to enable production mode SES for my personal email domains. The only thing I can think of that might have helped me (besides making it clear I wasn't using this for marketing emails) was that my AWS account had been open and in good standing for quite a while before enabling SES.

Add AWS to title, please.

How it could be use to send email using Gmail “send as alias”? Like sending as sales@example.com from your own gmail account

ImrpovMX.com handles this nicely too (for free)

There's a typo in the URL. It's https://improvmx.com/ and is free for 1 domain, $9/month for up to 100 domains & 100 aliases per domain.

I use ImprovMX for this.

I use a similar service, forwardemail.net for this, and it's free.