On Mon, Feb 19, 2024 at 02:38:03PM -0500, Bill Cole wrote:
> On 2024-02-18 at 18:40:45 UTC-0500 (Mon, 19 Feb 2024 00:40:45 +0100)
> Matija Nalis <mnalis-sa-l...@voyager.hr> is rumored to have said:
> > - Firsty: yes, I'm fully aware of all issues associated with
> > https://en.wikipedia.org/wiki/Callout_verification
>
> Which is why SA does not support such so-called verification in any way. It
> never will as long as I'm a contributor.
It's fine, really. No need to get all upset :)
> > - I'm not looking for debate about general usefulness of Callout
> > verification (and the system for which it is being investigated is
> > not general-purpose e-mail system).
>
> This is a bit like saying you don't want to debate the general
> usefulness of spamming. And then going on to ask about ways to
> spam.
It's more like saying when one has a question about using SA, they
might not want engaging in a debate about why SA is written in perl
instead of in rust (even though the advantages of rust are obvious).
Or if they ask advice how to use SPF plugin, they might not want to
waste time discussing shortcomings of SPF as a technology.
Anyway, idea was to reduce spam, not promote it, so your comparison
sounds a little too negative :(
(Also, there is generally no need to discuss usefullness of spamming:
it is obviously profitable or people wouldn't be doing it)
> I do not care about why you are trying to use SMTP callback
> verification,
Just as well, as I'm not particularly inclined to waste significantly
more time trying to explain the details, especially if they've put
wall before themselves ("never will...")
> because it is a fundamentally broken concept.
Yes, it is broken to a certain extent. But to be fair, whole SMTP
itself is based on fundamentally broken concepts, don't you agree?
And most of SMTP workarounds are fundamentally broken too in many
ways. SPF is broken. RBLs are definitely way too broken. Pattern
matching is quite broken. Bayes is broken. etc.
That is IMHO why SA (still) exists at all -- each of the attempts of
fixing the broken SMTP is also broken (to some higher or lower
extent), so SA requires that *multiple* broken technologies become
*broken at the same time on the same email* before if produces false
positive (yet, both false positives and false negatives still happen
from time to time. Because all of it is broken, and we do not live in
perfect world).
> If it looks like a solution to you, you are refusing to look at
> solving your real problem.
Real problem is of course that e-mail is still the only universal
widespread communication technology which has not been silo-ed away
by megacoorps (yet; although they are working hard on that), and that
people are refusing to *universally* implement DKIM (or some other
sender authentication scheme) worldwide in my lifetime. And yes, in
this one (of hundreds others) use case it does look like improvement
to me (not a solution though - there is no "solution" for e-mail
except perhaps not using it at all).
> All set then. SA is not the right tool for you.
But it is. Although, this question was not for me.
Anyway, unless somebody else has seen something like that, I think
I'll just leave their postfix doing all-or-nothing mail rejection
based on callout verification during SMTP phase; instead of trying to
improve it by just assigning SA score based on it (and doing it on
much reduced number of cases).
(but just because I have other more important things to do at the
moment then dive into writing custom SA plugin; and not because doing
it in SA would not actually improve situation for everyone involved
in this particular case)
--
Opinions above are GNU-copylefted.
