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
