On 2 Aug 2020, at 9:18, Rupert Gallagher wrote:
> They will procrastinate until the end of time unless we do something.
> I tried hard, but they are lazy/ignorant/careless. Blacklisting would
> trigger a problem with most of their customers, then they will try to
> de-list at first, then they will comply when de-listing is rejected.
In what way does this relate to SpamAssassin?
You are free to block based on a non-resolving HELO domain or even a
non-resolving M-ID domain, and you can use SA to do so. The mechanisms
are documented. I'm sure you can get help here if the documentation
isn't clear to you. For the HELO domain that is most efficiently done in
your MTA and as Matus says: if you're using Postfix you can do that with
the various reject_*_helo_hostname restrictions, depending on what sort
of strictures you want to use. You can even lie to yourself about that
being an "enforcement" of some RFC, even though no RFC blesses the
rejection of mail based on any characteristic of the HELO domain or says
that it MUST resolve. A non-resolving HELO name may or may not correlate
to mail being spam, and if you can establish that correlation and define
it in SA rules I'm sure we would all like to know that and I would be
happy to test such rules in the project's RuleQA system.
If you want to recruit DNSBL operators to your point of view, this is
not a reasonable forum for that campaign. They are mostly not here. If
you want to recruit mail admins to your point of view, this is not a
reasonable forum for that campaign. They are also mostly not here, even
the ones who are consciously using SpamAssassin.
If there's no correlation of your pet HELO domain rules to whether or
not email is spam then you will have a very hard time recruiting anyone
to join your campaign by blocking mail, no matter where you find a
suitable audience for that evangelism.
> -------- Original Message --------
> On 2 Aug 2020, 12:30, Matus UHLAR - fantomas < uhlar@fantomas.sk>
> wrote:
> On 02.08.20 05:11, Rupert Gallagher wrote:
>> Correction: it is not the mid, it is the helo.
> oh... this is something quite different.
> But unless multiple servers start implementing
> reject_unknown_helo_hostname,
> such companies ignore to change that...
> ... apparently with possibly reject_non_fqdn_elo_hostname and
> reject_invalid_helo_hostname. and smtpd_helo_required=yes of course
>> -------- Original Message --------
>> On 1 Aug 2020, 14:58, Rupert Gallagher < ruga@protonmail.com> wrote:
>> Two well known companies in my country persist in making the mistake
>> of writing their mid with a non-public fqdn, violating the rfc. It
>> has been so for the past three years, with me sending detailed,
>> manually written error messages to their painstakingly collected
>> admin addresses. Their answer is that everybody else accepts their
>> invalid mid, and their servers are enterprise ibm / microsoft
>> shitware that they are unwilling to fix. Since we get a lot of their
>> emails, I decided to scale up their problem. There are many
>> blacklists, and I have no intention to go through each idiosyncratic
>> procedure.
>>
>> Is there an ombusdman that superintends the major blacklists and
>> enforces rfc compliance through them?
> --
> Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)