451–460 of 460 posts
Earlier quoted context omitted.
In most internet engineering task force RFCs the standard verbiage for "must not" usually is in fact "should not".
The phrase "must not" appears some 60 times in this RFC.
Earlier quoted context omitted.
Aside - I'm not an expert but systems like MailChimp will get very worked up if your list has lots of undeliverable addresses on it. This can trigger an audit of your list which prevents sending, etc. These audits seem to take quite a while, in my very limited experience.
So what you're saying is, if you're annoyed by "subscribe to our mailing list" modal popups, "doesno5exist@garbage.blah" is better than "jeff@amazon.com" ?
If you want revenge for modal popups, your best bet is to create a bunch of throwaway email accounts, subscribe to the mailing list from them, and start reporting the individual messages as spam when they arrive. Flag them as junk at the mailbox provider (Gmail, Outlook, etc.) and use the links in the List-Unsubscribe headers to flag them at the ESP's end, too.
Earlier quoted context omitted.
Your answer kind of misses the point GP was trying to make. Google's mailserver could genuinely believe that the user doesn't exist, if the user service doesn't fail completely but cannot access part of the data and thus doesn't find a user record. In this case the returned "user doesn't exist" error is intended behavior of the mail server and the post you replied to still stands. If you sent to that email successful…
But then why would Google's mailserver not know that it once delivered email to that mailbox? If the protocol is stateful, why the state should be kept by the "sender" and not by the "receiver"? Being stateless removes this ambiguity in my opinion. Also we should remember how bad is for spam reputation sending emails to a non-existent address and thus I would not blame it on the mailing list for being "overly cautiou…
Hard-failing good addresses is a much worse bad than soft-failing bad addresses. In the latter case, remote sender tries again later and eventually gets a hard bounce. In the former, good addresses are permanently dropped from numerous services, and sent mail is lost rather than retried.
Critical failures should soft bounce until positively determined otherwise.
Earlier quoted context omitted.
What you're saying makes sense but I don't think it really applies to anything the OP said. The "non-confidential" qualifier indicates to me that they only want people to share what they can responsibly.
And the parent post’s point is that there are people whose job it is to specifically share that information, and so we should let them do their job. They are the domain expert in this particular task.
1) Harmless to share 2) Will never be shared by PR teams
I don't see anything wrong with asking people to share what they can.
Earlier quoted context omitted.
And the parent post’s point is that there are people whose job it is to specifically share that information, and so we should let them do their job. They are the domain expert in this particular task.
For any incident like this there are tons of details that are both 1) Harmless to share 2) Will never be shared by PR teams I don't see anything wrong with asking people to share what they can.
Just got this from the ProtonMail team: > Dear ProtonMail user, Starting at around 4:30PM New York (10:30PM Zurich), Gmail suffered a global outage. A catastrophic failure at Gmail is causing emails sent to Gmail to permanently fail and bounce back. The error message from Gmail is the following: 550-5.1.1 The email account that you tried to reach does not exist. This is a global issue, and it impacts all email provid…
This is the Nightmare Scenario for mailing lists. Many of them auto-unsubscribe after a bounce.
[1]'Check email service status before sending emails' - https://needgap.com/problems/178-check-email-service-status-...
Earlier quoted context omitted.
Ah I think I did not describe the repercussions of making exceptions (even if they are in highly specialized cases like this). If you allow yourself to make such exceptions, you diminish the motivation for you (or someone else) to fix the problem at the right place. Most workarounds tend to live forever.
There's no clear-cut rule here. Some workarounds stay workarounds and never get standardized. Some become so well-accepted and adopted that people then put them into standards. It's great to put things into standards, so by all means, do try to improve standards. But that shouldn't block you from everything . At the end of the day, standardization is just a means to an end, and the end is what matters here. Nobody ca…
Exactly, that is why it is important to follow standards. Most engineering decisions are not clear-cut and are born out of tradeoffs. That is why we agree on standards that define those tradeoffs instead of every one of us having our own take on situations.
> Nobody cares if their mailman's knocks follows an RFC or not
If there is a Mailman RFC which says: "If someone opens the door and says `Mike does not live here' then DO NOT attempt delivering the same package"
THEN I expect the mailman to not bother me again, EVEN IF it was actually my mistake that I forgot my roommate Mike actually does live at this address.
Earlier quoted context omitted.
Same for me, mainly for privacy concerns. And I back it up daily to my local NAS. It's so easy to configure and run your own mail server, that I'm surprised we are the minority in the tech community.
> It's so easy to configure and run your own mail server Is it? Is dealing with IP reputation, getting your emails accepted by major providers, and being on the hook for fixing everything yourself very easy? I haven't tried, so I don't have personal experience, but I've heard enough horror stories to think that it's not a good use of my time.
Receiving side is where there is a great range of options, and many things to try and have fun with. You can have anything from a single catchall mailbox with no filtering, no GUI, and a simple IMAP or POP3 access for MUA, to a multi-account, multi-domain setup with server side filtering, database driven mailbox and alias management, proper TLS, web MUA access, etc. It can also be built up gradually, starting from very simple setup to something more complicated so that you never lose account of how things work.
I use Helm for email. It’s a silent little server in my living room routed via Amazon (using a TLS cert that lives in my living room). I’d say about every three or four months it goes down for 5 minutes if I need to reboot my wifi router. I use it for privacy (am a fan) but I feel pretty smug knowing I’m getting better reliability too. At least this month :) No affiliation with the company. https://www.thehelm.com/
I remember seeing this when it first popped up on HN. Very cool. Home internet is pretty reliable these days and my sense is that it’s getting better, not worse, as people value their internet connectivity more. Is your data backed up anywhere in case your Helm box burns in a fire?
Earlier quoted context omitted.
There's no clear-cut rule here. Some workarounds stay workarounds and never get standardized. Some become so well-accepted and adopted that people then put them into standards. It's great to put things into standards, so by all means, do try to improve standards. But that shouldn't block you from everything . At the end of the day, standardization is just a means to an end, and the end is what matters here. Nobody ca…
> There's no clear-cut rule here Exactly, that is why it is important to follow standards. Most engineering decisions are not clear-cut and are born out of tradeoffs. That is why we agree on standards that define those tradeoffs instead of every one of us having our own take on situations. > Nobody cares if their mailman's knocks follows an RFC or not If there is a Mailman RFC which says: "If someone opens the door a…