Hello Atro,
>
> Having said all of the above, I truly welcome the fact that you have shown
> up here to own up and explain what it is that you are doing and where you
> are coming from with this. It may not make matters any better from the
> perspective of whether anybody's inclined to accept email verification
> attempts, but from my perspective, somebody who shows up in a potentially
> hostile environment such as this deserves some kudos just for doing it.
> We've discussed this offline before and I wanted to say this in public
> too.
>
Thank you very much for your kind words.
I really believe that with transparency and vulnerability, we can be genuinely
in the dialog…
And as always, I really appreciate and respect your perspective and
constructive exchange of thoughts.
This conversation has stimulated me to reflect on our current and potentially
future business model.
Kind Regards
Radek
____________________________________ ______ ___ ___ ___
*Radoslaw Kaczynski*
CEO of Bouncer
usebouncer.com ( https://www.usebouncer.com/ )
ul. Cypriana Kamila Norwida 24/1
50-374 Wrocław, Poland
💙 Become Bouncer’s Ambassador (
https://bouncer.partnerstack.com/?group=ambassadors )
On Mon, Sep 05, 2022 at 21:39:01, Atro Tossavainen < mailop@mailop.org > wrote:
>
>
>
> Czesc, Radek,
>
>
>>
>>
>> We assume that:
>> - our customer (data controller) who requested us to verify the email
>> address got it in a legal way
>> - our customer is obeying anti-spam policies.
>>
>>
>
>
>
> So do all the ESPs. But their customers send mail, and the recipients are
> able to act upon it, informing the ESP of problem clients and sometimes
> even getting traction.
>
>
>
> In the case of email verifiers, there is no message, and there is no email
> recipient to do the same.
>
>
>
> The only people who have any visibility to the efforts of woodpeckers who
> abuse SMTP (EXPN and VRFY were disabled and even removed from mail
> software for a reason) are grumpy mail server admins who have much less
> time than your average spam recipient for this kind of behaviour.
>
>
>
> "Email verification" abusing RCPT TO produces zero benefits in exchange
> for nonzero resource use for the target system owners.
>
>
>
> I had entered " bouncer. cloud ( http://bouncer.cloud/ ) " in my list of
> HELOs to reject offhand a long time before this conversation. Don't worry,
> you're not alone; the list of similar players is dozens of lines long,
> could probably be made shorter by replacing most of the existing rules
> with entries in the regex version of the same, and additionally, some of
> the HELO rejects are redundant now that the networks involved have been
> entered into the firewall drop list, entities who have been kind enough to
> register their own networks such as Mailinblack or Kickbox are no longer
> able to make any connections to our systems at all.
>
>
>>
>>
>> Thank you again for the opportunity to be here - if you are already tired
>> of me - please let me know.
>>
>>
>
>
>
> Having said all of the above, I truly welcome the fact that you have shown
> up here to own up and explain what it is that you are doing and where you
> are coming from with this. It may not make matters any better from the
> perspective of whether anybody's inclined to accept email verification
> attempts, but from my perspective, somebody who shows up in a potentially
> hostile environment such as this deserves some kudos just for doing it.
> We've discussed this offline before and I wanted to say this in public
> too.
>
>
>
> Pozdrawiam, A.
>
>
>
> --
> Atro Tossavainen, Founder, Partner
> Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia
> tel. +372-5883-4269, http:/ / www. koliloks. eu/ ( http://www.koliloks.eu/
> )
> _______________________________________________
> mailop mailing list
> mailop@ mailop. org ( mailop@mailop.org )
> https://list.mailop.org/listinfo/mailop
>
>
>
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
