On 2020-10-27 00:01, Mueller Urs SBB CFF FFS wrote:
Thank you guys
well, technically, they (UCEProtect) are correct.
If an IP sends a mail with the From: header indicating a domain for
which an SPF record exists, and the sending IP is not supposed to send
it, then it is a misconfiguration and that IP should not be trying to
send such a mail at all.
If it is trying to send that, it indicates it allows forwarding of mails
From: domains that it should not be transmitting for. It should not be
doing that.
As such, listing it after one such event might be a bit quick, but
technically indeed, that server is misconfigured and allowing relaying
of messages it should not be.
Now of course, such an event can happen easily, e.g. when somebody
configures a forwarding rule and no rewriting happens. And in the day
and age of SPF/DKIM/DMARC/ARC, it again tells you, that such an event
should not happen as the rewrite should have taken place.
Thus in the end UCEprotect is correct: fix the host on the IP that is
sending those mails, as it is sending mails it should not.
Now, when that situation is fixed, then UCEprotect should IMHO be able
to remove the block entry though.
Greets,
Jeroen
--
My colleague just wrote me:
"I got the following reply from the swiss provider that obviously works
closely with UCEprotect that I'd also call a rogue list as of now. This
is the reply after sending them all of your arguments which I thank you
for. They do obviosuly not only not understand the basic problem but
also seem to be more keen on posting bla bla and accusations rather than
arguments that make sense. Here is their text:
SPF wurde etabliert, um Phishingmails und sonstige Formen von Betrug zu
unterbinden. Wenn der Eigentümer einer Domain solch einen SPF Record
setzt, dann gibt er damit automatisch zu verstehen, daß IPs, die nicht
erfasst sind, nicht zum Versand von Mails unter seiner Domain berechtigt
sind. Ein Server, der Mails versendet, die er ganz offensichtlich nicht
versenden darf, beweist, daß er ein gravierendes Sicherheitproblem hat.
Euer Diskussionspartner sollte von daher bei Einlieferungen von Kunden
schlicht und ergreifend auf SPF prüfen, und Mail, die er laut SPF nicht
versenden DARF, von vorne herein nicht annehmen... Dann werden seine
Server auch nicht bei uns geblacklistet. Wenn er technisch dazu nicht in
der Lage sein sollte, kann das nicht unser Problem sein, UCEPROTECT
Server beherrschen das jedenfalls. Statt Ihre und unsere Zeit zu
stehlen, um unsinnige Diskussionen über unsere Policies zu führen, hätte
er auch seinen Kunden kontaktieren, und diesen zur Abänderung oder
Löschung seines SPF Records auffordern können...
Was er aber macht ist ein typisches Lamerverhalten. Statt die Ursache
des Problems zu beheben, versuchen solche Leute das Symptom abzumildern,
und ihr eigenes Versagen anderen in die Schuhe zu schieben. Ja und das
Gejammer und Geschwurbel über uns in irgendwelchen Foren und auch auf
Webseiten geht uns gepflegt dort vorbei, wo die Sonne nicht scheint...
Wir betreiben die UCEPROTECT Listen für unsere weltweit zahlreichen
zufriedenen Anwender... Wenn diese unzufrieden mit den Listen wären,
würde die Listen niemand nutzen, und somit hätten die Gelisteten keinen
Grund zu jammern. Mit ihrem Gejammer überführen sich Gelistete aber
selbst als Lügner.... daß dieser Hoster Euch damit wochenlang belästigt,
statt das Problem direkt auf seinem System abzustellen, oder mit seinem
Kunden zu sprechen, zeigt jedenfalls, wes Geistes Kind er ist... Ich
denke, damit ist alles gesagt..."
My (Urs) opinion, rather rough words, I personally would like to know
the name of that provider, but it’s not me to blame him.
Regards, Urs
*Von:*[email protected] <[email protected]>
*Im Auftrag von *Matthias Leisi
*Gesendet:* Donnerstag, 8. Oktober 2020 22:35
*An:* Markus Wild <[email protected]>
*Cc:* [email protected]
*Betreff:* Re: [swinog] Handling of UCE / RBL while minor misconfigurations
I think Markus misses the main point of the OP. The question of the OP
is not whether SPF is a good or bad idea in general.
The question is whether its reasonable to add a blacklisting entry for
the server IP if you receive a single mail with a non-matching SPF
record (ie, server with IP a.b.c.d not covered by the SPF for foo.com
<http://foo.com>).
My take on this is that this blacklisting behaviour is entirely
unreasonable.
And I agree that it’s questionable why anyone should use a list with
such unreasonable listing practices (apart from their extortion
practices). Unfortunately the burden is first shifted not onto the
admins responsible for such stupid decisions, but on the sending party
who must wade through massive layers of ignorance and denial.
— Matthias
Am 08.10.2020 um 09:14 schrieb Markus Wild <[email protected]
<mailto:[email protected]>>:
Hello Urs,
My take on your problem is the following:
- SPF is bad and breaks mail delivery, don't use it. But, if someone
defines SPF records, and they thus declare they
want to shoot themselves into their feet, by all means, I
encourage to block mails failing SPF, because that's what
domain owners who define SPF records ask for.
- everyone can setup blocking lists defining the oddest criteria for
when an entry gets added. Someone in charge of a
mailserver can decide based on his criteria, and his alone, what
mails he wants to receive and what mail to reject.
He can use whatever resources he wants, including bogus lists such
as uceprotect. But, it would be prudent to inform
yourself about what exactly you enable before you do so...
- now, if someone deploys antispam gateways such as those from
Sophos, and decides to just click "enable all block
lists" or however that menu looks like, and with this enables
lists such as uceprotect, then that person just cut
their company off from a lot of valid mail. If he wanted to do
that, it's his decision, but usually it helps to teach
those admins about the errors of their ways, instead of blaming
the list provider.
- I personally consider uceprotect to be a rogue list with utopian
views on how mail service works. Their unlist policy
could be considered extortion, but the really responsible party is
whoever enables such a list on their servers.
just my personal views:)
Markus
_______________________________________________
swinog mailing list
[email protected] <mailto:[email protected]>
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
<http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog>
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
