Mailing List Archive

* Rupert Gallagher:

> Two well known companies in my country persist in making the mistake
> of writing their mid with a non-public fqdn, violating the rfc. [...]
> been so for the past three years, with me sending detailed, manually
> Their answer is that everybody else accepts their invalid mid, and
> their servers are enterprise ibm / microsoft shitware that they are
> unwilling to fix.

RFC 2822 (https://tools.ietf.org/html/rfc2822#section-3.6.4) does not
state that a "public fqdn" (or any FQDN) is required in the message ID.
Formally, the id-right portion can be any dot-atom-text. Also, the
Message-ID header itself is optional, although recommended.

In other words, you are the stubborn one, and wrong to boot. ;-)

-Ralph

On Sat, Aug 1, 2020 at 8:59 AM 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?
>

First, I use Chris Santerre's definition of Spam that spam is about not
having consent rather than the content. If someone sends something with
RFC issues to evade spam detection, that demonstrates a lack of consent and
clear intent. But if it's something with consent, as long as the email can
get from point A to point B, bending the RFCs is fine. I'd equate it to a
kid addressing an envelope to his Granny in crayon, forgetting the zip code
and put the stamp on the wrong corner. The post office can figure it out
automatically and it gets where it's meant to go. By comparison, the big
bad Wolf trying to contact Granny from his jail cell would be spam. The
RFC compliance might be an indicator for me but not a reason to block but
that's my take. If you want to share a sample on pastebin, I can give you
my take on it using the content vs consent litmus test for rules/blocking.

Second, I'm not aware of any ombudsman for RBLs. Many RBLs are run by
distinct organizations and many have unique listing/delisting criteria. An
ombudsman would basically be a consultant spending a lot of time on the
issue so you might just go that route and hire someone.

Finally, there are RBLs you might want to use. There used to be RFC
Ignorant but it appears to be shuttered. Take a look at
http://rfc-clueless.org/

Also if they use the same domain, just locally block it.

Regards,
KAM

They have explicit consent to send rfc compliant e-mail. Rfc-clueless.org seems.a good starting point.

Thank you

-------- Original Message --------
On 1 Aug 2020, 15:53, Kevin A. McGrail < kmcgrail@apache.org> wrote:
On Sat, Aug 1, 2020 at 8:59 AM 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?

First, I use Chris Santerre's definition of Spam that spam is about not having consent rather than the content. If someone sends something with RFC issues to evade spam detection, that demonstrates a lack of consent and clear intent. But if it's something with consent, as long as the email can get from point A to point B, bending the RFCs is fine. I'd equate it to a kid addressing an envelope to his Granny in crayon, forgetting the zip code and put the stamp on the wrong corner. The post office can figure it out automatically and it gets where it's meant to go. By comparison, the big bad Wolf trying to contact Granny from his jail cell would be spam. The RFC compliance might be an indicator for me but not a reason to block but that's my take. If you want to share a sample on pastebin, I can give you my take on it using the content vs consent litmus test for rules/blocking.

Second, I'm not aware of any ombudsman for RBLs. Many RBLs are run by distinct organizations and many have unique listing/delisting criteria. An ombudsman would basically be a consultant spending a lot of time on the issue so you might just go that route and hire someone.

Finally, there are RBLs you might want to use. There used to be RFC Ignorant but it appears to be shuttered. Take a look at http://rfc-clueless.org/

Also if they use the same domain, just locally block it.

Regards,
KAM

* Rupert Gallagher:

> They have explicit consent to send rfc compliant e-mail.

"They" are not violating RFC 2822 with their message IDs, as I already
explained in message <87eeoqfpel.fsf@wedjat.horus-it.com>.

> Rfc-clueless.org seems.a good starting point.

You are the one who misunderstands the relevant section of RFC 2822.
Why would you want to report that to an even wider audience?

-Ralph

On 1 Aug 2020, at 8:58, Rupert Gallagher 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.

As Ralph says, that is not a violation of any RFC. There is no "MUST"
condition in 5322 or its 2 most recent predecessors referencing the use
of or resolvability of a domain in the RHS of a Message-ID. A domain is
RECOMMENDED, but there's no mention of its public resolvability

> 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?

Of course there isn't. If there was someone who could tell DNSBL
operators what addresses to list or not list, there wouldn't be hundreds
of independent DNSBLs.

Also, the idea that RFC compliance is something that can or should be
"enforced" is entirely inconsistent with the basic principles of what
RFCs are. They are documentation, not law.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

On Sat, 01 Aug 2020 18:48:04 +0200
Ralph Seichter wrote:

> * Rupert Gallagher:
>
> > They have explicit consent to send rfc compliant e-mail.
>
> "They" are not violating RFC 2822 with their message IDs, as I already
> explained in message <87eeoqfpel.fsf@wedjat.horus-it.com>.
>
> > Rfc-clueless.org seems.a good starting point.
>
> You are the one who misunderstands the relevant section of RFC 2822.
> Why would you want to report that to an even wider audience?

Not for the first time either:

https://readlist.com/lists/incubator.apache.org/spamassassin-users/20/101951.html

Correction: it is not the mid, it is the helo.

-------- 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?

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

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.

-------- 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

On 02.08.20 13: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.

I don't think there's point in blacklisting hoat that sends fake helo, when
you can block the helo itself.

yes, I think that such helo should be blocked and I block it wherever I can.

>-------- 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.
Enter any 12-digit prime number to continue.

On 8/2/2020 9:18 AM, 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.

If they aren't spending spam, why care about their MID or Helo format
unless there is a delivery issue.

This project exists to stop spam not to weaponize our capabilities to
become the RFC-police.

If the users have consent to receive the mail and the mail is getting to
the right person, I'd recommend you ignore it.

Regards,

KAM

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

To ignore it, as you say, I would have to remove the postfix check, write rules to implement a non-blocking check, then write rules to implement the rejection except for whitelisted domains. It is a lot of work, to allow a bank and an accounting firm to violate an industry standard, and still have the doubt on the authenticity of their e-mails. No thank you.

-------- Original Message --------
On 2 Aug 2020, 15:54, Kevin A. McGrail < kmcgrail@apache.org> wrote:
On 8/2/2020 9:18 AM, 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.
If they aren't spending spam, why care about their MID or Helo format
unless there is a delivery issue.
This project exists to stop spam not to weaponize our capabilities to
become the RFC-police.
If the users have consent to receive the mail and the mail is getting to
the right person, I'd recommend you ignore it.
Regards,
KAM
--
Kevin A. McGrail
KMcGrail@Apache.org
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

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)

On 2 Aug 2020, at 10:07, Rupert Gallagher wrote:

> To ignore it, as you say, I would have to remove the postfix check,
> write rules to implement a non-blocking check, then write rules to
> implement the rejection except for whitelisted domains.

OR, in the language of Postfix configuration:

smtpd_helo_required = yes
smtpd_helo_restrictions = check_helo_access pcre:badheloallowed,
reject_unknown_helo_hostname, reject_non_fqdn_helo_hostname

And put entries into $config_directory/badheloallowed like this:

/localhost/ PERMIT
/invalid_hostname/ PERMIT
/unresolvable.rbs.co.uk/ PERMIT
/mailhost.sc.com/ PERMIT

> It is a lot of work,

I just did it for you, for free. The hardest "work" was looking up a
couple of bank domains for examples.

> to allow a bank and an accounting firm to violate an industry
> standard, and still have the doubt on the authenticity of their
> e-mails. No thank you.

If you want to authenticate email, it needs to use some form of internal
authentication such as DKIM, S/MIME or OpenPGP. Trusting the
authenticity of email simply because it comes from a machine which uses
a resolvable HELO in a particular domain is a naive approach unless you
are *AT LEAST* using a DNS resolver that demands authenticated answers,
i.e. requires DNSSEC, treating non-DNSSEC replies as meaningless.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

* RW:

> https://readlist.com/lists/incubator.apache.org/spamassassin-users/20/101951.html

Oh my, I was not aware of that. Looks like Rupert has nurtured his pet
peeve for at least three years. Thats a long time of being stubbornly
wrong.

-Ralph

* Rupert Gallagher:

> Correction: it is not the mid, it is the helo.

/me snorts

But of course it is. :-D After I have just read your ramblings in a
2017 mailing list thread [1], in which you made the same nonsense
remarks about message IDs, why would I doubt you?

[1] https://readlist.com/lists/incubator.apache.org/spamassassin-users/20/101931.html

-Ralph

* Rupert Gallagher:

> They will procrastinate until the end of time unless we do something.

"We"? You are trying to drag others into your fight against
windmills. No thanks.

> 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.

Who died and made you the enforcer of email purity? Block locally if you
must, silly as it is in the case of a bank, but don't presume to be the
deciding factor on what others accept.

-Ralph

* Bill Cole:

> Trusting the authenticity of email simply because it comes from a
> machine which uses a resolvable HELO in a particular domain is a naive
> approach unless you are *AT LEAST* using a DNS resolver that demands
> authenticated answers, i.e. requires DNSSEC [...]

Agreed, but I'd go one step further and call it dangerous instead of
just naive. Anything short of a verifiable, cryptographic signature
cannot be relied on when it comes to email authenticity. DNSSEC does not
provide protection against rogue email being sent from an organisation's
servers.

-Ralph

-------- Original Message --------
On 2 Aug 2020, 17:02, Bill Cole < sausers-20150205@billmail.scconsult.com> wrote:

> smtpd_helo_restrictions

Good idea. Thank you.

-------- Original Message --------
On 2 Aug 2020, 17:02, Bill Cole < sausers-20150205@billmail.scconsult.com> wrote:

> if you want to authenticate email, ...

The helo is a necessary, but not sufficient criteria for authentication. I use them all, up to dane. However, they all fail with those two senders, because they do not implement them, and they send mail from an IP whose rDNS is that of the ISP. Authenticating the source in this case reduces to cheching the sending IP against those from known valid e-mails, as well all rfc compliance as evidence of some degree of home work from their side. I am talking about a bank and an accountancy firm, and I resent having to do this.

On 02 Aug 2020, at 07:54, Kevin A. McGrail <kmcgrail@apache.org> wrote:
> If they aren't spending spam, why care about their MID or Helo format
> unless there is a delivery issue.

If they are sending mail with an invalid helo then it is perfectly valid to drop the connections. This may be a problem when you want to use this as an obvious spam fighting measure, but clueless gits misconfigure their mail servers and you then have to punch a hole through your perfectly reasonable anti-spam policy just to serve their cluelessness so that people get mail they want to get.

Every time you make your front-line defense weaker you increase the amount of spam you have to deal with to a great degree. Having to do this for someone is just incompetent is aggravating and expensive.

But, as always, you have to balance your aggravation against receiving the mail that the accounts on your server want to receive, and no one can measure that but the receiving mail server.

--
I gotta call my glitter guy

The domains turn out to be already in the rfc-clueless.org database since 2014.

-------- 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?

Rupert Gallagher skrev den 2020-08-03 16:10:
> The domains turn out to be already in the rfc-clueless.org database
> since 2014.

feel free to add it to spamassassin then

sadly 99% false possitives :/

>Rupert Gallagher skrev den 2020-08-03 16:10:
>>The domains turn out to be already in the rfc-clueless.org database
>>since 2014.

On 04.08.20 02:32, Benny Pedersen wrote:
>feel free to add it to spamassassin then
>
>sadly 99% false possitives :/

do you mean, 99% of listings are incorrect?
Or just that 99% of hits are ham?

--
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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."