I¹ll also see if we are tracking/counting this stat. Another helpful data point might be how many ³bounces² are later resolved, meaning the delivery failure was a temporary situation that was later corrected. This could be important if a relay obligation were framed in terms of ³unsuccessful delivery after X attempts or within Y business days² or something similar. Thanks‹ J. On 7/29/14, 10:42 , "Graeme Bunton" <gbunton@tucows.com> wrote:

That's a good question Kathy, I'll see if I can dig some stats up from our systems.

Graeme _________________________ Graeme Bunton Manager, Management Information Systems Manager, Public Policy Tucows Inc. PH: 416 535 0123 ext 1634

-----Original Message----- From: gnso-ppsai-pdp-wg-bounces@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of Kathy Kleiman Sent: Tuesday, July 29, 2014 11:32 AM To: Metalitz, Steven; gnso-ppsai-pdp-wg@icann.org Subject: [Gnso-ppsai-pdp-wg] Question

Hi Steve and Alex, Good discussion today - much appreciated. Quick note: I can certainly understand the desire to know if an email went through. Quick question: do you have any idea how many "bouncebacks" we are talking about? In today's environment, with the current forwarding work by proxy/privacy providers, do you have any idea how many messages are undeliverable vs. how many may be received but not responded to? I know each messages is important, but are we talking about a high percentage or a very low percentage?

Tx, Kathy _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

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

David It's defined in the RFC as: "Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days" See: https://www.ietf.org/rfc/rfc2821.txt Of course that's an RFC, so while *most* mail servers might work that way there's no guarantee that they all will 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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of David Cake Sent: Tuesday, July 29, 2014 6:20 PM To: James M. Bladel Cc: gnso-ppsai-pdp-wg@icann.org Subject: Re: [Gnso-ppsai-pdp-wg] Question It used to be the standard practice was that mail servers would continue trying to deliver for four days. Regards David On 29 Jul 2014, at 6:15 pm, James M. Bladel <jbladel@godaddy.com> wrote: I¹ll also see if we are tracking/counting this stat. Another helpful data point might be how many ³bounces² are later resolved, meaning the delivery failure was a temporary situation that was later corrected. This could be important if a relay obligation were framed in terms of ³unsuccessful delivery after X attempts or within Y business days² or something similar. Thanks< J. On 7/29/14, 10:42 , "Graeme Bunton" <gbunton@tucows.com> wrote: That's a good question Kathy, I'll see if I can dig some stats up from our systems. Graeme _________________________ Graeme Bunton Manager, Management Information Systems Manager, Public Policy Tucows Inc. PH: 416 535 0123 ext 1634 -----Original Message----- From: gnso-ppsai-pdp-wg-bounces@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of Kathy Kleiman Sent: Tuesday, July 29, 2014 11:32 AM To: Metalitz, Steven; gnso-ppsai-pdp-wg@icann.org Subject: [Gnso-ppsai-pdp-wg] Question Hi Steve and Alex, Good discussion today - much appreciated. Quick note: I can certainly understand the desire to know if an email went through. Quick question: do you have any idea how many "bouncebacks" we are talking about? In today's environment, with the current forwarding work by proxy/privacy providers, do you have any idea how many messages are undeliverable vs. how many may be received but not responded to? I know each messages is important, but are we talking about a high percentage or a very low percentage? Tx, Kathy _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

Well, when that happens, the service has to contact the registrant (or if impossible another involved party) and request an update of the underlying data. Anything beyond that is not required at this time. Why should the original sender have a right to be informed about a bounce if the data is later fixed? Volker Am 31.07.2014 17:55, schrieb Alex_Deacon@mpaa.org:

Thats right.

We are getting into the weeds here but when the “sender” (SMTP server in the context Michele provided below) finally gives up it will send a hard bounce back to the address in From: or Reply-To: header.

When this happens the service has X days (2 days based on the recent thread) to process the message and notify the original sender of the bounce.

Alex

On Jul 30, 2014, at 1:46 AM, Michele Neylon - Blacknight <michele@blacknight.com> wrote:

...

David

It's defined in the RFC as:

"Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days"

See: https://www.ietf.org/rfc/rfc2821.txt

Of course that's an RFC, so while *most* mail servers might work that way there's no guarantee that they all will

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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of David Cake Sent: Tuesday, July 29, 2014 6:20 PM To: James M. Bladel Cc: gnso-ppsai-pdp-wg@icann.org Subject: Re: [Gnso-ppsai-pdp-wg] Question

It used to be the standard practice was that mail servers would continue trying to deliver for four days.

Regards David

On 29 Jul 2014, at 6:15 pm, James M. Bladel <jbladel@godaddy.com> wrote:

I¹ll also see if we are tracking/counting this stat. Another helpful data point might be how many ³bounces² are later resolved, meaning the delivery failure was a temporary situation that was later corrected. This could be important if a relay obligation were framed in terms of ³unsuccessful delivery after X attempts or within Y business days² or something similar.

Thanks<

J.

On 7/29/14, 10:42 , "Graeme Bunton" <gbunton@tucows.com> wrote:

That's a good question Kathy, I'll see if I can dig some stats up from our systems.

Graeme _________________________ Graeme Bunton Manager, Management Information Systems Manager, Public Policy Tucows Inc. PH: 416 535 0123 ext 1634

-----Original Message----- From: gnso-ppsai-pdp-wg-bounces@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of Kathy Kleiman Sent: Tuesday, July 29, 2014 11:32 AM To: Metalitz, Steven; gnso-ppsai-pdp-wg@icann.org Subject: [Gnso-ppsai-pdp-wg] Question

Hi Steve and Alex, Good discussion today - much appreciated. Quick note: I can certainly understand the desire to know if an email went through. Quick question: do you have any idea how many "bouncebacks" we are talking about? In today's environment, with the current forwarding work by proxy/privacy providers, do you have any idea how many messages are undeliverable vs. how many may be received but not responded to? I know each messages is important, but are we talking about a high percentage or a very low percentage?

Tx, Kathy _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

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

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

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

---

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

-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

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@sgbdc.com

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

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@sgbdc.com<mailto:GBarnett@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@sgbdc.com<x-msg://6/gbarnett@sgbdc.com> ________________________________ From: gnso-ppsai-pdp-wg-bounces@icann.org<mailto:gnso-ppsai-pdp-wg-bounces@icann.org> [gnso-ppsai-pdp-wg-bounces@icann.org<mailto:gnso-ppsai-pdp-wg-bounces@icann.org>] on behalf of Kathy Kleiman [kathy@kathykleiman.com<mailto:kathy@kathykleiman.com>] Sent: Friday, August 01, 2014 5:16 PM To: gnso-ppsai-pdp-wg@icann.org<mailto:gnso-ppsai-pdp-wg@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@sgbdc.com<x-msg://6/UrlBlockedError.aspx> _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org<mailto:Gnso-ppsai-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org<mailto:Gnso-ppsai-pdp-wg@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. --------------------------------------------------------

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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of Don Blumenthal Sent: Monday, August 04, 2014 1:49 PM To: Luc SEUFER; GBarnett@sgbdc.com Cc: gnso-ppsai-pdp-wg@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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of Luc SEUFER Sent: Monday, August 4, 2014 5:18 AM To: GBarnett@sgbdc.com Cc: gnso-ppsai-pdp-wg@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@sgbdc.com<mailto:GBarnett@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@sgbdc.com<x-msg://6/gbarnett@sgbdc.com> ________________________________ From: gnso-ppsai-pdp-wg-bounces@icann.org<mailto:gnso-ppsai-pdp-wg-bounces@icann.org> [gnso-ppsai-pdp-wg-bounces@icann.org<mailto:gnso-ppsai-pdp-wg-bounces@icann.org>] on behalf of Kathy Kleiman [kathy@kathykleiman.com<mailto:kathy@kathykleiman.com>] Sent: Friday, August 01, 2014 5:16 PM To: gnso-ppsai-pdp-wg@icann.org<mailto:gnso-ppsai-pdp-wg@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@sgbdc.com<x-msg://6/UrlBlockedError.aspx> _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org<mailto:Gnso-ppsai-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org<mailto:Gnso-ppsai-pdp-wg@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg