mastodon.cc is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon for Art

Administered by:

Server stats:

68
active users

#smtp

3 posts3 participants0 posts today

Hi there. I'm self hosting my SMTP server for years, and I have 10/10 on mail-tester.com/

Recently, I've got 2 messages rejected by Apple server (on "@me.com" addresses), and today I've got a SPAM abuse signalement (probably automatic) for those 2 emails! I could send to those same addresses without problem before.

Do other people have had similar problems with Apple SMTP servers recently? What can we do? TIA

www.mail-tester.comNewsletters spam test by mail-tester.commail-tester.com is a free online service that allows you to test your emails for Spam, Malformed Content and Mail Server Configuration problems

I thought I had seen it all when it comes to mail delivery and security issues.

But this morning I was introduced to the fact that there are Exchange admins who will implement a rule that all incoming mail from outside their own organization should be flagged as potentially dangerous and presented to the user with the option to block sender and no option to mark the message or the sender as valid.

Yes, that for every single message.

What would you use these days to send out emails with auth codes for a small-ish web app? I have no interest in using Sendgrid, Mailgun, etc. I just need something to send out emails from `no-reply@example.com`

I don't even need to accept incoming email.

Preventing enshittification of platforms rests on credible exit for users and devs. #ActivityPub and #SMTP are not perfect but

a) are implemented und understood by many players,

b) enable freedom of choice of servers and clients,

c) implement #RightToMigrate as well as self/community custody

Many #p2p projects promise to remove servers but often promote and depend on a single implementation stack, have no spec and no interop among #p2p islands, and thus struggle to provide credible exit.

Following a recent discussion of email security over at Linkedin, I think perhaps my old but recently updated spam and malware countermeasures article is still worth reading if the subject is important to you - nxdomain.no/~peter/effective_s.

The reference section has pointers to a seemingly endless sequence of field notes related to these matters. The so far last entry is my New Year 2025 post "A Suitably Bizarre Start of the Year 2025" nxdomain.no/~peter/suitably_bi #email #smtp #spam #malware #security

nxdomain.noEffective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools

Here's an interesting question for you:
Can RFC 2047 encoded text in the Subject line of an email contain encoded line break characters (i.e.,, ^J, a.k.a. 0x0A)?
I don't think they should, because the point of RFC 2047 encoding is to encode non-ASCII characters which would otherwise be legal in the Subject line, not to encode characters which would otherwise be _illegal_, which includes line breaks.
RFC 2047 itself doesn't give a definitive answer.
What do you think?
#email #MIME #SMTP #SysAdmin

Le sigh. It appears #mozilla is too distracted with #AI and #LLMs to run their good old #email correctly. Maybe they should buy @mwl 's #RYOMS and learn a thing or two.

I signed up for their community forums so I could comment on the AI experiment in Nightly. This, as you can imagine, is getting A LOT of noise and I think mozilla is trying to email me and tell me that things have happened on that thread. I'm not getting the emails. My upstream mail receiver is showing 775 messages queued up for me, that my email server keeps rejecting. Let's look at why.

  1. The host community.mozilla.ORG is a CNAME to bnzry48543.lithium.com.
  2. bnzry48543.lithium.com. is a CNAME for d3rxjeenbqqyxw.cloudfront.net., which is AWS's CloudFront CDN service.
  3. There are no MX records for community.mozilla.ORG because there cannot be any others. If you're a CNAME, you can't have any other records. God only knows why there is this extra lithium.com CNAME in there. Probably so they can have an Alias record in a hosted AWS zone. (Hint: this is the dumb way to do it. The right way is to create community.mozilla.org as a Route53 zone, so you can get the Alias records for CloudFront, then in your mozilla.org zone you create NS records for the Route53 zone. Look at how I do blog.paco.to at AWS, when paco.to DNS is not hosted at AWS for an example).
  4. The Mozilla community software is sending emails out with a from address of community@connect.mozilla.COM.
  5. If you run dig connect.mozilla.com any you will find (assuming you find the same as me), a single, solitary TXT record: "v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email ~all". I'm not up enough on fancy-ass SPF records, but what I can tell you is that there is NO MX record for connect.mozilla.com. That makes it a pretty illegitimate domain to be on the righthand side of an @ in email. If I would like to send email to community@connect.mozilla.com, where should I direct that mail? Undefined. Ergo, illegitimate.

So, at the moment, my SMTP upstream and I are stuck in a bit of an argument. They've accepted the email from connect.mozilla.com and when they present it to my mail server, I say 'illegal domain, man. fuck off.' Well, they're a little stuck. They can't send that rejection back to the originator, because that's not possible (No MX record). So they pause, consider their life choices, and try again. I'm currently fielding 1800 attempts per hour and I have no idea how many of those are the umpteenth retry of something sent 5 days ago, and how many are a first email that was sent this morning. (It's no big deal. I mentioned it to my support folks, they'll get it fixed soon)

Maybe someone at Mozilla can ask #ChatGPT "How do I configure DNS records for email?" and get a halfway competent reply. I wish they'd just work on #firefox features that I want, instead.

Fucking #Comcast is (again) bouncing emails from my family mail server with no explanation of why or what to do about it. Just "554 server not available".
There is no legitimate reason to bounce emails from my server. I do _everything_ correctly (incl. #DKIM and p=reject #DMARC) and my server has been in continuous operation for over a decade.
Comcast is the worst, but, they're not the only one pulling this crap.
Yet another domain I have to route through #MailGun. *sigh*
#smtp #sysadmin