[asterisk-dev] Mailing List Future

[Paul Kudla]

ok dont know where all of this is comming from

not using mailman etc, just stating the facts of smtp email and esmtp 
email as per the startdards that are being applied today.

Email is very straight forward and is pretty much limited 
source<>destination. Anything trying to alter that gets

i guess at this point if i get the mail list emails great, if dont i 
will deal with it when i need to, I was just passing on practical 
experience, I wont start quoting RFC's because google and microsoft for 
example break most of them anyways.

I am just trying to give back to the community ?


Have A Happy Friday !!!

Thanks - Paul Kudla (Manager SCOM.CA Internet Services Inc.)


Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email paul at scom.ca

On 1/5/2024 6:58 AM, asterisk at phreaknet.org wrote:
> 
> 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.
>