[HN Gopher] Sending Emails to Myself
___________________________________________________________________
Sending Emails to Myself
Author : voussoir
Score : 69 points
Date : 2021-10-10 19:43 UTC (2 days ago)
(HTM) web link (voussoir.net)
(TXT) w3m dump (voussoir.net)
| indymike wrote:
| I once got hired to fix an application where the original dev
| heard "message queue" and implemented in using email boxes
| because... wait for it... because email has queues full of
| messages. So, instead of reaching for an actual message queue,
| everything was queued via emails, and worker tasks started by
| fetching an email message. About all I can say, is, it worked...
| sometimes slowly.. but it did work, and had the benefit of
| allowing you to inject stuff into the queue by sending in a
| properly formatted email.
| kinow wrote:
| I have seen that too in a previous job! It worked until there
| was a restart in the e-mail relay server, or something in the
| message (I think it was Java, sending multipart messages with
| some custom message format).
| bob1029 wrote:
| Thinking strategically about the most reliable systems in our
| organization today, email is probably at the top of the list. I
| feel like there is a semi-auto magic thing email is still
| missing for a lot of businesses. _Many_ things can be managed
| within the latency constraints of email. All of the hardest &
| most complex things almost certainly can be. For instance, on-
| boarding a new employee could be totally driven by some back-
| end service that simply sends & interprets emails all day to
| ensure that all of the required activities are executed.
|
| Now I am wondering if I can rewrite our B2B product interface
| to just be email. The more I think about this the more it
| starts to make a ridiculous amount of sense...
| User=>Server (Email 1): Subject: Get Workflow List
| Server=>User (Email 2): Subject: Workflow List [hash
| code] Body: <all workflows by name and id>
| User=>Server (Email 3): Subject: Start Workflow #21
| Server=>User (Email 4): Subject: Workflow #12345532
| Body: <First page of onboarding questions the user needs to
| fill out> User=>Server (Email 4 - reply):
| Subject: Re: Workflow #12345532 Body: <First page of
| questions with responses> Server=>User (Email 4 - reply):
| Subject: Workflow #12345532 Body: <Second page of
| questions, or error regarding first page responses> ...
| Server=>User (Email 4 - reply): Subject: Workflow
| #12345532 [COMPLETED] Body: <Completion summary with
| whatever final artifacts attached>
|
| I know our users would totally reject this proposal if it were
| made to be the only way to interact with our product, but if it
| were an _additional_ way to interact, they might grow
| accustomed over time.
|
| Think about the technical advantages of the above. If you keep
| it plaintext, anyone with a computer made within the last 3
| decades could access your business system unconditionally.
| Developer productivity is likely excellent. I can't imagine you
| would be able to get very distracted with plain text emails.
| efazati wrote:
| I think emails is not really the best way to manage errors. Maybe
| something like https://sentry.io/ works better
| mr337 wrote:
| I was thinking the same thing! Any logging tool will help take
| the errors and group them or some kind of housekeeping to help
| vs 200 emails slamming an inbox.
| akersten wrote:
| This is one dudes side projects, not an Enterprise K8n
| deployment - I think email is a great option. Of course when
| you go full "web scale" you should start using products like
| Sentry, but we're talking alternatives to "dump an error to
| stdout" here
| Minor49er wrote:
| Developers can carry the practice into a company if they
| aren't careful.
|
| At my last job, some of the senior/architect developers had
| baked in code that would email them with various application
| statuses. They pointed the logs at their main email addresses
| for maximum visibility. But what ended up happening is that
| they let their inboxes get so flooded with email that they
| simply never bothered to check their email again, including
| any work-related messages. So to solve _that_ problem, a
| couple of them just set up keyword filters to auto-forward
| inbox messages to yet another service that they would check
| on.
|
| Even now, there's some legacy system that emails all of the
| developers with some error messages. I think only two out of
| our 20+ development team even knows what they're for.
|
| Further, if you flood your email server, you can miss logs.
| And if you hand your project off to someone else, you'd have
| to figure out if you also want to hand over your email
| account, or if you want to point the logs to _their_ email
| account.
|
| tl;dr: email is the wrong solution for logging
| Topgamer7 wrote:
| Using loggers in python can be quite handy for a number of
| reasons. But similar to this you can log ship the data to DD, NR,
| ES, Loki, etc. And all you need to do is write a class to handle
| the deets.
| duiker101 wrote:
| Very nice write-up! I did something similar, but with Telegram
| instead of emails. Their API is so simple and easy.
|
| https://blog.hackertyper.net/post/creating-a-personal-notifi...
| voiper1 wrote:
| I have things sending emails to myself, but sometimes I just
| want to mute them for a while.
|
| With this, I'd create a new bot for each project. Then I could
| manage the mute on each project individually with ease. Cool!
| conor_f wrote:
| This seems like an ideal thing to integrate with Apprise
| https://github.com/caronc/apprise
| EvanAnderson wrote:
| I deal with a number of devices and applications that don't
| support SNMP traps for notification but do support email. The
| couple times I've been "mail-bombed" by a device sending
| hundreds, thousands, or more notifications in a short period of
| time have been frustrating.
|
| Has anybody heard of a rate-limiting SMTP proxy or MTA? I've
| thought about writing such a thing, but I'd gladly use something
| already-developed. I'm thinking of a simple token-bucket that
| uses to/from (or perhaps to/from/subject) to limit duplicate
| notifications and/or collapse duplicates in a manner similar to a
| syslog daemon logging "Last message repeated xxx times".
| denton-scratch wrote:
| You don't need a proxy; Postfix can rate-limit natively.
| Plugins, "milters" and stuff inherited from Sendmail; and TCP-
| level filters like Spamassassin, provide pretty-much
| comprehensive control.
|
| I agree that Postfix config is confusing. It beats the bejabers
| out of Sendmail config, but that's whataboutism.
|
| Dovecot config isn't that hard, unless you're trying to do hard
| stuff. Even then, your site config is an overlay on the default
| config, which should be what you get with your distro. The
| site-specific stuff is usually ony a couple of dozen lines.
|
| I expect you could also rig Postfix as a rate-limiting front-
| end for some inferior MTA :-)
|
| [Edit: oh - and Postfix/Dovecot doesn't need a machine to
| itself, if you're dealing with less than 20-or-so accounts, and
| you haven't set up a bot to spam the MTA.
|
| Actually, I think there are exactly zero circumstances in which
| a mailserver shouldn't be kicked-off the machine, in favour of
| a higher-priority job - email is a best-efforts, store-and-
| forward system]
| Karrot_Kream wrote:
| Most MTAs have rate-limiting out of the box. Postfix, Courier,
| and OpenSMTPD have rate-limiting in-built, and though I'm less
| familiar with Qmail, there's probably patches to make Qmail
| work with rate limiting.
| 2bluesc wrote:
| I wrote similar onfailure script[0] for failing systemd services
| that could be invoked by the `Onfailure` unit option[1].
|
| [0] https://github.com/kylemanna/systemd-
| utils/tree/master/onfai...
|
| [1]
| https://www.freedesktop.org/software/systemd/man/systemd.uni...
| jmartrican wrote:
| I am going to copy this in my code. Great post.
|
| Since I do Java code, my guess is to use Spring AOP and create an
| aspect for this that has a point-cut on an annotation called
| something like @EmailOnError.
| mustardo wrote:
| We kinda do a similar thing as a Jersey (Dropwizard) response
| filter, any internal server errors end up in a Slack channel
___________________________________________________________________
(page generated 2021-10-12 23:00 UTC)