[Gnso-ppsai-pdp-wg] Question

Tue Aug 5 10:53:36 UTC 2014

Don

I mentioned something about this on the call last week as well..

If you got a bounce or other message from my mail server you'd know a lot more about me than I might like you to know .. ie. it would be a "reveal"

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.co/
http://blog.blacknight.com/
http://www.technology.ie
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

-----Original Message-----
From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Don Blumenthal
Sent: Monday, August 04, 2014 1:49 PM
To: Luc SEUFER; GBarnett at sgbdc.com
Cc: gnso-ppsai-pdp-wg at icann.org
Subject: Re: [Gnso-ppsai-pdp-wg] Question

David Cake (I think that's who it was anyway) raised an issue that I don't see in this thread. Using different words:

Should we be concerned whether a forwarded bounce may serve as a partial, or even complete, reveal?

More fundamentally in this case, and as something to think about in general as we go forward, process discussions can be important when deciding what's feasible from a policy standpoint. However, we should keep the dividing line between policy and implementation in mind. In this case, if we decide that a submitter should know about bounces, can we just say that or do we also need to get into notification methods?

Talk to you tomorrow.

Don 

-----Original Message-----
From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Luc SEUFER
Sent: Monday, August 4, 2014 5:18 AM
To: GBarnett at sgbdc.com
Cc: gnso-ppsai-pdp-wg at icann.org
Subject: Re: [Gnso-ppsai-pdp-wg] Question

Hi Griffin et al.,

I may be missing something here, but knowing that not every mail provider/service is returning an error message in case an email hasn't been delivered, I don't think this WG is the place to try to define and create a new obligation on every RNH. The RAA only requires the RNH email address to be accurate in the sense that it's formatted accordingly to RFC 5322 and to pass the verification test define under 1.f.i. of the Whois Accuracy Program Specification.
This test only requires RNH to evidence receipt of its registrar verification email via an authentication method.

Thus, why would RNHs that recourse to the service of a P/P provider be obliged to have an email service providing this functionality and how/who would ensure compliance with this new obligation?

As previously mentioned, I see no objection that an error message be passed to the so-called requestors if there is one returned by the RNH email service provider, but this should in no case be turned into an obligation for the RNH/Registrar/P/P provider.

Luc

On 02 Aug 2014, at 00:20, GBarnett at sgbdc.com<mailto:GBarnett at sgbdc.com> wrote:

Kathy,

I think it would depend on whether the sender was notified of the bounce-back.  If the sender was notified of the bounce-back, which appeared to be a "non-receipt" bounce-back but was in fact  a "delayed receipt" bounce-back, the sender would presume that the re-verification process would be triggered, and would likely wait the 15-day re-verification period before proceeding with any follow-up or potential next step (or attempt, in that intervening time, to determine whether re-verification was successful by checking the domain name, etc.).

If the sender was never notified either way,  it would probably attempt to re-send the communication or otherwise follow up regardless of whether a re-verification was taking place.

I'm not sure, from a technical standpoint, whether your proposed scenario would occur, or if there wouldn't be a way of determining one type of bounce-back from the other and only communicating the non-receipt bounce-backs back to the sender.  I think what's key is that there is the initial communication to the sender if the relay doesn't happen "normally," to avoid the "initial redundancy" problem I identified.

I hope I've understood your question correctly! Have a nice weekend.

Best,

Griffin
_ _

Griffin M. Barnett
Silverberg, Goldman & Bikoff, LLP
1101 30th Street NW
Suite 120
Washington, DC 20007
(202) 944-3307
gbarnett at sgbdc.com<x-msg://6/gbarnett@sgbdc.com>
________________________________
From: gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>] on behalf of Kathy Kleiman [kathy at kathykleiman.com<mailto:kathy at kathykleiman.com>]
Sent: Friday, August 01, 2014 5:16 PM
To: gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: Re: [Gnso-ppsai-pdp-wg] Question

Griffin,
Quick question - if there is a bounceback indicating non-receipt where in fact it is really delayed receipt, how could and would that be processed by the sender?
Best,
Kathy
:
Volker and all,

Just a few thoughts on this subject--

The re-verification process is supposed to take place within 15 days under the 2013 RAA (3.7.7.2), but assuming for whatever reason the P/P provider is not also the registrar for the domain name, it may take longer than that to notify the registrar and then re-verify the customer/registrant contact info (I suppose it might also take less time, depending on the process and the responsiveness of the customer).  But potentially, it could take a fairly long time to re-verify.  During this time, the original complainant who has submitted a communication to be relayed to the P/P customer would simply not know whether its communication was (a) received by the P/P provider itself (although that part would probably be presumed) or (b) forwarded successfully (i.e. without an "undeliverable" notice) to the P/P customer.

Informing the complainant of a bounce-back would be a simple mechanism for preventing redundant follow-up submissions by the same complainant trying to reach the same customer.  In other words, if the P/P provider informed the complainant of abounce-back (perhaps in conjunction with initiating its own next step in the required re-verification process), this would preventthe complainant from sending, and the P/P provider from receiving, unnecessary/futile follow-ups in the intervening re-verification period.

Then, once re-verified, the P/P provider could just relay the single original communication.  Overall, it would seem to me thatone simple notice back to the complainant (and again, only in the event where the relay is unsuccessful and the P/P provider receives a bounce-back email associated with that attempt), would save time and headache for both complainants and P/Pproviders.

In the non-proxy context, a complainant would directly receive the bounce-back notification; I see no reason why a complainant should not be equally informed when there is a proxy intermediary.

Just my two cents on this issue, and look forward to further discussion on the subject.  Enjoy the weekend!

-Griffin

Griffin M. Barnett
Silverberg, Goldman & Bikoff, LLP
1101 30th Street NW
Suite 120
Washington, DC 20007
(202) 944-3307
gbarnett at sgbdc.com<x-msg://6/UrlBlockedError.aspx>

_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

________________________________

--------------------------------------------------------

This e-mail and any attached files are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please notify the sender immediately and delete it from your system. You must not copy the message or disclose its contents to anyone.

Think of the environment: don't print this e-mail unless you really need to.

--------------------------------------------------------
_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg