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 < [email protected]>
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 < [email protected]> 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, [email protected] ; 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
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
