A bit about email
58 points by robalex
58 points by robalex
Big-tech requires the sender's HELO hostname to be consistent with their IP address, via both forward and reverse DNS. [...] this policy also makes it impossible to directly send mail from most residential internet connections unless you own the address block.
I always though that big mailers simply blacklist residential IP blocks, regardless of their A and PTR records, because it's (from their POV) unexpected to receive an email from a residential IP address.
It's both. I had a working reverse resolve and I still had to annoy corporate contacts to unblock me.
What is a “resolve”?
but using a tool that automatically inserts cartridge-return bytes is easier
What is this, an inkjet printer? Carriage return!
This is well written.
AFAIK the RFC explicitly states the re-try policy, but it's not always followed. I came across a case where the email didn't come through the first time because of spamd and the client's smtpd never re-tried. Hence the email was lost.
Greylisting is an anti-spam technique that exploits the retry polity of SMTP. I use it on my email server, and it easily stops 50% of spam because a lot of spammers don't bother with retrying. The only issue I have with greylisting are time-sensitive emails (the "type this code into the web site to authenticate" emails, and I can work around this by either whitelisting the email address, or temporarily disabling the greylisting).
I thought that the spammers had adapted to this a long time ago. Looking at my, although very small, personal mailserver i get a 19% effectivness over the last 7 days. This is higher than i had guessed but much worse than a few years ago.
I just checked the logs over the past month, by checking the number of emails that expired still in the greylist state, versus those that were accepted by passing the time threshhold [1]---it's a 50/50 split (close enough). And yes, some spammers have adapted, either by compromising actual email accounts, or setting up servers to resend (and when they do, they resend the email the number of times it failed, so they usually send up sending me two or three copies of the same email---I personally find it rather amusing).
[1] I do have a way of short-circuiting this, by allowing either certain IP addresses or known senders to bypass the greylist process, but I skipped those in this calculation.
If your greylister can handle regular expressions, it is useful to use something like this:
/^.*-sub-.*@domain\.tld/
and then sign up for things with email addresses like:
dsr-sub-bostonglobe@example.com
Which you can then have your mail user agent or sieve filter into the correct folder.
You'll also get an immediate idea of who had all their subscribers leak (or sold their lists)
I don't support regular expressions, but I can filter on IP address, from domain, full from address, to domain and full to address. And because I run my own email server, I do set up unique email addresses to sign up for stuff.
This property, called non-repudiation, is generally not desirable for messaging systems.
I've come to find that property quite valuable, especially in messaging systems. Granted, my use-case is for signing and certifying, not for keeping secrets (encrypting).
However, once the [private] key has been published, the signature can been forged by anyone and is rendered retroactively untrustworthy. ... it will cast doubt on the authenticity of leaked messages since the signature could have been forged with minimal effort.
Ah, but what if another party is DKIM-signing on top of you? And of course, if it is known that a sender is playing "publish my private key on purpose" games like this, then I'd be just as worried that folks would take that as a sign that a forged message is actually one that the sender really did send.
I tried sending an email for fun, but I was hoisted by my own petard. His server correctly denied me because I've set up my DNS records to disallow anyone but the host I typically use to send email for me.