Re: [mailop] SMTP noise from *.bouncer.cloud

[Laura Atkins via mailop]

> On 7 Sep 2022, at 13:08, Radek Kaczynski (Radek from Bouncer) via mailop 
>  wrote:
> 
> 
> 
> I think that destroying all email verifiers is not going to be the solution 
> to the problem.
> I think that:
> - when spam filters block based on bounce rates
> - decent senders should have to have ways of verifying email addresses.

They do, it’s called “confirmed opt-in”. This means that you’re actually 
confirming that the person who receives the email is the same person that gave 
you the email address and they do want to receive mail from you. 

> 
> Among our customers, we have for example:
> - governmental institutions of Ghana - every adult joining workforce of Ghana 
> register their email address in the governmental system, which in order to 
> improve data quality - uses Bouncer, at the moment of entry,

How are you confirming that the adult is the same person that receives the 
email? ie, what happens if someone inside Ghana gives you my email address? Is 
the government of Ghana going to send me PII for that person?

> - big humanitarian organizations that have dirty databases of their 
> supporters (as captured in various error-prone situations),

Again, why are you assuming that the only errors that make it into the 
databases are ones that make the email addresses bounce? 

> - governments and parliaments of European countries.

> We have not been reaching out to them, we did no advertisements - they found 
> us (and it was not easy task, cause we suck at SEO), cause they had problems.
> 
> Email community while fighting spam is also affecting decent senders, who 
> have no choice but to seek some solution.

Address verification … isn’t the solution. 

> I believe the change is needed, and I'm afraid that destroying email 
> verifiers will not solve the problem - it will just create a void, with the 
> risk that an even worse solution will be created by some "innovative 
> entrepreneurs".

There are a lot of people (both on and off the list) that have spent literal 
decades fighting email abuse. I don’t think your comment here is as insightful 
or awe inspiring as you think it is. 

> Exactly as it happened with VRFY decommissioning… it just created a void… and 
> I think that none of our predecessors, had in mind helping spammers.

One of the reasons VRFY was decommissioned by so many receiving mail systems 
was because it was being used to harvest email addresses. And when it was 
decommissioned the spammers just moved to using partial SMTP transactions, just 
like you are doing. Your predecessors WERE spammers, not just people taking 
money from them. 

> I myself from time to time am contemplating what could be done to improve the 
> situation holistically - but I'm not as skilled and experienced in email as 
> you all are - have been in this "business only 5 years".

Maybe, then, you might think about listening to people who’ve been doing this 
for 4 or 5 times as long as you have. Rather than just being a jerk and 
explaining to us that ‘we don’t understand’ the complexities of email, running 
a business or that these issues need to be addressed holistically. 

> I've been thinking about incorporating blockchain technology and maybe smart 
> contracts to make sure that the sender has the right to send to the 
> recipient. But designing such a model would be super complex, cause it would 
> have to be equal, and not available to the privileged.

You might want to look up “microsoft” “anti-spam” and “hash cash”.

> It's very complex… and I guess over my capabilities. But maybe some of you, 
> or you together will figure out some real solution to the problem.
> And maybe we could, instead of putting our time, energy and talent in 
> fighting email verifiers, put it into creating new quality, that will solve 
> the problem.

Wow. 

laura 

> 
> Kind Regards
> Radek
> 
> 
> 
> 
> ___
>   
> Radoslaw Kaczynski
> CEO of Bouncer
> usebouncer.com 
> ul. Cypriana Kamila Norwida 24/1
> 50-374 Wrocław, Poland
>  Become Bouncer’s Ambassador 
> 
> 
> 
> On Wed, Sep 07, 2022 at 10:13:28, Slavko  > wrote:
> Dňa 7. 9. o 9:44 Radek Kaczynski (Radek from Bouncer) via mailop napísal(a):
> 
> Here I meant - if you as Mail Operator, do not want Bouncer to verify email 
> addresses hosted by you - please let me know and we will put a rule in our 
> configuration.
> 
> Do you really think, that email operators have nothing better to work as 
> contact every one, who decide to use their service for own business? And for 
> any new domain do that again and again? Adding to local BL is much more 
> simple, provides the same results and -- can be automated.
> 
> I hope, that soon or latter here will be DNSRBL with those "services", IMO 
> Spamhaus SBL starts with something similar recently (while not exactly 
> washers, it is good start).
> 
> regards
> 
>

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski (Radek from Bouncer) via mailop]

Hello Slavko,

> 
> Do you really think, that email operators have nothing better to work as
> contact every one, who decide to use their service for own business? And
> for any new domain do that again and again? Adding to local BL is much
> more simple, provides the same results and -- can be automated.
> 

Certainly - whichever is easier for you. I thought that in case of us managed 
the "do not verify" list - there would be no traffic flying; thus it would have 
a much lower footprint.

And on top of that, you would not have to invest your time into configuring 
your BL, but of course, sometimes it's easier to manage BL than send an email.

> 
> I hope, that soon or latter here will be DNSRBL with those "services", IMO
> Spamhaus SBL starts with something similar recently (while not exactly
> washers, it is good start).
> 

I'm afraid it won't be a solution to the problem :(

Probably mostly small naive and transparent email verifiers (like us) would be 
included on this list - those that are easy to catch. As we use only one domain 
( bouncer.cloud ( http://bouncer.cloud/ ) ; yes we are right now removing other 
old ones, that not really operational) - it will be indeed super easy to add us 
on the DNSRBL.

But our 10x bigger competitors will be just rotating cheap domains and will 
survive anyway.

I think that destroying all email verifiers is not going to be the solution to 
the problem.

I think that:

- when spam filters block based on bounce rates,

- decent senders should have to have ways of verifying email addresses.

Among our customers, we have for example:

- governmental institutions of Ghana - every adult joining workforce of Ghana 
register their email address in the governmental system, which in order to 
improve data quality - uses Bouncer, at the moment of entry,

- big humanitarian organizations that have dirty databases of their supporters 
(as captured in various error-prone situations),

- governments and parliaments of European countries.

We have not been reaching out to them, we did no advertisements - they found us 
(and it was not easy task, cause we suck at SEO), cause they had problems.

Email community while fighting spam is also affecting decent senders, who have 
no choice but to seek some solution.

I believe the change is needed, and I'm afraid that destroying email verifiers 
will not solve the problem - it will just create a void, with the risk that an 
even worse solution will be created by some "innovative entrepreneurs".

Exactly as it happened with VRFY decommissioning… it just created a void… and I 
think that none of our predecessors, had in mind helping spammers.

I myself from time to time am contemplating what could be done to improve the 
situation holistically - but I'm not as skilled and experienced in email as you 
all are - have been in this "business only 5 years".

I've been thinking about incorporating blockchain technology and maybe smart 
contracts to make sure that the sender has the right to send to the recipient. 
But designing such a model would be super complex, cause it would have to be 
equal, and not available to the privileged.

It's very complex… and I guess over my capabilities. But maybe some of you, or 
you together will figure out some real solution to the problem.

And maybe we could, instead of putting our time, energy and talent in fighting 
email verifiers, put it into creating new quality, that will solve the problem.

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 Wed, Sep 07, 2022 at 10:13:28, Slavko < mailop@mailop.org > wrote:

> 
> 
> 
> Dňa 7. 9. o 9:44 Radek Kaczynski (Radek from Bouncer) via mailop
> napísal(a):
> 
> 
>> 
>> 
>> Here I meant - if you as Mail Operator, do not want Bouncer to verify
>> email addresses hosted by you - please let me know and we will put a rule
>> in our configuration.
>> 
>> 
> 
> 
> 
> Do you really think, that email operators have nothing better to work as
> contact every one, who decide to use their service for own business? And
> for any new domain do that again and again? Adding to local BL is much
> more simple, provides the same results and -- can be automated.
> 
> 
> 
> I hope, that soon or latter here will be DNSRBL with those "services", IMO
> Spamhaus SBL starts with something similar recently (while not exactly
> washers, it is good start).
> 
> 
> 
> regards
> 
> 
> 
> --
> Slavko
> ___
> 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

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski (Radek from Bouncer) via mailop]

Hello John,

I'm afraid that the suggested price is too high for us; thus we'll be happy 
stay away from your servers.

Please send me the list of the domains which you manage, and we will stop 
processing email verification for them - and we we will be returning the 
"unknown" status to our customers.

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 Wed, Sep 07, 2022 at 11:04:40, John Levine < jo...@taugh.com > wrote:

> 
> 
> 
> It appears that Radek Kaczynski via mailop < radek@ usebouncer. com (
> ra...@usebouncer.com ) > said:
> 
> 
>> 
>> 
>> I don't think that.
>> Honestly, I hate that we are using YOUR resources without compensating
>> you.
>> 
>> 
>> 
>> As I wrote before, I'd love to pay. I initially thought about paying a
>> quota for using VRFY.
>> 
>> 
>> 
>> But if it would be hard to implement - I'd love to pay for the requests.
>> 
>> 
> 
> 
> 
> Great. You can verify addresses of my mail users for $1000 per address.
> Write for wire transfer instructions.
> 
> 
> 
> If you don't think it's worth $1000/address, then stay away from my
> servers.
> 
> 
> 
> R's,
> John
> --
> Regards,
> John Levine, johnl@ taugh. com ( jo...@taugh.com ) , Primary Perpetrator of
> "The Internet for Dummies", Please consider the environment before reading
> this e-mail. https:/ / jl. ly ( https://jl.ly/ )
> 
> 
>___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[John Levine via mailop]

It appears that Radek Kaczynski via mailop  said:
>I don't think that.
>Honestly, I hate that we are using YOUR resources without compensating you.
>
>As I wrote before, I'd love to pay. I initially thought about paying a quota 
>for using VRFY.
>
>But if it would be hard to implement - I'd love to pay for the requests.

Great.  You can verify addresses of my mail users for $1000 per address.  Write
for wire transfer instructions.

If you don't think it's worth $1000/address, then stay away from my servers.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Slavko via mailop]

Dňa 7. 9. o 9:44 Radek Kaczynski (Radek from Bouncer) via mailop napísal(a):


Here I meant - if you as Mail Operator, do not want Bouncer to verify email 
addresses hosted by you - please let me know and we will put a rule in our 
configuration.


Do you really think, that email operators have nothing better to work as 
contact every one, who decide to use their service for own business? And 
for any new domain do that again and again? Adding to local BL is much 
more simple, provides the same results and -- can be automated.


I hope, that soon or latter here will be DNSRBL with those "services", 
IMO Spamhaus SBL starts with something similar recently (while not 
exactly washers, it is good start).


regards

--
Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski (Radek from Bouncer) via mailop]

Hi Hal,

> 
> Many marketing people just don't get it when it comes to spam. They can
> always come up with some way to rationalize that their spam isn't spam. I
> wonder if it is genetic.
> 

That's why we try to educate marketing folks (we will be running a series of 
articles, and webinars this fall to educate a bit)… I know it's not much, but 
at least they will be exposed to some perspective about respect in email… after 
coming to the email verifier.

I don't think it's genetic… I think it depends on the culture, environment, and 
also circumstances, but I did notice a geographical correlation:

- growing economies (with less capital for customer acquisition),

- U.S. marketers, with a sales culture of hustling and less respect for data 
privacy.

> 
> Vernon Schryver has a wonderful list:
> Spam is That Which We Don't Do
> https:/ / www. rhyolite. com/ anti-spam/ that-which-we-dont. html (
> https://www.rhyolite.com/anti-spam/that-which-we-dont.html )

That's a good one!

> 
> 
> 
> There is a wide range of spam -- from crooks and Viagra to people who
> don't know better. There are also lots of people who do know better, but
> try to push the limits a bit, or push too hard and try to talk their way
> out of it.
> 
> 
> 
> 
> There is also a wide range of email marketing consultants. Some sell lists
> and spamming services. Some will encourage confirmed opt-in. Some would be
> happy to hire somebody else to do the dirty work of cleaning their lists.
> 
> 
> 

Truth to that!

I believe that people, in general, are good, but evil/immoral behaviors are 
usually caused by circumstances… though I'm not really good at philosophy.

> 
> 
>> 
>> 
>> - if you don't want us to verify your email addresses - please let us know
>> and we will consider them as blocked (no need even to spend your time on
>> feeding the firewall or block list),
>> 
>> 
>> 
> 
> 
> 
> That's opt-out.
> 
> 
> 

Here I meant - if you as Mail Operator, do not want Bouncer to verify email 
addresses hosted by you - please let me know and we will put a rule in our 
configuration.

For domains, you will provide we will be returning an "unknown" status and will 
not connect to your servers at all.

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 Wed, Sep 07, 2022 at 04:16:18, Hal Murray < halmurray+mai...@sonic.net > 
wrote:

> 
> 
> 
> radek@ usebouncer. com ( ra...@usebouncer.com ) said:
> 
> 
>> 
>> 
>> - marketing teams coming to us from Marketing SaaSs, who, during customer
>> onboarding, notice that the quality of email lists is low and send their
>> customers to us to clean it first.
>> 
>> 
> 
> 
> 
> My alarm bells went off on one of your first messages when you said little
> guys need to spam because otherwise they couldn't compete with the big
> guys.
> 
> 
> 
> Many marketing people just don't get it when it comes to spam. They can
> always come up with some way to rationalize that their spam isn't spam. I
> wonder if it is genetic.
> 
> 
> 
> Vernon Schryver has a wonderful list:
> Spam is That Which We Don't Do
> https:/ / www. rhyolite. com/ anti-spam/ that-which-we-dont. html (
> https://www.rhyolite.com/anti-spam/that-which-we-dont.html )
> 
> 
> 
> There is a wide range of spam -- from crooks and Viagra to people who
> don't know better. There are also lots of people who do know better, but
> try to push the limits a bit, or push too hard and try to talk their way
> out of it.
> 
> 
> 
> There is also a wide range of email marketing consultants. Some sell lists
> and spamming services. Some will encourage confirmed opt-in. Some would be
> happy to hire somebody else to do the dirty work of cleaning their lists.
> 
> 
> 
> ---
> 
> 
>> 
>> 
>> - if you don't want us to verify your email addresses - please let us know
>> and we will consider them as blocked (no need even to spend your time on
>> feeding the firewall or block list),
>> 
>> 
> 
> 
> 
> That's opt-out.
> 
> 
> 
> --
> These are my opinions. I hate spam.
> 
> 
>___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Hal Murray via mailop]

ra...@usebouncer.com said:
> - marketing teams coming to us from Marketing SaaSs, who, during customer
> onboarding, notice that the quality of email lists is low and send their
> customers to us to clean it first. 

My alarm bells went off on one of your first messages when you said little 
guys need to spam because otherwise they couldn't compete with the big guys.

Many marketing people just don't get it when it comes to spam.  They can 
always come up with some way to rationalize that their spam isn't spam.  I 
wonder if it is genetic.

Vernon Schryver has a wonderful list:
  Spam is That Which We Don't Do
  https://www.rhyolite.com/anti-spam/that-which-we-dont.html

There is a wide range of spam -- from crooks and Viagra to people who don't 
know better.  There are also lots of people who do know better, but try to 
push the limits a bit, or push too hard and try to talk their way out of it.

There is also a wide range of email marketing consultants.  Some sell lists 
and spamming services.  Some will encourage confirmed opt-in.  Some would be 
happy to hire somebody else to do the dirty work of cleaning their lists.

---

> - if you don't want us to verify your email addresses - please let us know
> and we will consider them as blocked (no need even to spend your time on
> feeding the firewall or block list), 

That's opt-out.



-- 
These are my opinions.  I hate spam.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hello Slavko,

> 
> 
> 
> I do not understand one thing. Why do you think, that you can use my (or
> any other's) hardware for own business without approve?
> 
> 
> 

I don't think that.
Honestly, I hate that we are using YOUR resources without compensating you.

As I wrote before, I'd love to pay. I initially thought about paying a quota 
for using VRFY.

But if it would be hard to implement - I'd love to pay for the requests.

The issue I had before was I did not know how to get in touch with mail server 
operators - I learned about this mailing group just a few days ago.

Actually, today I talked to my CTO, that we should put a website on 
bouncer.cloud ( http://bouncer.cloud/ ) mentioning that:

- we'd love to compensate mail operators for using their resources,

- if you don't want us to verify your email addresses - please let us know and 
we will consider them as blocked (no need even to spend your time on feeding 
the firewall or block list),

- all contact information to us.

> 
> You are makIng money from this, how many are you willing to pay to
> me/others (for our HW usage)? Or do you think, that we all are maintaining
> own hardware/services for your business?
> 

I'm sure that we would be able to figure out fair pricing. I think that volume 
tiered model could be the one to go.  Would you have something in mind?

There is one more thing that I'm really curious about regarding resources and 
also Atro's statement:

> 
> "Email verification" abusing RCPT TO produces zero benefits in exchange
> for nonzero resource use for the target system owners.
> 
> 

Is "email verification" using more of your resources than if senders would just 
send messages to undeliverable email addresses?

Is it the same payload or "cheeper one".

So far, we haven't been using historical verifications. But we brought that 
with our CTO (during this conversation) that maybe we should consider that. In 
that case, one undeliverable email address would be verified only once, stored 
in an anonymized form, and this information would be used for all the 
customers. In that case, there is a risk of edge case that the email address 
will become deliverable at some point- but maybe the probability is low enough 
not to care about it.

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 Tue, Sep 06, 2022 at 23:12:02, Slavko < mailop@mailop.org > wrote:

> 
> 
> 
> Dňa 6. septembra 2022 20:39:04 UTC používateľ Radek Kaczynski via mailop <
> mailop@ mailop. org ( mailop@mailop.org ) > napísal:
> 
> 
>> 
>> 
>> 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.
>> 
>> 
> 
> 
> 
> I do not understand one thing. Why do you think, that you can use my (or
> any other's) hardware for own business without approve?
> 
> 
> 
> You are makIng money from this, how many are you willing to pay to
> me/others (for our HW usage)? Or do you think, that we all are maintaining
> own hardware/services for your business?
> 
> 
> 
> regards
> 
> 
> 
> --
> Slavko
> https:/ / www. slavino. sk/ ( https://www.slavino.sk/ )
> ___
> 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

Re: [mailop] SMTP noise from *.bouncer.cloud

[Slavko via mailop]

Dňa 6. septembra 2022 20:39:04 UTC používateľ Radek Kaczynski via mailop 
 napísal:

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

I do not understand one thing. Why do you think, that you can use
my (or any other's) hardware for own business without approve?

You are makIng money from this, how many are you willing to pay
to me/others (for our HW usage)? Or do you think, that we all are
maintaining own hardware/services for your business?

regards



-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hi Hal, Members

Interestingly, because we initially were API only, back-end as a service, the 
most significant portion of our revenue comes from:

- Marketing SaaSs - that want to protect their infrastructure from organic but 
low-quality databases; and here low quality usually comes from old data or 
mistypes (via paper form, phone, online forms)

- marketing teams coming to us from Marketing SaaSs, who, during customer 
onboarding, notice that the quality of email lists is low and send their 
customers to us to clean it first.

It's quite weird, but actually doing email verification (or asking customers to 
do) is easier and safer for those ESPs to protect their infrastructure than 
managing bounces :/

I think that in "better" world they should not use email verification but 
simply VRFY instead.

I think that a part of the problem there is the fact that the sender's 
reputation depends a lot on the bounce-back ratio. I know that when it was 
introduced, there was a very high correlation between spammer and bounce back 
ratio. But since then:

- heavy spammers, phishers, and other cyber criminals found ways to reduce it,

- people with old databases started to get a hit…

and for them, it was easier to do automated list cleaning than a proper 
holistic one.

It's usually ESPs who educate the market to clean the list… and as laziness is 
in the DNA of humanity - people go for email verification services.

Back to our customer base…

We also have some big brands that take their customers from offline to online 
loyalty programs.

And they have noticed that the frictionless process (lack of double-opt-in) 
significantly increases conversion rates, but reduces data quality - thus, they 
use email verification for their registration forms.

And here again, VRFY would be a much better solution than what we do.

We also have cold-mailers and marketing agencies as customers… for which in 
fact, I am still having dilemmas about when to treat them as spammers. From 
time to time, I do have a dilemma here if we should block the customer… But I 
know that if they don't use us - they will go to our bigger competitors, from 
whom they will never hear about "Respect in the email" :(

I know it kind of sounds like a producer of alcoholic beverages or cigarettes 
participating in the anti-addiction programs.

Another problem I have is the fact that we are still super small, and our 
influence is very limited.

I think some of our competitors would be in a much better position to educate 
and change the market…

And maybe we will be at some point too… though I hope we can do it without 
crossing a line of our values.

(I know that you all think that our principles are already in the grey zone, 
cause we are in the email verification business.)

This conversation did stimulate me, however, to think about how can we do a 
better job in vetting out our customers and if we can change a business model.

Thank you so much for that!

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 Tue, Sep 06, 2022 at 10:08:56, Hal Murray < halmurray+mai...@sonic.net > 
wrote:

> 
> 
> 
> Radek Kaczynski said:
> 
> 
>> 
>> 
>> That's interesting indeed - we haven't implemented SMTP VRFY as it is very
>> uncommon.
>> However, I truly think that it would be great to use VRFY instead of
>> "broken SMTP trick".
>> I would be more than happy to pay to use it - or give back to the
>> community or charity.
>> 
>> 
> 
> 
> 
> If you want people to take you seriously, I suggest you put your energy
> into figuring out how to convince people that your customers are not
> spammers.
> 
> 
> 
> I have no idea how you could do that.
> 
> 
> 
> --
> These are my opinions. I hate spam.
> 
> 
>___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

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

Re: [mailop] SMTP noise from *.bouncer.cloud

[Luis E . Muñoz via mailop]

On 5 Sep 2022, at 18:07, Atro Tossavainen via mailop wrote:

>> This is a bit less clear, but I'd say that is fine because you have
>> every reason to believe that you are acting on behalf of the address
>> owner, not some 3rd party who may not have acquired the address
>> legitimately.
>
> This, too, can be co-opted by people who aren't your users.

And then, typos. I currently count at 7 the number of persons that believe that 
my 10+ years old Gmail account is theirs. I routinely receive bank, telecom and 
government communications from citizens of 4 Latin American countries.

The address verification would still work in this case—after all, it is a valid 
email—just not for the person filling the form / providing the data.

Best regards

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jaroslaw Rafa via mailop]

Dnia  5.09.2022 o godz. 15:58:51 Jay Hennigan via mailop pisze:
> > Of course, if you want that other person receive all information about
> > the progress and results of your application, and you have no access to
> > that information (unless you personally come to the office to ask about it),
> > then you can use someone else's email address ;). It will cause more
> > trouble to the person who filled the application than to anyone else.
> 
> You forget that there exist bad actors who fill out such forms in order to
> harass people.
> 
> > In the scenario I'm describing it was highly improbable that someone filling
> > in the form would provide all his/her personal data and other requested
> > information and give someone else's email address just for fun.
> 
> No, they'll typically provide someone else's personal data, other
> information, and email address just for fun.

And then they will deliver to the office all the paper documents required to
process the application (which normally only the person for whom the
application has been filled should possess), and they will pay the
application fee in the name of that person? All this just for fun?

And until these steps are done, nothing will happen to the filled-in form.
The person won't even receive any mail. Nobody (except maybe the database
administrator, if he decides to browse the entire database :)) will even
know that person exists in the system. It will just count +1 towards "filled
in the form, did not provide the documents" number in the statistics :). It
won't also prevent filling the form again with the same person's data (as it
is expected within the procedure that one person can apply more than one
time, and these applications are treated completely independently, as if
they were different persons).

The procedure consists of several steps, of which filling in the form is
only the first, and providing documents - the second. Then one will be
contacted by the office one or more times (additional documents may be
requested in the process) until the final decision is made.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Hal Murray via mailop]

Radek Kaczynski said:
> That's interesting indeed - we haven't implemented SMTP VRFY as it is very
> uncommon.
> However, I truly think that it would be great to use VRFY instead of "broken
> SMTP trick".
> I would be more than happy to pay to use it - or give back to the community
> or charity. 

If you want people to take you seriously, I suggest you put your energy into 
figuring out how to convince people that your customers are not spammers.

I have no idea how you could do that.

-- 
These are my opinions.  I hate spam.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-05 at 18:16:06 UTC-0400 (Tue, 6 Sep 2022 00:16:06 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:


Dnia  5.09.2022 o godz. 17:56:13 Bill Cole via mailop pisze:


Yes, of course, but he said he is using "reject_unverified_recipient" 
which

is RECIPIENT address verification, a tool which is used to prevent
backscatter on machines that do legitimate relaying of mail.


Sorry, I used the wrong parameter name. But I definitely meant SENDER
address verification - I hope it was clear from the rest of my 
question...


It is now. Do NOT do that. Do it and the IP involved WILL get 
blacklisted and SHOULD be.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-05 at 18:07:37 UTC-0400 (Tue, 6 Sep 2022 01:07:37 +0300)
Atro Tossavainen via mailop 
is rumored to have said:


Fine. You're responsible for delivering mail submitted to you, and
it is entirely reasonable to confirm that the entity you are
accepting it from has provided a usable address. What Postfix then
does to verify it is exactly what would be done if a message was
simply accepted without verification.


Does not take into account the matter of spam with forged headers.


Headers are irrelevant. No one confirms header addresses.

In any case, We are talking about different things. I read the original 
mail and saw this:



I'm thinking here for example about the Postfix
feature "reject_unverified_recipient"


Which is NOT sender address verification.

Yes, the rest of the text described sender address verification, which 
is unequivocally bad.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jay Hennigan via mailop]

On 9/5/22 15:13, Jaroslaw Rafa via mailop wrote:

Dnia  5.09.2022 o godz. 14:45:40 Michael Peddemors via mailop pisze:


This is the only argument that holds any kind of merit, but if you want to
REALLY see if the person intended to register, send them a real email, as in
confirmed double opt-in, that they have to click on. 


Yes, please do exactly this. And in the confirmation email include the 
IP address used to fill out the form as well as date, time, and 
timezone. (And stop calling it "double opt-in")



Otherwise, I can use
your email in the web form.. it will validate as real, but I should not be
using it.


Indeed.


Of course, if you want that other person receive all information about
the progress and results of your application, and you have no access to
that information (unless you personally come to the office to ask about it),
then you can use someone else's email address ;). It will cause more
trouble to the person who filled the application than to anyone else.


You forget that there exist bad actors who fill out such forms in order 
to harass people.



In the scenario I'm describing it was highly improbable that someone filling
in the form would provide all his/her personal data and other requested
information and give someone else's email address just for fun.


No, they'll typically provide someone else's personal data, other 
information, and email address just for fun.



Similarly, you could theoretically use my email address when buying
something in an online shop. I haven't yet seen any online shop that
requires you to confirm your email address before sending you transaction
confirmations, information about delivery etc. They just take the address
you entered in the order form for granted. But would you do this?


One wouldn't, but there are pranksters and malicious actors out there.

This behavior far pre-dates email and web forms, by the way, but web 
forms and email are just additional conduits for those who call in pizza 
delivery, fill out "bill me later" magazine subscriptions, etc. in order 
to annoy their victims.



Returning to "my" case, of course, it can happen that someone fills in the
application for another person, and provides all data of that other person,
but this is a completely valid case. You can do exactly the same with a
paper form. If you eg. fill in a tax form (on paper) for your friend or
family member - because he/she asked you to help with this - and provide
correctly all his/her data, is this any problem? People do this all the
time.


Indeed they do, and not always with good intentions.

--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jaroslaw Rafa via mailop]

Dnia  5.09.2022 o godz. 17:56:13 Bill Cole via mailop pisze:
> 
> Yes, of course, but he said he is using "reject_unverified_recipient" which
> is RECIPIENT address verification, a tool which is used to prevent
> backscatter on machines that do legitimate relaying of mail.

Sorry, I used the wrong parameter name. But I definitely meant SENDER
address verification - I hope it was clear from the rest of my question...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jaroslaw Rafa via mailop]

Dnia  5.09.2022 o godz. 14:45:40 Michael Peddemors via mailop pisze:
> 
> This is the only argument that holds any kind of merit, but if you want to
> REALLY see if the person intended to register, send them a real email, as in
> confirmed double opt-in, that they have to click on. Otherwise, I can use
> your email in the web form.. it will validate as real, but I should not be
> using it.

Of course, if you want that other person receive all information about
the progress and results of your application, and you have no access to
that information (unless you personally come to the office to ask about it),
then you can use someone else's email address ;). It will cause more
trouble to the person who filled the application than to anyone else.

In the scenario I'm describing it was highly improbable that someone filling
in the form would provide all his/her personal data and other requested
information and give someone else's email address just for fun.

Similarly, you could theoretically use my email address when buying
something in an online shop. I haven't yet seen any online shop that
requires you to confirm your email address before sending you transaction
confirmations, information about delivery etc. They just take the address
you entered in the order form for granted. But would you do this?

Returning to "my" case, of course, it can happen that someone fills in the
application for another person, and provides all data of that other person,
but this is a completely valid case. You can do exactly the same with a
paper form. If you eg. fill in a tax form (on paper) for your friend or
family member - because he/she asked you to help with this - and provide
correctly all his/her data, is this any problem? People do this all the
time.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Atro Tossavainen via mailop]

> Fine. You're responsible for delivering mail submitted to you, and
> it is entirely reasonable to confirm that the entity you are
> accepting it from has provided a usable address. What Postfix then
> does to verify it is exactly what would be done if a message was
> simply accepted without verification.

Does not take into account the matter of spam with forged headers.

I didn't send that email, and you're "verifying" whether I did, doing
exactly the same as Radek's woodpecker-as-a-service. No different from
my perspective.

[root@mail ~]# grep -i sender /etc/postfix/helo_access*
/etc/postfix/helo_access:inpost.tmes.trendmicro.com REJECT Sender Address 
Verification is Abusive
/etc/postfix/helo_access.pcre:/\.mailspamprotection\.com/   REJECT Sender 
Address Verification is Abusive
/etc/postfix/helo_access.pcre:/\.pphosted\.com/ REJECT Sender Address 
Verification is Abusive

And that's just some of the big names doing it.

> This is a bit less clear, but I'd say that is fine because you have
> every reason to believe that you are acting on behalf of the address
> owner, not some 3rd party who may not have acquired the address
> legitimately.

This, too, can be co-opted by people who aren't your users.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jay Hennigan via mailop]

On 9/5/22 13:51, Atro Tossavainen via mailop wrote:


Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are forged
as senders in spam.

And so is Challenge/Response based spam filtering.


Agreed, but so is recipient address verification for the same reason.


b) website registration process - some time ago I was maintaining some
website where people often mistyped their email addresses. Due to the
nature of the website the typical "click on confirmation link that
arrives via email" approach could not be used


List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.


Much like passwords, many web forms have the user enter the email 
address twice to catch typos. Note that spammy sites often label this 
second text box "Confirm Email Address" and claim that this constitutes 
"Confirmed Opt-In". Not so. Abusers will happily fill out such forms 
with the addresses of those they want to annoy with unwanted email, even 
if they have to do so twice.



...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)


If a person repeatedly can't type their own email address into a form, 
then they won't be able to benefit from whatever that form is offering. 
The same is true for phone numbers, postal addresses, etc. So-called 
email address verification services aren't going to be able to correct 
this.



Do you think using this method of email verification in such cases
is OK or not?


If it is, then it must be OK in all cases. This is, after all, the
intended use case for Radek's system as per his previous correspondence.


The elephant in the room is, who are the customers of ANY third-party 
commercial email verification service? Casual mailers, businesses who 
develop and maintain their own mailing lists, and legitimate ESPs get 
bounce messages. They can and should be using these on a regular basis 
to stop future mailings to those addresses that are not valid.


The only logical customer of such a service IMHO is someone who acquires 
a list of email addresses with which they have had no previous 
interaction and intends to mail that list in bulk. There is a word 
describing such people. That word is "spammer".


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-05 at 16:51:34 UTC-0400 (Mon, 5 Sep 2022 23:51:34 +0300)
Atro Tossavainen via mailop 
is rumored to have said:


Regarding the above, I have the following question:

What do you (and maybe other people on the list) think about such 
email

verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the 
Postfix
feature "reject_unverified_recipient" that checks sender's email 
using this
method before accepting (or rejecting, if sender's email doesn't 
verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html 
). Some
other MTAs have similar features too, there are also milters that do 
this.


Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are 
forged

as senders in spam.

And so is Challenge/Response based spam filtering.


Yes, of course, but he said he is using "reject_unverified_recipient" 
which is RECIPIENT address verification, a tool which is used to prevent 
backscatter on machines that do legitimate relaying of mail.


But his phrasing does confuse that...

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jarland Donnell via mailop]

send the applicant a copy of their completed form


And that right there is where a lot of my customers get in trouble. It's 
a shame but these days, you can't even send a "Hello {name}" to anyone 
from a form or you just end up sending "Hey 
get_cheap_viagra_at_this_website.tld" though it is mildly hilarious.


On 2022-09-05 16:16, Andrew C Aitchison via mailop wrote:

On Mon, 5 Sep 2022, Atro Tossavainen via mailop wrote:


Regarding the above, I have the following question:

What do you (and maybe other people on the list) think about such 
email

verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the 
Postfix
feature "reject_unverified_recipient" that checks sender's email 
using this
method before accepting (or rejecting, if sender's email doesn't 
verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html 
). Some
other MTAs have similar features too, there are also milters that do 
this.


Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are 
forged

as senders in spam.


I agree with Atro here.

b) website registration process - some time ago I was maintaining 
some

website where people often mistyped their email addresses. Due to the
nature of the website the typical "click on confirmation link that
arrives via email" approach could not be used


List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.

anything except the registration form). So I included the code that 
did the
email verification ("abusing RCPT TO") upon form submission, and in 
case of

a verification failure, asked the user to correct the address.


...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)


Do you think using this method of email verification in such cases
is OK or not?


Atro appears to object to this use. I disagree.

Arguably this is less expensive than "double opt in", which is doing a
similar thing.

He may be right that some systems will recognise and block sites that
do this sort of verification.
One way around that might be for the
final step be to send the applicant a copy of their completed form.
If this bounces, then you ask them to correct the address.
Of course, if they give *someone-elses* email (whether by accident or
deliberately) you have just mailed personal data to a third party ...

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-05 at 16:27:13 UTC-0400 (Mon, 5 Sep 2022 22:27:13 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:


Dnia  5.09.2022 o godz. 22:39:01 Atro Tossavainen via mailop pisze:


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.


Regarding the above, I have the following question:

What do you (and maybe other people on the list) think about such 
email

verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the 
Postfix
feature "reject_unverified_recipient" that checks sender's email using 
this
method before accepting (or rejecting, if sender's email doesn't 
verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html 
). Some
other MTAs have similar features too, there are also milters that do 
this.


Fine. You're responsible for delivering mail submitted to you, and it is 
entirely reasonable to confirm that the entity you are accepting it from 
has provided a usable address. What Postfix then does to verify it is 
exactly what would be done if a message was simply accepted without 
verification.



b) website registration process - some time ago I was maintaining some
website where people often mistyped their email addresses. Due to the 
nature
of the website the typical "click on confirmation link that arrives 
via

email" approach could not be used (the form was a part of an official
procedure, users had to fill in a lot of personal data, with email 
being
only one of many fields, also a lot of people filled the form on 
dedicated
machines available in the office that was running the website, where 
they
didn't have access to their email - actually, they didn't have access 
to
anything except the registration form). So I included the code that 
did the
email verification ("abusing RCPT TO") upon form submission, and in 
case of

a verification failure, asked the user to correct the address.


This is a bit less clear, but I'd say that is fine because you have 
every reason to believe that you are acting on behalf of the address 
owner, not some 3rd party who may not have acquired the address 
legitimately.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Atro Tossavainen via mailop]

> Atro appears to object to this use. I disagree.

It's abusable. Your users might not be who you think they will be.

> Arguably this is less expensive than "double opt in", which is doing
> a similar thing.

Yes. It also returns a different category of result.

> One way around that might be for the
> final step be to send the applicant a copy of their completed form.
> If this bounces, then you ask them to correct the address.

Yup.

> Of course, if they give *someone-elses* email (whether by accident
> or deliberately) you have just mailed personal data to a third party

People will mistype their address. Some of the typos exist. I know
because I have access to some of those that do - we are in the
business of spamtrapping, some of our traps are typo domains, and
some of the stuff that comes in is... not bulk email.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Michael Peddemors via mailop]

On 2022-09-05 13:27, Jaroslaw Rafa via mailop wrote:

What do you (and maybe other people on the list) think about such email
verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the Postfix
feature "reject_unverified_recipient" that checks sender's email using this
method before accepting (or rejecting, if sender's email doesn't verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
other MTAs have similar features too, there are also milters that do this.


Noone should do that, to easy to allow an attacker to get your email 
server blacklisted.. And it doesn't work in the real world, for many 
reasons too numerous to mention..



b) website registration process - some time ago I was maintaining some
website where people often mistyped their email addresses. Due to the nature
of the website the typical "click on confirmation link that arrives via
email" approach could not be used (the form was a part of an official
procedure, users had to fill in a lot of personal data, with email being
only one of many fields, also a lot of people filled the form on dedicated
machines available in the office that was running the website, where they
didn't have access to their email - actually, they didn't have access to
anything except the registration form). So I included the code that did the
email verification ("abusing RCPT TO") upon form submission, and in case of
a verification failure, asked the user to correct the address.


This is the only argument that holds any kind of merit, but if you want 
to REALLY see if the person intended to register, send them a real 
email, as in confirmed double opt-in, that they have to click on. 
Otherwise, I can use your email in the web form.. it will validate as 
real, but I should not be using it.


Of course, those types of forms (Signup Email Validation) CAN be used 
for a script kiddy mail bomb attack.  But that is a different problem. 
Better web form security, and human detection on the form can prevent that.







Do you think using this method of email verification in such cases is OK or
not?




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Andrew C Aitchison via mailop]

On Mon, 5 Sep 2022, Atro Tossavainen via mailop wrote:


Regarding the above, I have the following question:

What do you (and maybe other people on the list) think about such email
verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the Postfix
feature "reject_unverified_recipient" that checks sender's email using this
method before accepting (or rejecting, if sender's email doesn't verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
other MTAs have similar features too, there are also milters that do this.


Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are forged
as senders in spam.


I agree with Atro here.


b) website registration process - some time ago I was maintaining some
website where people often mistyped their email addresses. Due to the
nature of the website the typical "click on confirmation link that
arrives via email" approach could not be used


List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.


anything except the registration form). So I included the code that did the
email verification ("abusing RCPT TO") upon form submission, and in case of
a verification failure, asked the user to correct the address.


...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)


Do you think using this method of email verification in such cases
is OK or not?


Atro appears to object to this use. I disagree.

Arguably this is less expensive than "double opt in", which is doing a 
similar thing.


He may be right that some systems will recognise and block sites that
do this sort of verification.
One way around that might be for the
final step be to send the applicant a copy of their completed form.
If this bounces, then you ask them to correct the address.
Of course, if they give *someone-elses* email (whether by accident or 
deliberately) you have just mailed personal data to a third party ...


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Atro Tossavainen via mailop]

> Regarding the above, I have the following question:
> 
> What do you (and maybe other people on the list) think about such email
> verification method ("abusing RCPT TO") used as part of:
> 
> a) mail receiving process - I'm thinking here for example about the Postfix
> feature "reject_unverified_recipient" that checks sender's email using this
> method before accepting (or rejecting, if sender's email doesn't verify) the
> message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
> other MTAs have similar features too, there are also milters that do this.

Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are forged
as senders in spam.

And so is Challenge/Response based spam filtering.

> b) website registration process - some time ago I was maintaining some
> website where people often mistyped their email addresses. Due to the
> nature of the website the typical "click on confirmation link that
> arrives via email" approach could not be used

List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.

> anything except the registration form). So I included the code that did the
> email verification ("abusing RCPT TO") upon form submission, and in case of
> a verification failure, asked the user to correct the address.  

...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)

> Do you think using this method of email verification in such cases
> is OK or not?

If it is, then it must be OK in all cases. This is, after all, the
intended use case for Radek's system as per his previous correspondence.

But I don't think it is.

In my opinion, whether you do it yourself or outsource it to a partner
cannot be a factor in whether it is abusive. Neither is the volume. The
main bit is that the creator of any such system has observed the fact
that EXPN and VRFY are no longer available, so they have decided to
circumvent this fact and impose themselves on the mail server owners
in ways they can't pre-emptively break without breaking all email.

The solution to that, then, is rejecting all connections from such
systems, either within SMTP or on the network level. But doing that
requires observing where it is coming from first.

Those blocks tend to be of a set-and-forget nature.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jaroslaw Rafa via mailop]

Dnia  5.09.2022 o godz. 22:39:01 Atro Tossavainen via mailop pisze:
> 
> 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.

Regarding the above, I have the following question:

What do you (and maybe other people on the list) think about such email
verification method ("abusing RCPT TO") used as part of:

a) mail receiving process - I'm thinking here for example about the Postfix
feature "reject_unverified_recipient" that checks sender's email using this
method before accepting (or rejecting, if sender's email doesn't verify) the
message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
other MTAs have similar features too, there are also milters that do this.

b) website registration process - some time ago I was maintaining some
website where people often mistyped their email addresses. Due to the nature
of the website the typical "click on confirmation link that arrives via
email" approach could not be used (the form was a part of an official
procedure, users had to fill in a lot of personal data, with email being
only one of many fields, also a lot of people filled the form on dedicated
machines available in the office that was running the website, where they
didn't have access to their email - actually, they didn't have access to
anything except the registration form). So I included the code that did the
email verification ("abusing RCPT TO") upon form submission, and in case of
a verification failure, asked the user to correct the address.

Do you think using this method of email verification in such cases is OK or
not?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Michael Rathbun via mailop]

On Mon, 5 Sep 2022 12:27:05 -0700, Jay Hennigan via mailop 
wrote:

>I assume that:
>- When I walk up to a bank teller wearing a mask

One of the irritating aspects of the unnecessary pandemic was that my very
favorite Jack Vance quote became awkwardly inoperative.

mdr
-- 
"Honest folk do not wear masks when they enter a bank."
   -- Unspiek, Baron Bodissey

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Atro Tossavainen via mailop]

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" 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/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jay Hennigan via mailop]

On 9/5/22 12:12, Bill Cole via mailop wrote:

On 2022-09-05 at 14:42:38 UTC-0400 (Mon, 5 Sep 2022 11:42:38 -0700)
Jay Hennigan via mailop 
is rumored to have said:


On 9/5/22 07:48, Radek Kaczynski via mailop wrote:


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.


What logical basis or evidence do you have to support this assumption?


Those assumptions are necessary for any semblance of ethics in their 
business model, so they are logically required.


Kind of like

I assume that:
- When I walk up to a bank teller wearing a mask and displaying a Glock 
pistol, the teller will assume that the mask is for COVID protection.
- Bank employees will be so impressed with the quality of the pistol 
that the bank will reward me with cash simply for the privilege of 
viewing a weapon of such elegance.



It is that simple.


Indeed.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-05 at 14:42:38 UTC-0400 (Mon, 5 Sep 2022 11:42:38 -0700)
Jay Hennigan via mailop 
is rumored to have said:


On 9/5/22 07:48, Radek Kaczynski via mailop wrote:


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.


What logical basis or evidence do you have to support this assumption?


Those assumptions are necessary for any semblance of ethics in their 
business model, so they are logically required.


It is that simple.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jay Hennigan via mailop]

On 9/5/22 07:48, Radek Kaczynski via mailop wrote:


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.


What logical basis or evidence do you have to support this assumption?

--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hi Andrew, Ladies & Gentlemen,

> 
> Coincidentally, I have just been helping someone enable SMTP VRFY in exim.
> I suppose that you do use VRFY
> when it is availble ?

That's interesting indeed - we haven't implemented SMTP VRFY as it is very 
uncommon.

However, I truly think that it would be great to use VRFY instead of "broken 
SMTP trick".

I would be more than happy to pay to use it - or give back to the community or 
charity.

But I know it's a lot to ask, and probably for us to be able to do that, I 
would have to gain the trust of the email community first. And it does not 
happen over the night and after one conversation.

In general, I've been thinking a lot about compensation for a long time…

Let's be honest -  we do use YOUR resources to verify email addresses - cause 
we are initiating SMTP protocol with YOUR  servers.

And I hate the fact that it is abusive (as I mentioned before, we try to be as 
least abusive as it's possible - but it is abuse).

So, I think we could:

- pay some tax for email verification (directly or to the community/charity),

- pay for access to VRFY to those that would expose it to us,

- turn off verification for those email providers that don't wish us to do it.

I know it's far from ideal… and that in an ideal world, we should never exist… 
but the "market" is already taught that email verification is helpful…

And before we change and convince the market, maybe together we can find some 
temporary solutions.

In the genesis of email, VRFY was available, but after being abused was 
depreciated.

But maybe we can do something to have it accessible to some people and in some 
use cases?

Anyways… I really appreciate the dialog with you all!

Primarily as I know, I represent a completely different perspective, by some, 
categorized as an evil one.

> 
> was going to suggest that you use, say
> sales@ customer. pl ( sa...@customer.pl )
> as the envelope sender in your probes.
> That may have SPF, DKIM, DMARC implications,
> but since it sales@ not personal data in GDPR terms, in principle would
> you be happy to do that ?

I'm afraid I did not get that idea :(
We are using hello@bouncer.cloud , as far as I remember well… but the GDPR 
aspect considers the owners of email addresses that we verify.
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.

Thank you again for the opportunity to be here - if you are already tired of me 
- please let me know.

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 01:02:17, Andrew C Aitchison < and...@aitchison.me.uk > 
wrote:

> 
> 
> 
> On Sun, 4 Sep 2022, Radek Kaczynski via mailop wrote:
> 
> 
>> 
>> 
>> Thanks to members of this group I learned that
>> we still have a homework to be done if it comes to transparency, and
>> making it easier to folks like you to easily identify us. I hate the fact
>> that this topic has stolen so much time and attention of some of you
>> because it wasn’t as easy to identify Bouncer. cloud (
>> http://bouncer.cloud/ ) ( http:/ / bouncer. cloud/ ( http://bouncer.cloud/
>> ) ) :(
>> 
>> 
>> 
>> I think that I todays world there is so much polarization that sometimes
>> some center is needed. In this case, I think there are so many senders who
>> need to hear the rules, but unfortunately they usually are not exposed to
>> perspective of Mail Operators. And I know it sounds ridiculous but when
>> they hear from a List Cleaner some truth they may be bit more open to
>> hear.
>> 
>> 
>> 
>> If it comes to GDPR compliance, if the “data subject” will approach us
>> about the information about them we will be obliged to act on this.
>> 
>> 
>> 
>> As we are just a data processor we will have to inform the data controller
>> about such request and let them act.
>> 
>> 
> 
> 
> 
> I was going to suggest that you use, say
> sales@ customer. pl ( sa...@customer.pl )
> as the envelope sender in your probes.
> That may have SPF, DKIM, DMARC implications,
> but since it sales@ not personal data in GDPR terms, in principle would
> you be happy to do that ?
> 
> 
> 
> Coincidentally, I have just been helping someone enable SMTP VRFY in exim.
> I suppose that you do use VRFY
> when it is availble ?
> 
> 
> 
> --
> Andrew C. Aitchison Kendal, UK andrew@ aitchison. me. uk (
> and...@aitchison.me.uk )
> 
> 
>___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Andrew C Aitchison via mailop]

On Sun, 4 Sep 2022, Radek Kaczynski via mailop wrote:


Thanks to members of this group I learned that
we still have a homework to be done if it comes to transparency, and
making it easier to folks like you to easily identify us.
I hate the fact that this topic has stolen so much time and
attention of some of you because it wasn’t as easy to identify
Bouncer.cloud ( http://bouncer.cloud/ ) :(



I think that I todays world there is so much polarization that
sometimes some center is needed. In this case, I think there are so
many senders who need to hear the rules, but unfortunately they
usually are not exposed to perspective of Mail Operators.  And I
know it sounds ridiculous but when they hear from a List Cleaner
some truth they may be bit more open to hear.

If it comes to GDPR compliance, if the “data subject” will approach
us about the information about them we will be obliged to act on
this.

As we are just a data processor we will have to inform the data
controller about such request and let them act.


I was going to suggest that you use, say
sa...@customer.pl
as the envelope sender in your probes.
That may have SPF, DKIM, DMARC implications,
but since it sales@ not personal data in GDPR terms,
in principle would you be happy to do that ?

Coincidentally, I have just been helping someone enable
SMTP VRFY in exim. I suppose that you do use VRFY
when it is availble ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Carl, Yes, I’m aware that you do see the addresses, and thus the naming 
convention currently used is designed to be transparent- so there is no hiding.
Thanks to members of this group I learned that we still have a homework to be 
done if it comes to transparency, and making it easier to folks like you to 
easily identify us.
I hate the fact that this topic has stolen so much time and attention of some 
of you because it wasn’t as easy to identify Bouncer.cloud ( 
http://bouncer.cloud/ ) :(

Hans-Martin- thank you for pointing that out that there is some privacy-proxy 
turned on on those domains. That wasn’t my intention, and I’ll have to check 
that.

As I said- long time ago we decided not to hide.
Even though we are just a small team of 5 people, (far smaller company then 
most our competitors) thus very fragile to people in power like you.

I know our business model is far from being perfect, and I don’t like few 
things about it.
But I do see some bright side of it- I hope that when someone comes to us 
instead of to some
other email verifier- they will at least hear some of my “Email Deliverability 
- result of Love&Respect”speech.

Maybe it will change some behaviors of few “unaware spammers”.
I know I have a small influence, but in some cases can be a bridge between two 
opposite sides.

I think that I todays world there is so much polarization that sometimes some 
center is needed. In this case, I think there are so many senders who need to 
hear the rules, but unfortunately they usually are not exposed to perspective 
of Mail Operators.
And I know it sounds ridiculous but when they hear from a List Cleaner some 
truth they may be bit more open to hear.

If it comes to GDPR compliance, if the “data subject” will approach us about 
the information about them we will be obliged to act on this.

As we are just a data processor we will have to inform the data controller 
about such request and let them act.

However I’ll have to check with my legal council what should we do in case data 
controller does not act. I guess in that case we will have to reveal who is 
data controller - our customer. But I’d have to check.

If it comes to a spam trap where there is no actual person behind it, it’s bit 
trickier. Cause there is no person who’s information are processed by us- it’s 
a organization managing spam trap.
In that case I think I will have to protect personal data of my customer (as in 
this case I am data controller). Unless it is requested by law enforcement 
authorities.
But I’d have to check that too.

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 Sun, Sep 4 2022 at 11:28 PM, Hans-Martin Mosner < mailop@mailop.org > wrote:

> 
> 
> 
> Am 04.09.22 um 21:49 schrieb Radek Kaczynski via mailop:
> 
> 
> 
> > Those few domains with small traffic are:
> > - bringmesomejuice.com 
> > - iusedtolikeit.com 
> > - sometimeinthepast.com 
> > - mybigfluffyfriend.com 
> 
> 
> 
> You certainly realize why this marks your operation shady (just as most
> other e-mail verification businesses)?
> 
> 
> 
> Personal e-mail addresses are protected private information under european
> GDPR laws. When you process this data (and probing mail servers to see
> whether an e-mail exists is already some kind of processing) you need a
> valid reason under those laws, and of course you need to be identifiable,
> because the owner of such an e-mail address has a legal right to know who
> stores and processes their data for which purposes.
> 
> 
> 
> If you're using domain names registered through proxy services, hosted on
> a cloud provider who wouldn't reveal your identity unless we pry it from
> their cold dead hands, you're actively subverting these laws.
> 
> 
> 
> Of course, by stepping forward to participate in this discussion you're
> exposing yourself to quite some fire, that's pretty courageous and
> certainly a bit better than those cowards who prefer to stay anonymous.
> But still your business model is the same as theirs.
> 
> 
> 
> Even if you try to appear as friendly and open, would you be willing to
> reveal the names of your customers who requested an e-mail address
> verification if you were asked by the e-mail owner?
> 
> 
> 
> I had an exchange with someone from a similar service a while ago, after I
> found out that they (and some other mail validation services who didn't
> even reply to my request) have been trying to check an e-mail address on
> our server which did not exist (we reject such accesses without revealing
> whether the address exists or not). I set up the address as a spam trap
> when I noticed, and a very short time a

Re: [mailop] SMTP noise from *.bouncer.cloud

[Hans-Martin Mosner via mailop]

Am 04.09.22 um 21:49 schrieb Radek Kaczynski via mailop:

> Those few domains with small traffic are:
> - bringmesomejuice.com 
> - iusedtolikeit.com 
> - sometimeinthepast.com 
> - mybigfluffyfriend.com 

You certainly realize why this marks your operation shady (just as most other 
e-mail verification businesses)?

Personal e-mail addresses are protected private information under european GDPR laws. When you process this data (and 
probing mail servers to see whether an e-mail exists is already some kind of processing) you need a valid reason under 
those laws, and of course you need to be identifiable, because the owner of such an e-mail address has a legal right to 
know who stores and processes their data for which purposes.


If you're using domain names registered through proxy services, hosted on a cloud provider who wouldn't reveal your 
identity unless we pry it from their cold dead hands, you're actively subverting these laws.


Of course, by stepping forward to participate in this discussion you're exposing yourself to quite some fire, that's 
pretty courageous and certainly a bit better than those cowards who prefer to stay anonymous. But still your business 
model is the same as theirs.


Even if you try to appear as friendly and open, would you be willing to reveal the names of your customers who requested 
an e-mail address verification if you were asked by the e-mail owner?


I had an exchange with someone from a similar service a while ago, after I found out that they (and some other mail 
validation services who didn't even reply to my request) have been trying to check an e-mail address on our server which 
did not exist (we reject such accesses without revealing whether the address exists or not). I set up the address as a 
spam trap when I noticed, and a very short time after this it received porn and fake dating spam. I asked the validation 
service who their customer was, and they could or would not tell me (they claimed that they didn't have that data 
anymore, I can't verify or falsify that claim, of course).


As soon as a validation service is transparent about who they work for when checking an address, I may exempt them. Fat 
chance.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Carl Byington via mailop]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 2022-09-04 at 19:49 +, Radek Kaczynski via mailop wrote:
> Regarding the list of IPs - I'd prefer to send it to the interested
> people directly.
> I'd like to have a track of record to whom I have exposed it and


You realize of course that when you connect to a mail server, we can see
the ip address you are using, and the dns naming convention that you
use. From that it is a simple script to generate the list below of
almost 1000 ip addresses.


> how they plan to act on it.

Feed the firewall, of course.

5.39.122.67 sbg5-mail-144.bouncer.cloud.
5.135.32.66 sbg5-mail-40.bouncer.cloud.
5.135.80.107 sbg5-mail-41.bouncer.cloud.
5.135.120.254 sbg5-mail-39.bouncer.cloud.
5.196.58.154 sbg5-mail-42.bouncer.cloud.
5.196.58.239 sbg5-mail-43.bouncer.cloud.
5.196.98.237 sbg5-mail-44.bouncer.cloud.
37.59.67.40 sbg5-mail-37.bouncer.cloud.
37.59.88.176 sbg5-mail-38.bouncer.cloud.
37.59.219.241 sbg5-mail-36.bouncer.cloud.
37.187.190.8 sbg5-mail-35.bouncer.cloud.
37.187.190.123 sbg5-mail-32.bouncer.cloud.
37.187.190.125 sbg5-mail-33.bouncer.cloud.
37.187.190.127 sbg5-mail-34.bouncer.cloud.
46.105.33.125 sbg5-mail-141.bouncer.cloud.
46.105.36.159 sbg5-mail-142.bouncer.cloud.
46.105.164.19 sbg5-mail-153.bouncer.cloud.
46.105.234.21 sbg5-mail-143.bouncer.cloud.
51.38.103.170 de1-mail-189.bouncer.cloud.
51.38.103.179 de1-mail-190.bouncer.cloud.
51.38.103.250 de1-mail-73.bouncer.cloud.
51.38.105.9 de1-mail-193.bouncer.cloud.
51.38.105.10 de1-mail-191.bouncer.cloud.
51.38.105.11 de1-mail-192.bouncer.cloud.
51.38.105.52 de1-mail-274.bouncer.cloud.
51.38.107.29 de1-mail-136.bouncer.cloud.
51.38.107.30 de1-mail-137.bouncer.cloud.
51.38.107.31 de1-mail-138.bouncer.cloud.
51.38.107.32 de1-mail-139.bouncer.cloud.
51.38.107.52 de1-mail-142.bouncer.cloud.
51.38.107.54 de1-mail-143.bouncer.cloud.
51.38.107.57 de1-mail-275.bouncer.cloud.
51.38.116.69 de1-mail-1.bouncer.cloud.
51.38.116.70 de1-mail-2.bouncer.cloud.
51.38.116.79 de1-mail-276.bouncer.cloud.
51.38.117.3 de1-mail-29.bouncer.cloud.
51.38.117.50 de1-mail-30.bouncer.cloud.
51.38.118.38 de1-mail-246.bouncer.cloud.
51.38.119.171 de1-mail-194.bouncer.cloud.
51.38.119.172 de1-mail-195.bouncer.cloud.
51.38.119.173 de1-mail-196.bouncer.cloud.
51.38.120.201 de1-mail-3.bouncer.cloud.
51.38.120.216 de1-mail-4.bouncer.cloud.
51.38.120.249 de1-mail-141.bouncer.cloud.
51.38.121.166 de1-mail-197.bouncer.cloud.
51.68.160.36 de1-mail-33.bouncer.cloud.
51.68.160.181 de1-mail-277.bouncer.cloud.
51.68.162.245 de1-mail-222.bouncer.cloud.
51.68.163.58 de1-mail-75.bouncer.cloud.
51.68.178.9 de1-mail-199.bouncer.cloud.
51.68.178.58 de1-mail-5.bouncer.cloud.
51.68.178.63 de1-mail-198.bouncer.cloud.
51.68.187.159 de1-mail-74.bouncer.cloud.
51.75.82.12 de1-mail-8.bouncer.cloud.
51.75.82.27 de1-mail-93.bouncer.cloud.
51.75.82.49 de1-mail-280.bouncer.cloud.
51.75.84.157 de1-mail-223.bouncer.cloud.
51.75.84.158 de1-mail-254.bouncer.cloud.
51.75.84.161 de1-mail-281.bouncer.cloud.
51.75.101.182 sbg5-mail-2.bouncer.cloud.
51.75.101.183 sbg5-mail-3.bouncer.cloud.
51.75.101.187 sbg5-mail-4.bouncer.cloud.
51.75.101.188 sbg5-mail-1.bouncer.cloud.
51.75.101.240 sbg5-mail-5.bouncer.cloud.
51.75.101.242 sbg5-mail-6.bouncer.cloud.
51.75.101.244 sbg5-mail-7.bouncer.cloud.
51.75.101.247 sbg5-mail-8.bouncer.cloud.
51.75.101.248 sbg5-mail-9.bouncer.cloud.
51.75.101.249 sbg5-mail-10.bouncer.cloud.
51.75.101.252 sbg5-mail-11.bouncer.cloud.
51.75.101.253 sbg5-mail-12.bouncer.cloud.
51.75.104.8 sbg5-mail-15.bouncer.cloud.
51.75.104.56 sbg5-mail-13.bouncer.cloud.
51.75.104.57 sbg5-mail-14.bouncer.cloud.
51.75.153.68 de1-mail-6.bouncer.cloud.
51.75.153.69 de1-mail-7.bouncer.cloud.
51.75.154.78 de1-mail-251.bouncer.cloud.
51.75.154.88 de1-mail-252.bouncer.cloud.
51.75.154.91 de1-mail-253.bouncer.cloud.
51.75.154.92 de1-mail-278.bouncer.cloud.
51.75.154.104 de1-mail-247.bouncer.cloud.
51.75.154.105 de1-mail-248.bouncer.cloud.
51.75.154.106 de1-mail-249.bouncer.cloud.
51.75.154.114 de1-mail-250.bouncer.cloud.
51.75.155.157 de1-mail-79.bouncer.cloud.
51.75.155.158 de1-mail-80.bouncer.cloud.
51.75.155.167 de1-mail-81.bouncer.cloud.
51.75.155.168 de1-mail-82.bouncer.cloud.
51.75.155.169 de1-mail-83.bouncer.cloud.
51.75.155.170 de1-mail-84.bouncer.cloud.
51.75.155.171 de1-mail-85.bouncer.cloud.
51.75.155.172 de1-mail-86.bouncer.cloud.
51.75.155.173 de1-mail-87.bouncer.cloud.
51.75.155.174 de1-mail-88.bouncer.cloud.
51.77.77.185 de1-mail-37.bouncer.cloud.
51.77.77.186 de1-mail-38.bouncer.cloud.
51.77.77.187 de1-mail-39.bouncer.cloud.
51.77.77.188 de1-mail-40.bouncer.cloud.
51.77.77.189 de1-mail-41.bouncer.cloud.
51.77.77.190 de1-mail-42.bouncer.cloud.
51.77.77.191 de1-mail-43.bouncer.cloud.
51.77.77.192 de1-mail-44.bouncer.cloud.
51.77.77.193 de1-mail-45.bouncer.cloud.
51.77.77.194 de1-mail-46.bouncer.cloud.
51.77.77.195 de1-mail-47.bouncer.cloud.
51.77.77.196 de1-mail-48.bouncer.cloud.
51.77.77.197 de1-mail-49.bouncer.cloud.
51.77.77.198 de1-mail-50.bouncer.cloud.
51.77.

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hi Jarland,
As I mentioned before, I'm not a fan of cold email in general and specifically 
mass cold email.

I'm also not a representative of any company supporting cold email.

But to be fair, I have to say that as far as I'm concerned, users of Woodpecker 
are not able to do the old "spray and pray" technique - as Woodpecker imposes 
some limits.

Folks there, as I've heard and seen, are trying their best to educate their 
users to go for quality not quantity.
Which:

- starts with very good, manual prospecting,

- creating templates of messages, but...
- manually crafting big blocks of messages per recipient, so it is really 
personalized.

I've learned from them that they want to provide SMBs with a tool that will 
automate some repetitive tasks so that they can focus on their relationships.

I think that mass spamming is not happening via cold-email tools.

Anyways, don't want to be devil's advocate here, just wanted to share my 
perspective.

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 Sun, Sep 04, 2022 at 01:13:27, Jarland Donnell < mailop@mailop.org > wrote:

> 
> 
> 
> I think it's fair to say that there is "some" room for nuance on cold
> email, but the reason I don't allow it on my platform and I actively work
> to block companies that do, is simply this:
> 
> 
> 
> There is absolutely no one out there looking for help to send a cold email
> that isn't sending spam.
> 
> 
> 
> I mean if I see you and what you do and I think "We could really do
> something good together" I write you a personalized email, by hand, asking
> if you'd like to do business together. Is that spam? Of course not. But
> then there's what actually happens when someone needs help from a cold
> email company:
> 
> 
> 
> I collect a list of email addresses at companies that match a specific
> filter/business type, run a script to replace a variable with their name,
> and then blast out 4,000 duplicate emails with the old "spray and pray"
> technique. It's a numbers game, I don't care if you don't get back to me
> because I don't even know who you are. You were just part of a scraped
> list.
> 
> 
> 
> While the single, hand-typed cold email is fine, the automated cold email
> blast is spam. By merely saying "we want to help you send cold email"
> you're only focusing on the latter. Because when you're personally
> hand-writing a message to someone that you want to do business with, you
> don't need a service to help you do it.
> 
> 
> 
> On 2022-09-03 17:43, Radek Kaczynski via mailop wrote:
> 
> 
>> 
>> 
>> Good evening,
>> 
>> 
>> 
>> I feel like I need to come clean on the Bouncer - Woodpecker association
>> and my perspective on cold email.
>> 
>> 
>> 
>> (But please let me know if my responses are not welcome - I feel here like
>> a guest, and I don’t want to abuse your hospitality)
>> 
>> 
>> 
>> Long story short - when working for Mack Trucks, we had issues when an
>> email address was passed over the counter at the dealerships. Many typos
>> were affecting not only the continuity of communication but also master
>> data management and further processes down the road. At the same time, I
>> was going through a divorce and decided to move back from the U.S. to
>> Poland.
>> When I told my friend (CEO of Woodpecker) about it, he motivated me and
>> helped me to take a big step - quitting my corporate job and starting
>> Bouncer.
>> 
>> 
>> 
>> So I’m not directly associated with Woodpecker, but indeed there is some
>> connection between Bouncer and Woodpecker:
>> - Woodpecker’s CEO is my close friend from high school,
>> - He helped me establish Bouncer, when I decided to come back from the
>> U.S. to Poland,
>> - Some Woodpecker’s shareholders are also Bouncer’s shareholders,
>> - Woodpecker is one of Bouncer’s customers,
>> - We initially had offices in the same building.
>> 
>> 
>> 
>> If it comes to the cold email… I think it’s not that black&white…
>> 
>> 
>> 
>> I personally am not a fan of cold email, and sometimes do get irritated by
>> the spammy one.
>> 
>> 
>> 
>> But I also see it sometimes as an equalizer - giving the same chances when
>> competing with global enterprises.
>> This way, small businesses can reach out to potentially interested
>> customers - which is very costly and very difficult in other communication
>> channels.
>> Small businesses can’t usually afford sophisticated marketing funnels
>> (full of Ads, LeadMagnets, Remarketing to get opt-in, and then sharing the
>> contact in the network of affiliates). In a cold email, you don’t have to
>> have huge budgets only because your big competitors can afford high
>> Customer Acquisition Costs.
>> 
>> 
>> 
>> But RESPECTFUL cold email is complicated and thus rare to see. Cause
>> respect

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hello,

> 
> 
> 
> Probably easier just to post it here.
> 
> 
> 

Our main domain for email verifications is *bouncer.cloud* ( 
http://bouncer.cloud/ ).

We do have some small traffic going through a few other domains that we have 
set in the initial days.

We did not mean to hide, but looking at our competitors thought it was good to 
have many domains.

Later on, we discovered that a multiple-domains set-up is aimed to hide, so we 
abandoned this strategy and stuck to bouncer.cloud ( http://bouncer.cloud/ ).

Those few domains with small traffic are:

- bringmesomejuice.com ( http://bringmesomejuice.com/ )

- iusedtolikeit.com ( http://iusedtolikeit.com/ )

- sometimeinthepast.com ( http://sometimeinthepast.com/ )

- mybigfluffyfriend.com ( http://mybigfluffyfriend.com/ )

So as you can see not much to block there ;)

Regarding the list of IPs - I'd prefer to send it to the interested people 
directly.

I'd like to have a track of record to whom I have exposed it and how they plan 
to act on it.

Anyone interested - please shoot me an email at ra...@usebouncer.com.

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 Sun, Sep 04, 2022 at 00:52:13, Carl Byington < mailop@mailop.org > wrote:

> 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> 
> On Sun, 2022-09-04 at 00:43 +0200, Radek Kaczynski via mailop wrote:
> 
> 
>> 
>> 
>> If any of you would like to get a full list of our IP addresses and
>> domains so that you can block Bouncer's requests - please feel free to
>> email me at radek@ usebouncer. com ( ra...@usebouncer.com ).
>> 
>> 
> 
> 
> 
> Probably easier just to post it here.
> 
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> 
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYxPahxUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsHurwCfdx61FTKS+ojFTEWYHLsTfdaFBm4A
> n2hadXNEhOVjlpeJfEt3o7TX6pf8
> =5NsA
> -END PGP SIGNATURE-
> 
> 
> 
> ___
> 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

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jay Hennigan via mailop]

On 9/3/22 15:43, Radek Kaczynski via mailop wrote:

Good evening,


[snip]

I personally am not a fan of cold email, and sometimes do get irritated 
by the spammy one.


But I also see it sometimes as an equalizer - giving the same chances 
when competing with global enterprises.


[snip]


But RESPECTFUL cold email is complicated and thus rare to see.


Kind of like advocating that if you only pick up turds by the clean end 
you don't need to wash your hands.



--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jarland Donnell via mailop]

I think it's fair to say that there is "some" room for nuance on cold 
email, but the reason I don't allow it on my platform and I actively 
work to block companies that do, is simply this:


There is absolutely no one out there looking for help to send a cold 
email that isn't sending spam.


I mean if I see you and what you do and I think "We could really do 
something good together" I write you a personalized email, by hand, 
asking if you'd like to do business together. Is that spam? Of course 
not. But then there's what actually happens when someone needs help from 
a cold email company:


I collect a list of email addresses at companies that match a specific 
filter/business type, run a script to replace a variable with their 
name, and then blast out 4,000 duplicate emails with the old "spray and 
pray" technique. It's a numbers game, I don't care if you don't get back 
to me because I don't even know who you are. You were just part of a 
scraped list.


While the single, hand-typed cold email is fine, the automated cold 
email blast is spam. By merely saying "we want to help you send cold 
email" you're only focusing on the latter. Because when you're 
personally hand-writing a message to someone that you want to do 
business with, you don't need a service to help you do it.


On 2022-09-03 17:43, Radek Kaczynski via mailop wrote:

Good evening,

I feel like I need to come clean on the Bouncer - Woodpecker
association and my perspective on cold email.

(But please let me know if my responses are not welcome - I feel here
like a guest, and I don’t want to abuse your hospitality)

Long story short - when working for Mack Trucks, we had issues when an
email address was passed over the counter at the dealerships. Many
typos were affecting not only the continuity of communication but also
master data management and further processes down the road.
At the same time, I was going through a divorce and decided to move
back from the U.S. to Poland.
When I told my friend (CEO of Woodpecker) about it, he motivated me
and helped me to take a big step - quitting my corporate job and
starting Bouncer.

So I’m not directly associated with Woodpecker, but indeed there is
some connection between Bouncer and Woodpecker:
- Woodpecker’s CEO is my close friend from high school,
- He helped me establish Bouncer, when I decided to come back from the
U.S. to Poland,
- Some Woodpecker’s shareholders are also Bouncer’s shareholders,
- Woodpecker is one of Bouncer’s customers,
- We initially had offices in the same building.

If it comes to the cold email… I think it’s not that
black&white…

I personally am not a fan of cold email, and sometimes do get
irritated by the spammy one.

But I also see it sometimes as an equalizer - giving the same chances
when competing with global enterprises.
This way, small businesses can reach out to potentially interested
customers - which is very costly and very difficult in other
communication channels.
Small businesses can’t usually afford sophisticated marketing
funnels (full of Ads, LeadMagnets, Remarketing to get opt-in, and then
sharing the contact in the network of affiliates).
In a cold email, you don’t have to have huge budgets only because
your big competitors can afford high Customer Acquisition Costs.

But RESPECTFUL cold email is complicated and thus rare to see.
Cause respectful cold email is about:
- excellent prospecting- identifying those recipients that with a high
probability would like to see one offer
- well crafted and personalized copy (and by personalized, I don’t
mean “Hello {first_name},”)
- not intrusive and respectful sequence.

Kind Regards
Radek

P.S.
Bill, if I can be honest - it did hurt me when you wished me starving
on the street.
Especially as I do my best to be a decent human being.
Additionally, as a fresh father, I would hate for my baby daughter to
experience hunger because of my poor business decisions.
I do understand your frustration with what our services do, and I’m
sorry it causes hard feelings, but I hope it was just a rhetorical
figure.

P.P.S.
If any of you would like to get a full list of our IP addresses and
domains so that you can block Bouncer’s requests - please feel free
to email me at ra...@usebouncer.com.


Radoslaw Kaczynski | CEO of Bouncer

ul. Cypriana Kamila Norwida 24/1
50-374 Wrocław, Poland


Date: Fri, 02 Sep 2022 16:13:24 -0400
From: Bill Cole 
To: "Larry M. Smith via mailop" 
Subject: Re: [mailop] SMTP noise from *.bouncer.cloud
Message-ID:

Content-Type: text/plain; format=flowed

On 2022-09-02 at 14:16:25 UTC-0400 (Fri, 2 Sep 2022 18:16:25 +)
Larry M. Smith via mailop 
is rumored to have said:

On 8/31/2022, Bill Cole via mailop wrote:
(snip)
Who/what/where their clients are, and for what purpose of course, is

not likely something we will find out unless they like to share
m

Re: [mailop] SMTP noise from *.bouncer.cloud

[Carl Byington via mailop]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 2022-09-04 at 00:43 +0200, Radek Kaczynski via mailop wrote:
> If any of you would like to get a full list of our IP addresses and
> domains so that you can block Bouncer's requests - please feel free to
> email me at ra...@usebouncer.com.

Probably easier just to post it here.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYxPahxUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsHurwCfdx61FTKS+ojFTEWYHLsTfdaFBm4A
n2hadXNEhOVjlpeJfEt3o7TX6pf8
=5NsA
-END PGP SIGNATURE-


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Good evening,

I feel like I need to come clean on the Bouncer - Woodpecker association and my 
perspective on cold email.

(But please let me know if my responses are not welcome - I feel here like a 
guest, and I don’t want to abuse your hospitality)

Long story short - when working for Mack Trucks, we had issues when an email 
address was passed over the counter at the dealerships. Many typos were 
affecting not only the continuity of communication but also master data 
management and further processes down the road.
At the same time, I was going through a divorce and decided to move back from 
the U.S. to Poland.
When I told my friend (CEO of Woodpecker) about it, he motivated me and helped 
me to take a big step - quitting my corporate job and starting Bouncer.

So I’m not directly associated with Woodpecker, but indeed there is some 
connection between Bouncer and Woodpecker:
- Woodpecker’s CEO is my close friend from high school,
- He helped me establish Bouncer, when I decided to come back from the U.S. to 
Poland,
- Some Woodpecker’s shareholders are also Bouncer’s shareholders,
- Woodpecker is one of Bouncer’s customers,
- We initially had offices in the same building.

If it comes to the cold email… I think it’s not that black&white…

I personally am not a fan of cold email, and sometimes do get irritated by the 
spammy one.

But I also see it sometimes as an equalizer - giving the same chances when 
competing with global enterprises.
This way, small businesses can reach out to potentially interested customers - 
which is very costly and very difficult in other communication channels.
Small businesses can’t usually afford sophisticated marketing funnels (full of 
Ads, LeadMagnets, Remarketing to get opt-in, and then sharing the contact in 
the network of affiliates).
In a cold email, you don’t have to have huge budgets only because your big 
competitors can afford high Customer Acquisition Costs.

But RESPECTFUL cold email is complicated and thus rare to see.
Cause respectful cold email is about:
- excellent prospecting- identifying those recipients that with a high 
probability would like to see one offer
- well crafted and personalized copy (and by personalized, I don’t mean “Hello 
{first_name},”)
- not intrusive and respectful sequence.
 
Kind Regards
Radek

P.S.
Bill, if I can be honest - it did hurt me when you wished me starving on the 
street.
Especially as I do my best to be a decent human being.
Additionally, as a fresh father, I would hate for my baby daughter to 
experience hunger because of my poor business decisions.
I do understand your frustration with what our services do, and I’m sorry it 
causes hard feelings, but I hope it was just a rhetorical figure. 

P.P.S.
If any of you would like to get a full list of our IP addresses and domains so 
that you can block Bouncer’s requests - please feel free to email me at 
ra...@usebouncer.com.

Radoslaw Kaczynski | CEO of Bouncer
ul. Cypriana Kamila Norwida 24/1
50-374 Wrocław, Poland



> Date: Fri, 02 Sep 2022 16:13:24 -0400
> From: Bill Cole  <mailto:mailop-20160...@billmail.scconsult.com>>
> To: "Larry M. Smith via mailop" mailto:mailop@mailop.org>>
> Subject: Re: [mailop] SMTP noise from *.bouncer.cloud
> Message-ID:
><mailto:e2f16089-7098-4c69-8492-7ca158268...@billmail.scconsult.com>>
> Content-Type: text/plain; format=flowed
> 
> On 2022-09-02 at 14:16:25 UTC-0400 (Fri, 2 Sep 2022 18:16:25 +)
> Larry M. Smith via mailop mailto:mailop@fahq2.com>>
> is rumored to have said:
> 
>> On 8/31/2022, Bill Cole via mailop wrote:
>> (snip)
>>>> Who/what/where their clients are, and for what purpose of course, is 
>>>> not likely something we will find out unless they like to share 
>>>> more, but we can continue discussing this in terms of all the 
>>>> operators out there, and what constitutes the good vs the ugly.
>>> 
>>> Their intended service is the problem.
>>> 
>> 
>> Also at the same address physical address;
>> 
>> https://woodpecker.co/ <https://woodpecker.co/>
> 
> It's as if they live in a different reality... Where 'cold email' is not 
> intrinsically problematic.
> 
> The name only makes it worse.
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com <mailto:b...@scconsult.com> or billc...@apache.org 
> <mailto:billc...@apache.org>
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jarland Donnell via mailop]

I've seen precisely one thing on this list, on this topic, that I would 
classify as "bitching" and I'm replying to it.


On 2022-09-02 17:13, Christopher Hawker via mailop wrote:

Seems like a whole lot of bitching and whinging is going on here
regarding bouncer.cloud. Pretty sure this is a mail operations list,
not a “let’s whinge and complain about mail services” list.

It’s very simple - if you don’t like or want traffic from their
systems entering your network or servers, then blackhole their AS or
block the IPs and domains which they use. If you want to discuss their
services, take it off-list with whoever you choose.

CH.

Sent from my iPhone

On 3 Sep 2022, at 6:20 am, Bill Cole via mailop  
wrote:


On 2022-09-02 at 14:16:25 UTC-0400 (Fri, 2 Sep 2022 18:16:25 +)
Larry M. Smith via mailop 
is rumored to have said:


On 8/31/2022, Bill Cole via mailop wrote:
(snip)
Who/what/where their clients are, and for what purpose of course, 
is not likely something we will find out unless they like to share 
more, but we can continue discussing this in terms of all the 
operators out there, and what constitutes the good vs the ugly.


Their intended service is the problem.



Also at the same address physical address;

https://woodpecker.co/


It's as if they live in a different reality... Where 'cold email' is 
not intrinsically problematic.


The name only makes it worse.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Christopher Hawker via mailop]

Seems like a whole lot of bitching and whinging is going on here regarding 
bouncer.cloud. Pretty sure this is a mail operations list, not a “let’s whinge 
and complain about mail services” list.

It’s very simple - if you don’t like or want traffic from their systems 
entering your network or servers, then blackhole their AS or block the IPs and 
domains which they use. If you want to discuss their services, take it off-list 
with whoever you choose.

CH.

Sent from my iPhone

> On 3 Sep 2022, at 6:20 am, Bill Cole via mailop  wrote:
> 
> On 2022-09-02 at 14:16:25 UTC-0400 (Fri, 2 Sep 2022 18:16:25 +)
> Larry M. Smith via mailop 
> is rumored to have said:
> 
>> On 8/31/2022, Bill Cole via mailop wrote:
>> (snip)
 Who/what/where their clients are, and for what purpose of course, is not 
 likely something we will find out unless they like to share more, but we 
 can continue discussing this in terms of all the operators out there, and 
 what constitutes the good vs the ugly.
>>> 
>>> Their intended service is the problem.
>>> 
>> 
>> Also at the same address physical address;
>> 
>> https://woodpecker.co/
> 
> It's as if they live in a different reality... Where 'cold email' is not 
> intrinsically problematic.
> 
> The name only makes it worse.
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-09-02 at 14:16:25 UTC-0400 (Fri, 2 Sep 2022 18:16:25 +)
Larry M. Smith via mailop 
is rumored to have said:


On 8/31/2022, Bill Cole via mailop wrote:
(snip)
Who/what/where their clients are, and for what purpose of course, is 
not likely something we will find out unless they like to share 
more, but we can continue discussing this in terms of all the 
operators out there, and what constitutes the good vs the ugly.


Their intended service is the problem.



Also at the same address physical address;

https://woodpecker.co/


It's as if they live in a different reality... Where 'cold email' is not 
intrinsically problematic.


The name only makes it worse.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SMTP noise from *.bouncer.cloud

[Radek Kaczynski via mailop]

Hello Gentlemen,

First of all, Andreas - I'm sorry that traffic from our solution has confused 
you.

We are indeed providing email verification services ( 
https://www.usebouncer.com ( https://www.usebouncer.com/ ) ).

I do understand and fully respect your opinion about that kind of service.

And to be honest with you, should I know what I have learned so far, I probably 
would not start this company.

When I started it, I naively thought it was an excellent solution to the 
problem of mistyping/misspelling email addresses at the point of entry.

A one also that would have a small footprint - smaller than sending messages to 
undeliverable email addresses and then spending time, energy, and talent to 
recover the connection.

(I don't want to bother you with my story and beliefs, but I'll be happy to 
share if you're interested. )

But apparently, the more important use case is around cleaning lists of emails. 
The old business email lists are the ones that we want to help clean the most.

And we are trying to have as small a footprint as possible.

We are also doing our best not to support shady customers, however, in our 
case, it's difficult to tell what's good and evil, and I have some moral 
dilemmas too.

For example… should I prevent a sober alcoholic who wrote a book about getting 
out of addiction (a problem close to my heart) from verifying a list of 
potential NGOs who might help publish it?

There are more stories like that; usually, it's not that black or white.

But I know what we do and how we do it is still far from perfect; thus, I 
appreciate your feedback on what we should do to be more transparent and less 
abusive.

I have already passed to my team that we definitely have to put a redirect from 
bouncer.cloud ( http://bouncer.cloud/ ) to a page with our contact information 
so that folks like Andreas don't have to search for info about who we are.

We try to be as transparent as possible; thus, we use bouncer.cloud ( 
http://bouncer.cloud/ ) instead of thousands of cheap domains, and we don't 
hide our information, but I know we could do better.

I understand your position on not supporting what we do and blocking us, and I 
do respect it, as this is your full right. And I know it will be much easier 
for you to do so (knowing all our IPs and our domain) than doing this for most 
of our bigger competitors.

Kind Regard

Radek

P.S.

Sorry for bit chaotic message - as there are so many aspects I wanted to cover.

 __ ___ ___ ___

*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 )___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Larry M. Smith via mailop]

On 8/31/2022, Bill Cole via mailop wrote:
(snip)
Who/what/where their clients are, and for what purpose of course, is 
not likely something we will find out unless they like to share more, 
but we can continue discussing this in terms of all the operators out 
there, and what constitutes the good vs the ugly.


Their intended service is the problem.



Also at the same address physical address;

https://woodpecker.co/

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[John Levine via mailop]

It appears that Michael Peddemors via mailop  said:
>But I do of course understand the temptation to simply block them, if 
>you dont' know what they are doing.

I do know what they are doing, and I have no interest in helping them do it.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[WIlliam Fisher via mailop]

For those of us out of the loopwhat is this?



On 8/31/22 3:22 PM, Michael Peddemors via mailop wrote:
For the record, I should note in this thread, that in this case it is 
an actual company behind this (was reached out offlist by a principle) 
and many on the list are aware of this person.


https://www.linkedin.com/company/usebouncer/

Who/what/where their clients are, and for what purpose of course, is 
not likely something we will find out unless they like to share more, 
but we can continue discussing this in terms of all the operators out 
there, and what constitutes the good vs the ugly.


But I do of course understand the temptation to simply block them, if 
you dont' know what they are doing.


But of course recommended that they be more transparent, both in the 
use of IP space clearly indicating they are the operator (rwhois or 
SWIP) and the domain used should have an associated URL where contact 
information can be found.  Those recommendations would apply to all 
the AWS ones, and other companies equally.


-- Michael --



On 2022-08-31 10:15, Jarland Donnell via mailop wrote:
Nice find. Here's the IP list I pulled for them as well: 
https://clbin.com/Fr1IH


Probably not worth blocking by IP but some blacklistings might alert 
hosts to abusive behavior more than "yet another ignored abuse 
complaint."


On 2022-08-31 08:56, Michael Peddemors via mailop wrote:

Not just OVH, on LeaseWeb as well..

Script at least is sane, even though it simply does a RCPT TO, then
QUIT.  Suggest it is another email validator, or list washer.. without
transparency.

Aug 31 04:38:13 be msd[603032]: Linux Magic SMTPD started: connection
from 212.7.193.14 (192.168.0.118:25) Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: Created UUID
65a11bb8-2921-11ed-a12c-272390e3399e for message
Aug 31 04:38:13 be msd[603032]: CONN: 212.7.193.14 -> 25 GeoIP = [NL]
PTR = lw-mail-14.bouncer.cloud OS = Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: EHLO command received, args:
lw-mail-14.bouncer.cloud
Aug 31 04:38:13 be msd[603032]: MAIL command received, args:
FROM:
Aug 31 04:38:13 be msd[603032]: MAIL FROM address:
[hello@lw-mail-14.bouncer.cloud]
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: 
rfc_mail_from(hello@lw-mail-14.bouncer.cloud)

Aug 31 04:38:13 be msd[603032]: Done server-wide checks
Aug 31 04:38:13 be msd[603032]: RCPT command received (212.7.193.14),
args: TO:
Aug 31 04:38:13 be msd[603032]: from domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: helo domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: Looking up domain
lw-mail-14.bouncer.cloud (this may take a while)
Aug 31 04:38:14 be msd[603032]: Done server-wide checks
Aug 31 04:38:14 be msd[603032]: RCPT address [SNIPPED] is local
Aug 31 04:38:14 be msd[603032]: User spam rules loaded successfully
Aug 31 04:38:14 be msd[603032]: Doing domain-wide checks
Aug 31 04:38:14 be msd[603032]: Done domain-wide checks
Aug 31 04:38:14 be msd[603032]: User spam checking enabled
Aug 31 04:38:14 be msd[603032]: SPAM HIT: block_lists: 41
Aug 31 04:38:14 be msd[603032]: Adding flag for quarantine.
Aug 31 04:38:14 be msd[603032]: QUIT command received, args:
Aug 31 04:38:14 be msd[603032]: Session ending: Client issued QUIT
Aug 31 04:38:14 be msd[603032]: Exiting (bytes in: 118 out: 177)



On 2022-08-31 04:49, Andreas S. Kerber via mailop wrote:
Noticing lot's of noise from OVH adress ranges with "bouncer.cloud" 
PTR and HELO. Often they are trying only one recipient and seem to 
move on then.
Can anyone shed some light on what these people are trying to 
accomplish? Could there be any kind of legitimacy, or are just 
plain bad guys? Seems like a lot of effort to push spam this way 
and that's what's holding me back from blocking them..


SPF pass: ip=135.125.128.56, fqdn=de1-mail-173.bouncer.cloud, 
helo=de1-mail-173.bouncer.cloud, 
from=
SPF pass: ip=91.121.50.199, fqdn=sbg5-mail-160.bouncer.cloud, 
helo=sbg5-mail-160.bouncer.cloud, 
from=
SPF pass: ip=51.89.19.107, fqdn=de1-mail-35.bouncer.cloud, 
helo=de1-mail-35.bouncer.cloud, from=
SPF pass: ip=51.68.178.58, fqdn=de1-mail-5.bouncer.cloud, 
helo=de1-mail-5.bouncer.cloud, from=
SPF pass: ip=46.105.33.125, fqdn=sbg5-mail-141.bouncer.cloud, 
helo=sbg5-mail-141.bouncer.cloud, 
from=
SPF pass: ip=37.59.67.40, fqdn=sbg5-mail-37.bouncer.cloud, 
helo=sbg5-mail-37.bouncer.cloud, 
from=
SPF pass: ip=178.32.167.75, fqdn=sbg5-mail-150.bouncer.cloud, 
helo=sbg5-mail-150.bouncer.cloud, 
from=
SPF pass: ip=54.36.212.178, fqdn=sbg5-mail-147.bouncer.cloud, 
helo=sbg5-mail-147.bouncer.cloud, 
from=
SPF pass: ip=135.125.224.91, fqdn=de1-mail-233.bouncer.cloud, 
helo=de1-mail-233.bouncer.cloud, 
from=
SPF pass: ip=135.125.145.35, fqdn=de1-mail-185.bouncer.cloud, 
helo=de1-mail-185.bouncer.cloud, 
from=
SPF pass: ip=188.165.49.25, fqdn=sbg5-mail-27.bouncer.cloud, 

Re: [mailop] SMTP noise from *.bouncer.cloud

[Bill Cole via mailop]

On 2022-08-31 at 15:22:33 UTC-0400 (Wed, 31 Aug 2022 12:22:33 -0700)
Michael Peddemors via mailop 
is rumored to have said:

For the record, I should note in this thread, that in this case it is 
an actual company behind this (was reached out offlist by a principle) 
and many on the list are aware of this person.


I fail to comprehend how being an "actual company" makes the slightest 
difference. They exist for the purpose of abusive behaviors.



https://www.linkedin.com/company/usebouncer/


Not accessible.

I assume it's also .com?

Not a legitimate business. Hope they go broke and their principals and 
investors all starve in the street.



Who/what/where their clients are, and for what purpose of course, is 
not likely something we will find out unless they like to share more, 
but we can continue discussing this in terms of all the operators out 
there, and what constitutes the good vs the ugly.


Their intended service is the problem.

3rd-party address verification services are inherently bad for email. 
They are selling an intrinsicallky shoddy product that should not be 
available in any quality to anyone. No one who could find their 
'service' useful should be mailing anyone anything.


But I do of course understand the temptation to simply block them, if 
you dont' know what they are doing.


I understand what they are doing and will thwart/misinform/block them 
when and where I can. They are a net negative contributor to existence. 
A company with negative value, providing a service of negative value, to 
customers of negative value.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Michael Peddemors via mailop]

For the record, I should note in this thread, that in this case it is an 
actual company behind this (was reached out offlist by a principle) and 
many on the list are aware of this person.


https://www.linkedin.com/company/usebouncer/

Who/what/where their clients are, and for what purpose of course, is not 
likely something we will find out unless they like to share more, but we 
can continue discussing this in terms of all the operators out there, 
and what constitutes the good vs the ugly.


But I do of course understand the temptation to simply block them, if 
you dont' know what they are doing.


But of course recommended that they be more transparent, both in the use 
of IP space clearly indicating they are the operator (rwhois or SWIP) 
and the domain used should have an associated URL where contact 
information can be found.  Those recommendations would apply to all the 
AWS ones, and other companies equally.


-- Michael --



On 2022-08-31 10:15, Jarland Donnell via mailop wrote:
Nice find. Here's the IP list I pulled for them as well: 
https://clbin.com/Fr1IH


Probably not worth blocking by IP but some blacklistings might alert 
hosts to abusive behavior more than "yet another ignored abuse complaint."


On 2022-08-31 08:56, Michael Peddemors via mailop wrote:

Not just OVH, on LeaseWeb as well..

Script at least is sane, even though it simply does a RCPT TO, then
QUIT.  Suggest it is another email validator, or list washer.. without
transparency.

Aug 31 04:38:13 be msd[603032]: Linux Magic SMTPD started: connection
from 212.7.193.14 (192.168.0.118:25) Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: Created UUID
65a11bb8-2921-11ed-a12c-272390e3399e for message
Aug 31 04:38:13 be msd[603032]: CONN: 212.7.193.14 -> 25 GeoIP = [NL]
PTR = lw-mail-14.bouncer.cloud OS = Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: EHLO command received, args:
lw-mail-14.bouncer.cloud
Aug 31 04:38:13 be msd[603032]: MAIL command received, args:
FROM:
Aug 31 04:38:13 be msd[603032]: MAIL FROM address:
[hello@lw-mail-14.bouncer.cloud]
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: 
rfc_mail_from(hello@lw-mail-14.bouncer.cloud)

Aug 31 04:38:13 be msd[603032]: Done server-wide checks
Aug 31 04:38:13 be msd[603032]: RCPT command received (212.7.193.14),
args: TO:
Aug 31 04:38:13 be msd[603032]: from domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: helo domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: Looking up domain
lw-mail-14.bouncer.cloud (this may take a while)
Aug 31 04:38:14 be msd[603032]: Done server-wide checks
Aug 31 04:38:14 be msd[603032]: RCPT address [SNIPPED] is local
Aug 31 04:38:14 be msd[603032]: User spam rules loaded successfully
Aug 31 04:38:14 be msd[603032]: Doing domain-wide checks
Aug 31 04:38:14 be msd[603032]: Done domain-wide checks
Aug 31 04:38:14 be msd[603032]: User spam checking enabled
Aug 31 04:38:14 be msd[603032]: SPAM HIT: block_lists: 41
Aug 31 04:38:14 be msd[603032]: Adding flag for quarantine.
Aug 31 04:38:14 be msd[603032]: QUIT command received, args:
Aug 31 04:38:14 be msd[603032]: Session ending: Client issued QUIT
Aug 31 04:38:14 be msd[603032]: Exiting (bytes in: 118 out: 177)



On 2022-08-31 04:49, Andreas S. Kerber via mailop wrote:
Noticing lot's of noise from OVH adress ranges with "bouncer.cloud" 
PTR and HELO. Often they are trying only one recipient and seem to 
move on then.
Can anyone shed some light on what these people are trying to 
accomplish? Could there be any kind of legitimacy, or are just plain 
bad guys? Seems like a lot of effort to push spam this way and that's 
what's holding me back from blocking them..


SPF pass: ip=135.125.128.56, fqdn=de1-mail-173.bouncer.cloud, 
helo=de1-mail-173.bouncer.cloud, from=
SPF pass: ip=91.121.50.199, fqdn=sbg5-mail-160.bouncer.cloud, 
helo=sbg5-mail-160.bouncer.cloud, 
from=
SPF pass: ip=51.89.19.107, fqdn=de1-mail-35.bouncer.cloud, 
helo=de1-mail-35.bouncer.cloud, from=
SPF pass: ip=51.68.178.58, fqdn=de1-mail-5.bouncer.cloud, 
helo=de1-mail-5.bouncer.cloud, from=
SPF pass: ip=46.105.33.125, fqdn=sbg5-mail-141.bouncer.cloud, 
helo=sbg5-mail-141.bouncer.cloud, 
from=
SPF pass: ip=37.59.67.40, fqdn=sbg5-mail-37.bouncer.cloud, 
helo=sbg5-mail-37.bouncer.cloud, from=
SPF pass: ip=178.32.167.75, fqdn=sbg5-mail-150.bouncer.cloud, 
helo=sbg5-mail-150.bouncer.cloud, 
from=
SPF pass: ip=54.36.212.178, fqdn=sbg5-mail-147.bouncer.cloud, 
helo=sbg5-mail-147.bouncer.cloud, 
from=
SPF pass: ip=135.125.224.91, fqdn=de1-mail-233.bouncer.cloud, 
helo=de1-mail-233.bouncer.cloud, from=
SPF pass: ip=135.125.145.35, fqdn=de1-mail-185.bouncer.cloud, 
helo=de1-mail-185.bouncer.cloud, from=
SPF pass: ip=188.165.49.25, fqdn=sbg5-mail-27.bouncer.cloud, 
helo=sbg5-mail-27.bouncer.cloud, from=
SPF pass: ip=51.38.116.69, fqdn=de1-mail-1.bouncer.cloud, 
helo=de1-mai

Re: [mailop] SMTP noise from *.bouncer.cloud

[Jarland Donnell via mailop]

Nice find. Here's the IP list I pulled for them as well: 
https://clbin.com/Fr1IH


Probably not worth blocking by IP but some blacklistings might alert 
hosts to abusive behavior more than "yet another ignored abuse 
complaint."


On 2022-08-31 08:56, Michael Peddemors via mailop wrote:

Not just OVH, on LeaseWeb as well..

Script at least is sane, even though it simply does a RCPT TO, then
QUIT.  Suggest it is another email validator, or list washer.. without
transparency.

Aug 31 04:38:13 be msd[603032]: Linux Magic SMTPD started: connection
from 212.7.193.14 (192.168.0.118:25) Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: Created UUID
65a11bb8-2921-11ed-a12c-272390e3399e for message
Aug 31 04:38:13 be msd[603032]: CONN: 212.7.193.14 -> 25 GeoIP = [NL]
PTR = lw-mail-14.bouncer.cloud OS = Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: EHLO command received, args:
lw-mail-14.bouncer.cloud
Aug 31 04:38:13 be msd[603032]: MAIL command received, args:
FROM:
Aug 31 04:38:13 be msd[603032]: MAIL FROM address:
[hello@lw-mail-14.bouncer.cloud]
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: 
rfc_mail_from(hello@lw-mail-14.bouncer.cloud)

Aug 31 04:38:13 be msd[603032]: Done server-wide checks
Aug 31 04:38:13 be msd[603032]: RCPT command received (212.7.193.14),
args: TO:
Aug 31 04:38:13 be msd[603032]: from domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: helo domain country
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: Looking up domain
lw-mail-14.bouncer.cloud (this may take a while)
Aug 31 04:38:14 be msd[603032]: Done server-wide checks
Aug 31 04:38:14 be msd[603032]: RCPT address [SNIPPED] is local
Aug 31 04:38:14 be msd[603032]: User spam rules loaded successfully
Aug 31 04:38:14 be msd[603032]: Doing domain-wide checks
Aug 31 04:38:14 be msd[603032]: Done domain-wide checks
Aug 31 04:38:14 be msd[603032]: User spam checking enabled
Aug 31 04:38:14 be msd[603032]: SPAM HIT: block_lists: 41
Aug 31 04:38:14 be msd[603032]: Adding flag for quarantine.
Aug 31 04:38:14 be msd[603032]: QUIT command received, args:
Aug 31 04:38:14 be msd[603032]: Session ending: Client issued QUIT
Aug 31 04:38:14 be msd[603032]: Exiting (bytes in: 118 out: 177)



On 2022-08-31 04:49, Andreas S. Kerber via mailop wrote:
Noticing lot's of noise from OVH adress ranges with "bouncer.cloud" 
PTR and HELO. Often they are trying only one recipient and seem to 
move on then.
Can anyone shed some light on what these people are trying to 
accomplish? Could there be any kind of legitimacy, or are just plain 
bad guys? Seems like a lot of effort to push spam this way and that's 
what's holding me back from blocking them..


SPF pass: ip=135.125.128.56, fqdn=de1-mail-173.bouncer.cloud, 
helo=de1-mail-173.bouncer.cloud, 
from=
SPF pass: ip=91.121.50.199, fqdn=sbg5-mail-160.bouncer.cloud, 
helo=sbg5-mail-160.bouncer.cloud, 
from=
SPF pass: ip=51.89.19.107, fqdn=de1-mail-35.bouncer.cloud, 
helo=de1-mail-35.bouncer.cloud, from=
SPF pass: ip=51.68.178.58, fqdn=de1-mail-5.bouncer.cloud, 
helo=de1-mail-5.bouncer.cloud, from=
SPF pass: ip=46.105.33.125, fqdn=sbg5-mail-141.bouncer.cloud, 
helo=sbg5-mail-141.bouncer.cloud, 
from=
SPF pass: ip=37.59.67.40, fqdn=sbg5-mail-37.bouncer.cloud, 
helo=sbg5-mail-37.bouncer.cloud, 
from=
SPF pass: ip=178.32.167.75, fqdn=sbg5-mail-150.bouncer.cloud, 
helo=sbg5-mail-150.bouncer.cloud, 
from=
SPF pass: ip=54.36.212.178, fqdn=sbg5-mail-147.bouncer.cloud, 
helo=sbg5-mail-147.bouncer.cloud, 
from=
SPF pass: ip=135.125.224.91, fqdn=de1-mail-233.bouncer.cloud, 
helo=de1-mail-233.bouncer.cloud, 
from=
SPF pass: ip=135.125.145.35, fqdn=de1-mail-185.bouncer.cloud, 
helo=de1-mail-185.bouncer.cloud, 
from=
SPF pass: ip=188.165.49.25, fqdn=sbg5-mail-27.bouncer.cloud, 
helo=sbg5-mail-27.bouncer.cloud, 
from=
SPF pass: ip=51.38.116.69, fqdn=de1-mail-1.bouncer.cloud, 
helo=de1-mail-1.bouncer.cloud, from=
SPF pass: ip=178.33.42.186, fqdn=sbg5-mail-25.bouncer.cloud, 
helo=sbg5-mail-25.bouncer.cloud, 
from=
SPF pass: ip=51.89.47.230, fqdn=de1-mail-108.bouncer.cloud, 
helo=de1-mail-108.bouncer.cloud, 
from=


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and 
intended
solely for the use of the individual or entity to which they are 
addressed.
Please note that any views or opinions p

Re: [mailop] SMTP noise from *.bouncer.cloud

[John Levine via mailop]

It appears that Michael Peddemors via mailop  said:
>Not just OVH, on LeaseWeb as well..

They're obviously doing listwashing.  Nice of them to give us a reliable signal 
to block them.

2022-06-10 12:51:20.947844500 tcpserver: ok 4064 mail1.iecc.com:64.57.183.56:25 
de1-mail-178.bouncer.cloud:135.125.140.170::45197
2022-06-10 12:51:21.301446500 mailfront[4064]: ESMTP HELO 
de1-mail-178.bouncer.cloud
2022-06-10 12:51:21.461134500 mailfront[4064]: MAIL 
FROM:
2022-06-10 12:51:21.475629500 mailfront[4064]: assigned seq 697586005
2022-06-10 12:51:21.633353500 mailfront[4064]: RCPT 
TO:
2022-06-10 12:51:21.634123500 mailfront[4064]: 550 5.1.1 Sorry, that recipient 
does not exist.
2022-06-10 12:51:21.743825500 mailfront[4064]: bytes in: 132 bytes out: 330
2022-06-10 12:51:21.744883500 tcpserver: end 4064 status 0

2022-06-10 12:51:21.175035500 tcpserver: pid 4066 from 51.89.127.166
2022-06-10 12:51:21.630905500 tcpserver: ok 4066 mail1.iecc.com:64.57.183.56:25 
de1-mail-99.bouncer.cloud:51.89.127.166::52355
2022-06-10 12:51:21.883588500 mailfront[4066]: ESMTP HELO 
de1-mail-99.bouncer.cloud
2022-06-10 12:51:21.978857500 mailfront[4066]: MAIL 
FROM:
2022-06-10 12:51:21.987864500 mailfront[4066]: assigned seq 697586006
2022-06-10 12:51:22.170280500 mailfront[4066]: RCPT 
TO:
2022-06-10 12:51:22.276703500 mailfront[4066]: bytes in: 125 bytes out: 316
2022-06-10 12:51:22.277810500 tcpserver: end 4066 status 0

2022-06-10 12:51:21.388017500 tcpserver: pid 4068 from 5.196.98.237
2022-06-10 12:51:21.760790500 tcpserver: ok 4068 mail1.iecc.com:64.57.183.56:25 
sbg5-mail-44.bouncer.cloud:5.196.98.237::49129
2022-06-10 12:51:22.044963500 mailfront[4068]: ESMTP HELO 
sbg5-mail-44.bouncer.cloud
2022-06-10 12:51:22.140702500 mailfront[4068]: MAIL 
FROM:
2022-06-10 12:51:22.150948500 mailfront[4068]: assigned seq 697586007
2022-06-10 12:51:22.283755500 mailfront[4068]: RCPT 
TO:
2022-06-10 12:51:22.390697500 mailfront[4068]: bytes in: 127 bytes out: 316
2022-06-10 12:51:22.391747500 tcpserver: end 4068 status 0
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Michael Peddemors via mailop]

Not just OVH, on LeaseWeb as well..

Script at least is sane, even though it simply does a RCPT TO, then 
QUIT.  Suggest it is another email validator, or list washer.. without 
transparency.


Aug 31 04:38:13 be msd[603032]: Linux Magic SMTPD started: connection 
from 212.7.193.14 (192.168.0.118:25) Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: Created UUID 
65a11bb8-2921-11ed-a12c-272390e3399e for message
Aug 31 04:38:13 be msd[603032]: CONN: 212.7.193.14 -> 25 GeoIP = [NL] 
PTR = lw-mail-14.bouncer.cloud OS = Linux 2.2.x-3.x
Aug 31 04:38:13 be msd[603032]: EHLO command received, args: 
lw-mail-14.bouncer.cloud
Aug 31 04:38:13 be msd[603032]: MAIL command received, args: 
FROM:
Aug 31 04:38:13 be msd[603032]: MAIL FROM address: 
[hello@lw-mail-14.bouncer.cloud]

Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: 
rfc_mail_from(hello@lw-mail-14.bouncer.cloud)

Aug 31 04:38:13 be msd[603032]: Done server-wide checks
Aug 31 04:38:13 be msd[603032]: RCPT command received (212.7.193.14), 
args: TO:
Aug 31 04:38:13 be msd[603032]: from domain country 
code[lw-mail-14.bouncer.cloud] = "**"
Aug 31 04:38:13 be msd[603032]: helo domain country 
code[lw-mail-14.bouncer.cloud] = "**"

Aug 31 04:38:13 be msd[603032]: Doing server-wide checks
Aug 31 04:38:13 be msd[603032]: Looking up domain 
lw-mail-14.bouncer.cloud (this may take a while)

Aug 31 04:38:14 be msd[603032]: Done server-wide checks
Aug 31 04:38:14 be msd[603032]: RCPT address [SNIPPED] is local
Aug 31 04:38:14 be msd[603032]: User spam rules loaded successfully
Aug 31 04:38:14 be msd[603032]: Doing domain-wide checks
Aug 31 04:38:14 be msd[603032]: Done domain-wide checks
Aug 31 04:38:14 be msd[603032]: User spam checking enabled
Aug 31 04:38:14 be msd[603032]: SPAM HIT: block_lists: 41
Aug 31 04:38:14 be msd[603032]: Adding flag for quarantine.
Aug 31 04:38:14 be msd[603032]: QUIT command received, args:
Aug 31 04:38:14 be msd[603032]: Session ending: Client issued QUIT
Aug 31 04:38:14 be msd[603032]: Exiting (bytes in: 118 out: 177)



On 2022-08-31 04:49, Andreas S. Kerber via mailop wrote:

Noticing lot's of noise from OVH adress ranges with "bouncer.cloud" PTR and 
HELO. Often they are trying only one recipient and seem to move on then.
Can anyone shed some light on what these people are trying to accomplish? Could 
there be any kind of legitimacy, or are just plain bad guys? Seems like a lot 
of effort to push spam this way and that's what's holding me back from blocking 
them..

SPF pass: ip=135.125.128.56, fqdn=de1-mail-173.bouncer.cloud, 
helo=de1-mail-173.bouncer.cloud, from=
SPF pass: ip=91.121.50.199, fqdn=sbg5-mail-160.bouncer.cloud, 
helo=sbg5-mail-160.bouncer.cloud, from=
SPF pass: ip=51.89.19.107, fqdn=de1-mail-35.bouncer.cloud, 
helo=de1-mail-35.bouncer.cloud, from=
SPF pass: ip=51.68.178.58, fqdn=de1-mail-5.bouncer.cloud, 
helo=de1-mail-5.bouncer.cloud, from=
SPF pass: ip=46.105.33.125, fqdn=sbg5-mail-141.bouncer.cloud, 
helo=sbg5-mail-141.bouncer.cloud, from=
SPF pass: ip=37.59.67.40, fqdn=sbg5-mail-37.bouncer.cloud, 
helo=sbg5-mail-37.bouncer.cloud, from=
SPF pass: ip=178.32.167.75, fqdn=sbg5-mail-150.bouncer.cloud, 
helo=sbg5-mail-150.bouncer.cloud, from=
SPF pass: ip=54.36.212.178, fqdn=sbg5-mail-147.bouncer.cloud, 
helo=sbg5-mail-147.bouncer.cloud, from=
SPF pass: ip=135.125.224.91, fqdn=de1-mail-233.bouncer.cloud, 
helo=de1-mail-233.bouncer.cloud, from=
SPF pass: ip=135.125.145.35, fqdn=de1-mail-185.bouncer.cloud, 
helo=de1-mail-185.bouncer.cloud, from=
SPF pass: ip=188.165.49.25, fqdn=sbg5-mail-27.bouncer.cloud, 
helo=sbg5-mail-27.bouncer.cloud, from=
SPF pass: ip=51.38.116.69, fqdn=de1-mail-1.bouncer.cloud, 
helo=de1-mail-1.bouncer.cloud, from=
SPF pass: ip=178.33.42.186, fqdn=sbg5-mail-25.bouncer.cloud, 
helo=sbg5-mail-25.bouncer.cloud, from=
SPF pass: ip=51.89.47.230, fqdn=de1-mail-108.bouncer.cloud, 
helo=de1-mail-108.bouncer.cloud, from=

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SMTP noise from *.bouncer.cloud

[Andreas S. Kerber via mailop]

Noticing lot's of noise from OVH adress ranges with "bouncer.cloud" PTR and 
HELO. Often they are trying only one recipient and seem to move on then.
Can anyone shed some light on what these people are trying to accomplish? Could 
there be any kind of legitimacy, or are just plain bad guys? Seems like a lot 
of effort to push spam this way and that's what's holding me back from blocking 
them..

SPF pass: ip=135.125.128.56, fqdn=de1-mail-173.bouncer.cloud, 
helo=de1-mail-173.bouncer.cloud, from=
SPF pass: ip=91.121.50.199, fqdn=sbg5-mail-160.bouncer.cloud, 
helo=sbg5-mail-160.bouncer.cloud, from=
SPF pass: ip=51.89.19.107, fqdn=de1-mail-35.bouncer.cloud, 
helo=de1-mail-35.bouncer.cloud, from=
SPF pass: ip=51.68.178.58, fqdn=de1-mail-5.bouncer.cloud, 
helo=de1-mail-5.bouncer.cloud, from=
SPF pass: ip=46.105.33.125, fqdn=sbg5-mail-141.bouncer.cloud, 
helo=sbg5-mail-141.bouncer.cloud, from=
SPF pass: ip=37.59.67.40, fqdn=sbg5-mail-37.bouncer.cloud, 
helo=sbg5-mail-37.bouncer.cloud, from=
SPF pass: ip=178.32.167.75, fqdn=sbg5-mail-150.bouncer.cloud, 
helo=sbg5-mail-150.bouncer.cloud, from=
SPF pass: ip=54.36.212.178, fqdn=sbg5-mail-147.bouncer.cloud, 
helo=sbg5-mail-147.bouncer.cloud, from=
SPF pass: ip=135.125.224.91, fqdn=de1-mail-233.bouncer.cloud, 
helo=de1-mail-233.bouncer.cloud, from=
SPF pass: ip=135.125.145.35, fqdn=de1-mail-185.bouncer.cloud, 
helo=de1-mail-185.bouncer.cloud, from=
SPF pass: ip=188.165.49.25, fqdn=sbg5-mail-27.bouncer.cloud, 
helo=sbg5-mail-27.bouncer.cloud, from=
SPF pass: ip=51.38.116.69, fqdn=de1-mail-1.bouncer.cloud, 
helo=de1-mail-1.bouncer.cloud, from=
SPF pass: ip=178.33.42.186, fqdn=sbg5-mail-25.bouncer.cloud, 
helo=sbg5-mail-25.bouncer.cloud, from=
SPF pass: ip=51.89.47.230, fqdn=de1-mail-108.bouncer.cloud, 
helo=de1-mail-108.bouncer.cloud, from=

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop