We have setup a new mail submit service for Librem One users at ms.librem.one. To use this server, just replace smtp.librem.one with ms.librem.one in your mail client sending mail settings.
This server runs on latest debian gnu/linux stable version trixie, has latest postfix/opendkim and other libraries. Once more people test and confirm it is working well, we intend to point smtp.librem.one domain to the new server.
This update is part of tightening mail server configuration to prevent spoofing and spam.
This is an early call for testing the new server, so if you have a Librem.One email account, please test the new server and let us know if you find any issues.
Because of a gaming club that I belong to sends uses address lists .gt. 60+ odd recipients, it already means I can’t do reply-alls and I switch my replies to gmail.
Does this tightening of the email server lower that number again?
I haven’t seen a mass spam in years as it seems they target one addresee at a time. I think the recipient limit is a red herring now.
I think you are correct. Any recipient limit should be a rate limit on total recipients regardless of whether the recipients are distributed as
one email sent to 60 recipients
60 emails sent individually to each recipient
anything in between
but there should be some limit.
Regardless though the judgement call on this restriction is a difficult one. If Purism gets marked as a spammer and thereby blacklisted, it will be painful for Purism and painful for all Purism (Librem One) customers.
However
I feel as if your gaming club is not “doing it right” then.
With a mailing list, you should be replying solely to the mailing list and the mailing list host should be doing the fanout to send to every person on the mailing list. The identity (and email address) of each person on the mailing list should be secret (suppressed from view to you and to anyone else on the list). “reply-all” should not even be possible.
Unless of course you are the one managing the mailing list and the mailing list host is (or was) Librem One.
Having said that the identity should be secret, of course an individual contributor to the list may choose to include identifying information, including an email address, within the body of the contribution and in that case the identifying information would cease to be secret.
Some do. Some don’t.
I still see lame spam/scam emails addressed to “Dear Customer” or “Dear Sir/Madam”, which could well have been sent en masse.
But I also see better spam/scam emails addressed to “Dear Irvine”, where they have inferred the name from the email address, which by definition are emails sent one by one.
And the better still spam/scam emails marry up lists of email addresses with data breach material, so that the email is not only personally addressed but includes correct other personal information. (This can still be epic fail though if I am not a customer of the company that this is pretending to be from.)
On 25th at 7am UTC, I will make the new server the default outgoing mail server by pointing smtp.librem.one domain to ms.librem.one. Users won’t need to change anything, but domain propagation could take time. If you see problems during the transition, you can manually switch to ms.librem.one as domain. Both ms.puri.sm and smtp.puri.sm will work after the transition.
Looks like you’ve set the TTL to 5 minutes. So if anyone has a problem during the transition then one approach for troubleshooting can be “wait 5 minutes”.
(Except where a cache is intentionally over-caching i.e. caching a DNS entry beyond its official lifetime, which I myself do in some circumstances.)
This update is completed, now both servers can accept smtp.librem.one domain in tls certificate. Once the DNS propagation is done, I will remove this domain from the old server - we have time till the next domain renewal.
As part of tightening the mail server, only mails coming via mx1.librem.one (as per MX records) was being accepted by imap.librem.one (which serves inbox to users). This caused librem.one to librem.one mails being unintentionally rejected. Someone contacted support and reported this issue. I have now fixed the issue by allowing ms.librem.one also to relay mails to imap.librem.one. Sorry about the unintentional disruption of Librem.One to Librem.One mails (all incoming and outgoing mails from any other server was not affected). We missed this specific case when testing the permission changes.
I’m going to update librem.one SPF records from softfail (~all) to hard fail (-all) for any IPs explicitly not listed in the SPF record. I will do it on 10th at 7am UTC.
I agree. If a domain goes to the trouble of defining an SPF record (which it should), the SPF record should be exhaustive and hence hard fail, if at all possible.
Since dovcot (our imap server) was still using the old certificates, which expired, there was a downtime for about 10 hours for accessing mails (mails were received just fine - only access to inbox was affected). This is now fixed. Sorry for the unexpected downtime.
I have found that mails from domains with hard fails in their SPF records have a higher chance of being undelivered if that mail gets forwarded or relayed at some point on it’s journey.
This is far more likely when it lands on an old server that leans heavily on SPF records only (i.e. no DKIM or DMARC checks) for validation. Although, I have also seen some servers fail the mail when SPF checks are done before DKIM in the validation process or just generally put too much weight on the SPF record.
That’s right. For the scenario of SPF only and hardfail and, let’s say, Librem One user sends email to fubar@example.com and that recipient is redirecting email to fubar@gmail.com … it is essential that the mail server at example.com changes the SMTP FROM (envelope) address when sending the email on so that it no longer claims that the email is from Librem One (e.g. inserts one of its own email addresses).
This has implications for bounce though e.g. if fubar@gmail.com is actually no good, particularly if Google doesn’t say so up front i.e. accepts the email and then subsequently generates an NDN.
The most common scenario I see is with a domain having a primary mail server and a backup, the primary server goes down, mail is received by the backup, primary server comes back online, backup server then relays any mail it has received over to the primary. The backup server is not listed within the SPF record of the sending domain and as such raises an SPF hard fail.
I will never have that problem because in that exact scenario (transferring backlogged email from secondary to primary) the primary makes an exception for that transfer and simply doesn’t do all the verification that would normally be done i.e. the primary assumes that the secondary already did all the public-facing checks and lot of the other processing. In other words, the primary trusts the secondary to have done the job properly on its behalf - which isn’t really a problem because they are both administered by me.
This includes handling spam and scam and SPF and DKIM and … ; and it is somewhat preferable to handle scam and spam in the secondary rather than to keep it on backlog, then transfer it to the primary, then toss it, given that the substantial majority of all email is scam and spam.
Occasionally I see scam and spam senders deliberately sending to the secondary when there would be no reason for that (the primary is not down). Perhaps they are probing for the possibility that the secondary is not as well maintained as the primary (behind in software version, lacks up to date configuration, whatever).