AS16019, vodafone.cz == idiots
Some days I am inclined to wonder how or why anything at all actually works on this planet. I suspect that I am not alone, given that Covid-19 has now exposed for all the world to see just how inept and dysfunctional even so-called "first world" systems are at dealing with anything that is even just a little bit out of the ordinary. Another case in point: AS16019 aka vodafone.cz, whose formally declared abuse reporting address, as given in the WHOIS record for the ASN, is abuse@vodafone.cz. Unfortunately, if you send a copy of a spam that you have received from their network to that address, you will get back something that may look vaguely like this: <spamrd@vf.dkm.cz>: host mail2.dkm.cz[62.24.64.36] said: 550 5.7.1 <spamrd@vf.dkm.cz>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=rfg%40tristatelogic.com;ip=80.95.99.97... So, the retorical question for the day is: Just how completely idiotic does any given group of network operators have to be in order to be unable to just simply operate a functioning email address for inbound messages? I guess Vodafone is either too broke or too cheap to hire merely competent people. It would be one thing if this was an impoverished third-world country involved here, but it isn't. It's the Czech Republic. So what is their excuse for this level of sheer incompetence? Does someone need to send a formal memo to Vodafone, explaining to them about this thing called spam? And why are they even leaving port 25 outbound open on end-luser lines? Regards, rfg
Ronald, my two cents on this:
http://www.openspf.net/Why?s=mfrom;id=rfg%40tristatelogic.com;ip=80.95.99.97...
There are many SMTP relays in the world checking SPF record for the incoming mail and providing a diagnostics with openspf.net web. But unfortunately this website is down for almost two years and this diagnostics leads to nowhere. If someone is running a mail relay, then now is a good time to check its responses. -- Kind regards, Sergey Myasoedov
On 12 Dec 2020, at 11:36, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
Some days I am inclined to wonder how or why anything at all actually works on this planet. I suspect that I am not alone, given that Covid-19 has now exposed for all the world to see just how inept and dysfunctional even so-called "first world" systems are at dealing with anything that is even just a little bit out of the ordinary.
Another case in point: AS16019 aka vodafone.cz, whose formally declared abuse reporting address, as given in the WHOIS record for the ASN, is abuse@vodafone.cz. Unfortunately, if you send a copy of a spam that you have received from their network to that address, you will get back something that may look vaguely like this:
<spamrd@vf.dkm.cz>: host mail2.dkm.cz[62.24.64.36] said: 550 5.7.1 <spamrd@vf.dkm.cz>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=rfg%40tristatelogic.com;ip=80.95.99.97...
So, the retorical question for the day is: Just how completely idiotic does any given group of network operators have to be in order to be unable to just simply operate a functioning email address for inbound messages?
I guess Vodafone is either too broke or too cheap to hire merely competent people.
It would be one thing if this was an impoverished third-world country involved here, but it isn't. It's the Czech Republic. So what is their excuse for this level of sheer incompetence?
Does someone need to send a formal memo to Vodafone, explaining to them about this thing called spam?
And why are they even leaving port 25 outbound open on end-luser lines?
Regards, rfg
In message <83900D1F-3EB8-4D72-8A8E-2086BCD0D4AB@devnull.ru>, Sergey Myasoedov <sergey@devnull.ru> wrote:
my two cents on this: http://www.openspf.net/Why?s=3Dmfrom;id=3Drfg%40tristatelogic.com;ip=3D80.= 95.99.97;r=3Dmail2.dkm.cz
There are many SMTP relays in the world checking SPF record for the incoming mail and providing a diagnostics with openspf.net web.
That would be fine, BUT... there isn't a goddamn single thing wrong with my domain's SPF record. The brain damage is on THEIR END. Apparently they don't even know how to check SPF TXT properly.
But unfortunately this website is down for almost two years and this diagnostics leads to nowhere.
Yea, there's that also. Basically, it is stupid layered on top of stupid. It's a stupid sandwich. Regards, rfg
They shot themselves in the foot. The email was sent to abuse@vodafone.cz It apparently forwards on to spamrd@vf.dkm.cz and this forwarding breaks SPF, and domains with strict -all SPF records like RFG's tristatelogic.com will fail SPF validation. I guess it is an interesting way to cut down on abuse, as measured by reducing traffic to your abuse mailbox. --srs On 12/12/20, 6:49 PM, "anti-abuse-wg on behalf of Ronald F. Guilmette" <anti-abuse-wg-bounces@ripe.net on behalf of rfg@tristatelogic.com> wrote: In message <83900D1F-3EB8-4D72-8A8E-2086BCD0D4AB@devnull.ru>, Sergey Myasoedov <sergey@devnull.ru> wrote: >my two cents on this: >http://www.openspf.net/Why?s=3Dmfrom;id=3Drfg%40tristatelogic.com;ip=3D80.= >95.99.97;r=3Dmail2.dkm.cz > >There are many SMTP relays in the world checking SPF record for the >incoming mail and providing a diagnostics with openspf.net web. That would be fine, BUT... there isn't a goddamn single thing wrong with my domain's SPF record. The brain damage is on THEIR END. Apparently they don't even know how to check SPF TXT properly. >But unfortunately this website is down for almost two years and this >diagnostics leads to nowhere. Yea, there's that also. Basically, it is stupid layered on top of stupid. It's a stupid sandwich. Regards, rfg
Hej, lör 2020-12-12 klockan 02:36 -0800 skrev Ronald F. Guilmette:
how inept and dysfunctional even so-called "first world" systems are at dealing with anything that is even just a little bit out of the ordinary.
You're referring to your wording in the subject, aren't you? Cheers, Alexander -- Alexander Talos-Zens IT-Security - ACOnet-CERT Zentraler Informatikdienst http://zid.univie.ac.at Universität Wien Universitätsstraße 7 1010 Wien T +43-1-4277-14351 at@univie.ac.at GPG-Key-Id: 0x757A494B
participants (4)
-
Alexander Talos-Zens -
Ronald F. Guilmette -
Sergey Myasoedov -
Suresh Ramasubramanian