[Gnso-ppsai-pdp-wg] Question

[GBarnett at sgbdc.com]

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
________________________________
From: gnso-ppsai-pdp-wg-bounces at icann.org [gnso-ppsai-pdp-wg-bounces at icann.org] on behalf of Kathy Kleiman [kathy at kathykleiman.com]
Sent: Friday, August 01, 2014 5:16 PM
To: 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<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140801/f5c51072/attachment-0001.html>