[asterisk-dev] Mailing List Future

[asterisk at phreaknet.org]

On 1/5/2024 3:58 AM, Paul Kudla wrote:
>
> again just trying to help
>
> when i signed up for the new mailing list
>
> see headers below,
>
> a few things to note, return address & from address needs to match, 
> this is a common spam filter which is enabled on my email server.

No, they don't need to match. That is not how email or SMTP work. Your 
spam filter is nonsensical.
In fact, for lists the return path (MAIL FROM) SHOULD NOT match the from 
address, ever. That is how VERP works. If they did, bounces would go to 
the sender, not the list software.
mailman is ancient, that's probably why it was "fine" for you, it wasn't 
doing any of this properly. It wasn't fine for many other people, 
resulting in messages going to spam. Your setup is backwards.

Your spam filters may be effective for you but they are not in line with 
reality and it's not fair to expect the rest of the world to conform to 
these expectations.

> You have no idea how many emails come in saying from "Paul Kudla 
> <groups.io>"
This is not the full address.
If the from header uses a groups.io domain, it's because your domain has 
DMARC enabled. This is correct.
> for example which my server picks up as a bad email address before 
> delivery. (Because Paul Kudla is paul at scom.ca ?)

?? There's no reason you can't send mail from multiple email addresses.

> Reply-to carries the same issues which is why they are ignored coming 
> through the system.

Again, there is no expectation they should match. Reply-To is not a 
header that you should be checking for spam purposes. Anyone could set 
that for any reason. If you're checking it, you're on your own.
FWIW, the group owner can change Reply To to be "list AND sender" rather 
than just "list". Many lists I'm on and my own are set up this way for 
several reasons. Maybe that would help your situation?

> on other notes postfix is programmed for FQDN and reverse ip looks etc 
> that must match the sending smtp serve sending the emails. Sincce 
> stuff is showing up that does not appear to be an issue but thought i 
> should mention that.
>
> also note i and no one else opens an entire domain like groups.io or 
> any other domain(s)
>
> it would be like allowing all email from *@gmail.com
>
> just not practical.
>
> scom.ca is a small provider compared to others but over 80% of my 
> email server traffic is spam, hacks etc and programming is in place to 
> prevent anything from wrecking a customers account (viruses, 
> blacklisted ip's etc) - this is what prompted the SPAMCOP.NET issue as 
> it is one for the dnsbl lookups on my postfix server. 

I also run my own mail servers, and my experience is most DNSBL's have 
lots of false positives. You have to take them with a grain of salt.
I don't use postfix anymore, but if you haven't already, there are 
simple things you can enable to deflect most spam pre-delivery, like 
pregreet detection, FcRDNS checks, tarpitting, greylisting, etc.
Past that, you should just allow it in, run a spam filter like 
SpamAssassin, and let the user deal with it. I always hated mail 
providers that thought they knew better than I did when it came to 
handling spam.

> I had access to the log files so was able to track that down, but 
> another question it seems if email bounces back to groups.io do you 
> get a report ? - a lot of email servers like microsoft do not report 
> bouncebacks thus making it hard to trace issues upon setup.

groups.io does notify the group owner when a bounce results in a 
removal. I've received one of these that I can remember in the past 
several years.

> I know you are restricted by the groups.io and apparently this is a 
> free account, which is why i suggested if groups.io can interface to 
> an external email server or at least an external out smtp server that 
> is programmed with all the correct setups (spf,dkim,ssl etc etc)
>
> it seems you need to be in more control of the outbound email side.
>
> inbound emails could still be received by the groups.io server on the 
> mx record side ?
>
> just a thought out load as I am not fimiliar with groups.io setup up 
> until now. It seems a lot of assumptions are being made (aka willy 
> nilly sending emails without proper formats?) because groups.io is 
> doing things on your behalf.

As far as I am aware, they are doing things correctly. You simply need 
to adjust your expectations with the reality of how email works and what 
the "proper format" is. Point out something in an RFC that is being 
violated.