291–300 of 430 posts
Makes you wonder if email will someday become so unusable we'll go back to using the post.
Anecdotal but I've just had a company write to me by post because they didn't recieve my last email I definitely sent them, and I'm going to have to write back to them by post.
I gave up trying to run SMTP ourselves years (decades?) ago. Services like Sendgrid et al all made it very easy.
However, in the last couple of years I've noticed even the basic paid plan on Sendgrid, Sparkpost, Mailgun (I've tried them all now I think?) still gets constantly blacklisted. Going to support gives you one answer: upgrade to a dedicated IP, which is close to $100/month, and really quite wasteful on the IPv4 space (if anyone knows a cheaper/better alternative, please let me know!).
The problem is I am often building systems which require very little (but really important) email - the odd password reset request perhaps.
For small webapps you're going to be spending probably more for this dedicated email IP than the rest of your infra combined.
Earlier quoted context omitted.
I'm the Abusix engineer in question (and actually the architect of the system in question), and you're being somewhat "economical" with what actually happened here. Here's the actual chain of events in question: - You recently switched ISPs and that meant you moved to a new IP block. - The IP block in question is owned by Hurricane Internet and unfortunately contains a host which persistently sends out a lot of junk…
> make sure it has a working List-Unsubscribe header (preferably HTTP that allows someone to unsubscribe without having to contact you). Important note: If you use a mailto: unsubscribe, then I cannot unsubscribe a trap, even if I wanted to. This is very interesting to me. Could you elaborate further? - Some providers (IIRC outlook being the main one) only support mailto: and most prefer it. I have never seen advice…
I didn't say anywhere that you MUST support HTTP unsubscribes, but I just said it was preferable (to me at least).
HTTP typically means there is some sort of form which will typically auto-fill the email address from the database (because of the HTTP GET parameters included in the link) and all the user has to do is generally click 'Unsubscribe' and the address is automatically removed from the database.
The reason I prefer this is that if I or one of my colleagues want to unsubscribe a spam trap, then we can - but only if the above is true. (Disclaimer: we only do this very occasionally, usually it's only if we've spoken to someone and are convinced they are legitimate, have fixed any issues we've identified, but are hitting traps because of a single address - if we didn't do this then we'd either have to force the sender to reconfirm their entire database by asking everyone to opt-in again, or we'd have to whitelist the sender, neither are great options - so if we ever do this, then it's done hours/days after the event so as to not tip off anyone on what the trap was).
Because spam traps have to stay secret, we only reference them by a hash value internally (and only I and a select few can convert hash to trap value to do the unsubscribe) and as the messages are received on our trap network the traps themselves are obfuscated to a know value before they are stored in our evidence system.
mailto: means we can't do this at all - a trap can never originate traffic, that's cardinal rule of them, it would be grossly unfair if they did.
> - What do you mean by unsubscribe without contacting me? Isn't HTTP or SMTP just as much contacting me?
Poor use of words from me.
What I meant is that I don't trust messages that have an unsubscribe that does not encode the recipient in it in some way e.g. HTTP method without GET parameters (as this means I would have to do considerably more work to fill out the form) or a mailto:foo@domain.com?subject=unsubscribe - both to me scream our that there is no automatic connection to a database and that someone on the receiving end has to manually remove the address - which could take weeks, or be never.
I'm dealing with this right now. Both my personal domain and rsync.net are on a distinct subnet, but that subnet is smaller than a /24 and someone on a different subnet has, apparently, behaved badly. Enter "abusix" ... One of my engineers had an enlightening webchat with one of their engineers where we were shown the "offending" IP and it was explained that they have no ability to distinguish subnets (and no interes…
I'm the Abusix engineer in question (and actually the architect of the system in question), and you're being somewhat "economical" with what actually happened here. Here's the actual chain of events in question: - You recently switched ISPs and that meant you moved to a new IP block. - The IP block in question is owned by Hurricane Internet and unfortunately contains a host which persistently sends out a lot of junk…
(snip)
"That tells me that you knew that you were sending to old accounts and that your bounce handling was either not great or non-existent."
Yes, that is exactly right.
I have instructed everyone to be as liberal and forgiving of non-payment and failed contact as possible. These people, who were paying customers, have data stored here for safekeeping and we're not going to trash it because we haven't heard from them in 3 months or their email bounced.
I can give you hours of stories of customers who came back from military deployment, came back from depression, came back from prison, came back from financial ruin ... that contacted us, beyond all hope, to see if we still had their account. And we did.
After 21 years of doing this are there a few hundred accounts that we are giving extreme benefit of the doubt to ? There certainly are.
Bottom line: our duty of safeguarding customer data trumps this weeks fashionable spam heuristics.
Earlier quoted context omitted.
I'm the Abusix engineer in question (and actually the architect of the system in question), and you're being somewhat "economical" with what actually happened here. Here's the actual chain of events in question: - You recently switched ISPs and that meant you moved to a new IP block. - The IP block in question is owned by Hurricane Internet and unfortunately contains a host which persistently sends out a lot of junk…
One other question. How do you manage domain based reputation vs IP reputation. I'm trying to get by running a service off of Cloud provider IPs and they may rotate from time to time as VPSs rotate. Part of me feels that once my domain has enough reputation it should be fine. It does seem like some of the big providers work like this (Google seems to trust me now from any IP) but it seems that a lot of smaller provid…
Because spam traps get very different traffic to a real mail server, you can make a lot of assumptions that would be impossible to do on a real mail stream.
So generally speaking, if your domain name isn't in the top million domains (and there are still some exceptions to this - but I'm not going to list them all here) and you hit one of our pristine traps (see my post about the different trap types) with a message containing your domain, that will usually cause the domain to be listed.
Other lists and spam filters will have their own methods for this.
My belief is that Google and Microsoft only use AI for this (which is a bit of a nightmare if it gets it wrong).
Earlier quoted context omitted.
the email w/unsub link could be forwarded also, it's often a portal to change notification settings w/o auth and leaks personal preference info - and when there is auth it's impossible to unsub when if were signed up maliciously. it happened to me - someone charged a bunch of stuff to my cc and then registered my email at thousands of sites to bury the email receipts (it didn't work since I have simple filters for th…
Ugh that sucks. But in the cases where there is authentication, isn't it enough (in most cases) to reset the password and change the email to something disposable? Of course that's not really practical for the case where you get subscribe-bombed, but maybe for the general case it is, no?
Earlier quoted context omitted.
He didn’t say threaten them. It’s pretty easy to envision a situation where a lawyer sends a quite friendly and factual email to a company, that is literally identical to the one the IT head would have sent, but because it’s coming from a lawyer the recipient uses completely different internal routing to process the request. So someone actually takes the request seriously. Seems both plausible and a reasonable thing…
In the American legal system, if somebody spends the money to take the time to have their lawyer hand craft and send me a letter about something such as this, I'm going to take it as a threat whether or not it specifically contains one. The implication is that if you do not do whatever is demanded in the letter, the next step will be the client of said lawyer escalating the situation to paying their lawyer to actuall…
Make it a legal and business decision instead of a technical one. And find an audience that knows the practical benefits of quick resolutions to reasonable requests.
And I say this as a person that would likely respond in a similar punitive and/or principled way to what you described upthread. Which is exactly why I leave it to the lawyers.
Earlier quoted context omitted.
Everything you've said makes perfect sense - for a contact management function. We have that. You can change contact info, set owner/technical/emergency contacts, alert thresholds, etc. But unsubscribe means something totally different: When I click on unsubscribe I want it to be the end of all communications. Period. In this case, that makes no sense. Ceasing communications for all purposes implies service cancellat…
From a comment below from the other side of the equation it sounds like the email in question WAS indeed marketing for a lifetime promotion. People should have every right to unsubscribe themselves from that, and thus should have some sort of feedback loop attached to the email being sent (to the detriment of your bottom line I fully understand and sympathize with). If this was indeed a marketing email, then I don't…
I agree.
We have a flag for such a thing and set that flag when people ask us to. They ask us in a nice email exchange between human beings. We're very responsive to this since they are our paying customers.
That's the big disconnect here: it's inconceivable to many people (including abusix, et. al) that healthy, straightforward interactions like this occur in 2022.
In their mind there are nothing but robots and newsletter subscribers forever locked in an arms race.
I'm sorry that is the case.
Spam blocklists are run by an unaccountable cowboy cult that somehow has managed to consolidate a ton of power simply for the fact that most people who run email inbox services didn't want to deal with the problem of spam, so they were more than willing to just hand over anti-spam "enforcement" to anyone who was allegedly doing "what was best for the internet." There's no check on these people who run these blacklist…
Let's not classify all spam blacklists as the same. UCEPROTECT is in a special class of extortionist cowboy, because it's basically just an inaccurate protection racket throwing a wide net across cloud providers who won't play their game. Some other blacklists are updated regularly and only contain IP addresses that have actually sent spam. By contrast, UCEPROTECT3 just lumps ISPs into the list even though an address…
People have been complaining about this for a very long time; as long as I can remember. In the past they've also just permanently added people's IPs after complaining their IPs were wrongfully listed (not sure if they still do that).
The UCEPROTECT blacklist should be blacklisted by everyone. Yes, we need a blacklist of blacklists.
Earlier quoted context omitted.
I'm the Abusix engineer in question (and actually the architect of the system in question), and you're being somewhat "economical" with what actually happened here. Here's the actual chain of events in question: - You recently switched ISPs and that meant you moved to a new IP block. - The IP block in question is owned by Hurricane Internet and unfortunately contains a host which persistently sends out a lot of junk…
"- Your engineer said to me "we took down 600 old accounts and are reviewing our contact policies going forward" and "there are still plenty of other customers who are listed generically as bouncing so we will have work to do here"." (snip) "That tells me that you knew that you were sending to old accounts and that your bounce handling was either not great or non-existent." Yes, that is exactly right . I have instruc…
I haven't suggested that you do anything differently to that.
Keep the data, keep the accounts, do whatever you feel is best for you and your business.
All I've said is to be smarter when it comes to sending email to old accounts that are repeatedly bouncing. I've outlined what was wrong and I worked with your engineers to resolve it.