Hello James, Did you have a chance to check my questions? May I ask if you have any updates for me? _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship
> On 06/27/2025 11:50 AM EEST Daria Sydorenko <[email protected]> > wrote: > > > Got it, thank you so much. > > For clarity, are you redacting all properties of the contacts, but including > a proxy replacement for the e-mail property? > Yes. You can check the following output as an example: > https://rdap.spaceship.com/domain/srgrthrsthsrh.sbs > > So, did I understand correctly that we should treat our redaction method > (placing privacy service registration data instead of user PI) as a Removal > Method since it doesn't provide any useful information but acts as a > placeholder, yes? > > And we can scale this logic to other cases. For example, for GDPR, we can > redact all properties of the contact so they have the value "REDACTED" except > for the email address, which has contact-uri. > > In these cases, are we ok (in terms of RFCs) to call this redaction method > Removal? > Will it not be a mistake that the contact object is still present in the RDAP > output? > Do you think we should include any JSONPath (none of the "prePath", > "postPath", or "replacementPath" looks fully relevant in this case for me)? > _____________ > > Best regards, > Daria Sydorenko > Product Coordinator - Domains Compliance > Namecheap/Spaceship > > > > On 06/26/2025 6:22 PM EEST Gould, James > > <[email protected]> wrote: > > > > > > > > CAUTION: This email originated from outside the organization. Do not click > > links unless you can confirm the sender and know the content is safe. > > > > Daria, > > > > > > > > For clarity, are you redacting all properties of the contacts, but > > including a proxy replacement for the e-mail property? In that case, it > > would be overkill to include all the contact properties individually that > > are using the Removal Method. What I’m thinking is that it would be best > > to signal the client that the contacts by type are being redacted via the > > Removal Method and include the redaction of the contact email individually > > via the Replacement Method in the redaction extension. So, for the 4 > > contacts roles, there would be four object-level removal redaction entries > > and four field-level replacement redaction entries. I don’t believe it > > will make a difference whether there is a single entity with four roles or > > multiple entities with a single role. The following redacted names could > > be registered to use the name “type” field instead of the name > > “description” field: > > > > > > > > * “Registrant Contact” > > * “Administrative Contact” > > * “Tech Contact” > > * “Billing Contact” > > * “Administrative Email” > > * “Billing Email” > > > > > > > > The “Registrant Email” and “Tech Email” redacted names are already > > registered. > > > > > > > > This is my initial thought, but there could be other approaches from the > > working group to cover this use case. > > > > > > > > Thanks, > > > > > > > > -- > > > > > > > > JG > > > > > > [cid87442*[email protected]] > > > > James Gould > > Fellow Engineer > > [email protected] > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com http://verisigninc.com/ > > > > > > > > From: Daria Sydorenko <[email protected]> > > Date: Thursday, June 26, 2025 at 10:42 AM > > To: James Gould <[email protected]>, "[email protected]" > > <[email protected]>, "[email protected]" <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Subject: [EXTERNAL] Re: [regext] Re: Namecheap Inc. inquiry: RFC9537 > > implementation peculiarities > > > > > > > > Caution: This email originated from outside the organization. Do not click > > links or open attachments unless you recognize the sender and know the > > content is safe. > > > > I would also like to add some context and clarify my questions > > > > > > > > We gather 4 contacts for all gTLDs: Registrant, Technical, Administrative, > > Billing, and show all four in our RDAP. > > > > When the user adds the Privacy service for their domain name, there can be > > 2 main cases: > > > > > > > > 1) RDAP output has one entity with four roles. > > > > 2) RDAP output has several entities with their own roles (but the redacted > > values are the same for each entity). > > > > > > > > My questions are: > > > > - FOR CASE 2: > > > > can we reference the whole object (e.g. Registrant contact, Administrative > > contact, etc.) in the redacted member? > > > > - FOR CASE 1: > > > > can we reference the whole object only once if it has more than 1 role? > > > > > > > > - If no, can we reference the same field only once if it has different > > roles when such a field is redacted for all roles (given that the reason is > > the same - privacy service)? > > > > For example, in both use cases, we can redact registrant, admin, billing, > > and technical email using the same contact-uri with the same link. Can we > > reference this in the "redacted" member only once, or do we need to add > > each redacted field separately? > > > > _____________ > > > > > > > > Best regards, > > Daria Sydorenko > > Product Coordinator - Domains Compliance > > > > Namecheap/Spaceship > > > > > > > > > > > > On 06/26/2025 4:09 PM EEST Daria Sydorenko > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > Hello James, > > > > > > > > > > > > I went through your answers. Thank you for the detailed responses. > > > > > > > > > > > > I have a comment about q. #1: > > > > > > 1. We mainly use the redaction by ‘Replacement Value' method. We checked > > > that for the ‘Removal' method we can reference the whole object in the > > > 'redacted' member if all fields of that object are removed (e.g. Tech > > > contact). > > > > > > Can we do the same for the ‘Replacement Value’ method or do we need to > > > reference each redacted field separately in the ‘redacted’ member? > > > > > > JG- The reason that the “Removal Method” can reference a single redaction > > > element for a removed object is the redaction of the parent object > > > applies to all children as well. I’m not exactly sure what the child > > > members are being replaced with (e.g., proxy data, placeholder text). > > > The “Replacement Value Method” is a more specific redaction feature that > > > is meant to resolve to a useful value (e.g., anonymized email, web form). > > > Can you describe what form of replacement that you’re planning on using? > > > > > > > > > > > > We have the following use case within our RDAP: we utilize the Privacy > > > service. When a user enables our privacy service, we use redaction in the > > > RDAP response as shown below: > > > > > > "vcardArray": [ > > > "vcard", > > > [ > > > ["version", {}, "text", "4.0"], > > > ["fn", {}, "text", "Redacted for Privacy Purposes"], > > > ["org", {}, "text", "Privacy service provided by Withheld for Privacy > > > ehf"], > > > ["adr", { "cc": "IS" }, "text", ["", "", "Kalkofnsvegur 2", "Reykjavik", > > > "Capital Region", "101", ""]], > > > ["tel", { "type": ["voice"] }, "uri", "tel:+354.4212434"], > > > ["tel", { "type": ["fax"] }, "uri", "fax:"], > > > ["contact-uri", {}, "uri", > > > "https://www.spaceship.com/domains/whois/contact/?d=domain.com";] > > > ] > > > ] > > > > > > *The user chooses if the email should be replaced with the contact form > > > or an anonymized email. > > > > > > > > > > > > This approach complies with section 9.2.5 of ICANN's Registration Data > > > Policy, which states: "For Registered Names using an Affiliated or > > > Accredited Privacy or Proxy service, Registrar and Registry Operator MUST > > > Publish the full Registration Data of the Privacy or Proxy Service, which > > > MAY also include the existing privacy or proxy pseudonymized email." > > > > > > Following the policy, we don't remove the fields but replace them with > > > the Registration Data of the Privacy Service that we use. > > > > > > > > > > > > Given this, we believe that our approach is the 'Replacement Value' > > > Method for all fields. > > > > > > > > > > > > Do we need to list each replaced field individually in the redacted > > > member, applying specific logic for each one? As I see, for fn, for > > > example, we should use postPath child member, while for contact-uri, > > > prePath and replacementPath will be more suitable. > > > > > > > > > > > > Is there any option to reference the whole object in the "redacted" > > > member using the 'Replacement Value' method (for our use case) to > > > simplify RDAP output? > > > > > > > > > > > > Will be looking forward to your reply. > > > > > > _____________ > > > > > > > > > > > > Best regards, > > > Daria Sydorenko > > > Product Coordinator - Domains Compliance > > > > > > Namecheap/Spaceship > > > > > > > > > > > > > > > > > On 06/25/2025 9:28 PM EEST Gould, James > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > CAUTION: This email originated from outside the organization. Do not > > > > click links unless you can confirm the sender and know the content is > > > > safe. > > > > > > > > Hi, > > > > > > > > > > > > > > > > My feedback is embedded below, prefixed with “JG-“. Let me know if you > > > > have any additional questions. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > JG > > > > > > > > > > > > [cid87442*[email protected]] > > > > > > > > James Gould > > > > Fellow Engineer > > > > [email protected] > > > > > > > > 703-948-3271 > > > > 12061 Bluemont Way > > > > Reston, VA 20190 > > > > > > > > Verisign.com > > > > http://secure-web.cisco.com/1haCjyo7cl-91kyQ3VqfMki8w3kzHOAPlPtm9QAiIdvwjwA9FRm_pn0xE8O2nvC85ySBtrEY2TIFUivKRpmef_rDqItysXxAQe4kZ_whseY_AtF7Xc62MCHyuXitoYG8771RzjLXCOkNnLmyWtPT4AZ_OBV4wFX5BEn8i_gqWW2s4PHiJLHMQJisrZwm6yJpcdqZoUIU0Jv7Nt8G3qIn2bsnx7HUSGUzDDwhbTSu89QLuaLZjfPlxK13R6O31c23dsMG5b7mA1G5xPv7ApCfJkUdjlGFbzdCYaTTjcUKe2QM/http%3A%2F%2Fverisigninc.com%2F > > > > > > > > > > > > > > > > From: Daria Sydorenko <[email protected]> > > > > Date: Wednesday, June 25, 2025 at 11:59 AM > > > > To: Marc Blanchet <[email protected]>, "[email protected]" > > > > <[email protected]> > > > > Cc: Ksenia Chuprina <[email protected]> > > > > Subject: [EXTERNAL] [regext] Re: Namecheap Inc. inquiry: RFC9537 > > > > implementation peculiarities > > > > > > > > > > > > > > > > Caution: This email originated from outside the organization. Do not > > > > click links or open attachments unless you recognize the sender and > > > > know the content is safe. > > > > > > > > Hello team, > > > > > > > > > > > > > > > > Could you please let us know if any information is already available to > > > > cover our question? > > > > > > > > > > > > > > > > We are looking forward to a response from you. > > > > > > > > _____________ > > > > > > > > > > > > > > > > Best regards, > > > > Daria Sydorenko > > > > Product Coordinator - Domains Compliance > > > > > > > > Namecheap/Spaceship > > > > > > > > > > > > > > > > > > > > > > On 05/27/2025 2:33 PM EEST Ksenia Chuprina > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Marc, > > > > > > > > > > Thank you for passing my query to the working group. > > > > > > > > > > We appreciate your efforts on RDAP, and if it helps you can use our > > > > > Spaceship RDAP Production environment with .ote domain names for > > > > > tests, e.g. > > > > > https://rdap.spaceship.com/domain/xn--20001013-01-75066601--1726844587268632-17da086aa.work.ote > > > > > > > > > > https://secure-web.cisco.com/1wAdhc-t6b80KYiMW36BTSlLCmW---iTyvBcNggJl2mU2j1eZyC4utpleca_1foyJCebEy4vQhhn-8534cBwPXtnSvrp7Opop9WAd3ATJ68EwLroOjRREg6Nnttv1bDe7C8Uu9hYhEKYg5AlZ4nxcKGIALvZVY6nK6FsBu7UVun3wVmtaXwvWf4RN5ArDidUHwwrQ1cMTA6XpKreC7SDudNb__umuFSce8ZQmlRcBiFp7q4CTx3Gz8aN-TgRjk6XrwlSIBBwVdbmu2LuU5_BiqlElCSou0-46spDfYVAmeJ8/https%3A%2F%2Frdap.spaceship.com%2Fdomain%2Fxn--20001013-01-75066601--1726844587268632-17da086aa.work.ote > > > > > > > > > > > > > > > This is the only approach we can currently suggest. And just for you > > > > > to know, we have not yet upgraded to the RDAP 2024 version. Should > > > > > that suit you, let me know, and I will provide a few more .ote domain > > > > > names. > > > > > > > > > > Have a wonderful one ahead! > > > > > > > > > > > > > > > > > On 05/26/2025 3:45 PM EEST Marc Blanchet > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > CAUTION: This email originated from outside the organization. Do > > > > > > not click links unless you can confirm the sender and know the > > > > > > content is safe. > > > > > > > > > > > > Hello, > > > > > > > > > > > > I’ll let the wg respond to your query. I’m writing to you because > > > > > > I’m the author of the RDAP Browser mobile app (iOS and Android). > > > > > > I’m working on a major update of both versions which will include > > > > > > Redacted. (I was one pushing for a better solution than just random > > > > > > strings saying no data here). If you have any test > > > > > > server/infrastructure that would contain the real data but in a > > > > > > non-production mode, and interested in interop testing, let’s talk! > > > > > > > > > > > > > > > > > > > > > > > > Regards, Marc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Le 22 mai 2025 à 13:10, Ksenia Chuprina > > > > > > > <[email protected]> a écrit : > > > > > > > > > > > > > > Greetings Team, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am a Business Analyst at Namecheap Inc, a Domain Registrar. > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are currently working on the upgrade of our RDAP to the > > > > > > > version 2024 and we have questions about entities redaction. We > > > > > > > reached ICANN, but they have forwarded us to you. Hope you can > > > > > > > help us with that: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. We mainly use the redaction by ‘Replacement Value' method. We > > > > > > > checked that for the ‘Removal' method we can reference the whole > > > > > > > object in the 'redacted' member if all fields of that object are > > > > > > > removed (e.g. Tech contact). > > > > > > > > > > > > > > Can we do the same for the ‘Replacement Value’ method or do we > > > > > > > need to reference each redacted field separately in the > > > > > > > ‘redacted’ member? > > > > > > > > > > > > > > JG- The reason that the “Removal Method” can reference a single > > > > > > > redaction element for a removed object is the redaction of the > > > > > > > parent object applies to all children as well. I’m not exactly > > > > > > > sure what the child members are being replaced with (e.g., proxy > > > > > > > data, placeholder text). The “Replacement Value Method” is a > > > > > > > more specific redaction feature that is meant to resolve to a > > > > > > > useful value (e.g., anonymized email, web form). Can you > > > > > > > describe what form of replacement that you’re planning on using? > > > > > > > > > > > > > > 1. Many child members of the ‘redacted’ member are marked as > > > > > > > ‘optional’ in the RFC9537 > > > > > > > https://secure-web.cisco.com/1K-p06XuKlGkEPkvNLd0CFFLUUAXdJvZoYGuBloQH1ApcgRqEbkz8m8SpOaM6pGOYMixPweHL9Z57jsGmMpRUGGWCyxEfc2aQOh5NmeeCB_DG9ZdQmnbkBsqbJrt2IqCI5e8CSwdL3hglT8F-EVT1SUESR9il3jDd_IvAacOc9cPEfi9w9JNEHFK5KdrrH4_n4FQ07bBvuC6PDhT242rqiRiQ8R_n2fJu7sswGT-n1WRKMnCFNn6k-Ddwb-Jq9Q3Hih9judqi7GBZOX0HRJIIHkNZr26lnJbBk6Him5VKwYA/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9537.html%23name-redaction-by-removal-method. > > > > > > > > > > > > > > Is it totally up to us whether to include them or not, or do they > > > > > > > become obligatory on a certain condition? > > > > > > > > > > > > > > In particular, we have doubts about ‘postPath’ and ‘method’ > > > > > > > members when using the ‘Replacement Value’ redaction method, but > > > > > > > it would be best to know the approach to all members. > > > > > > > > > > > > > > JG – The only required member is the “name” member and the > > > > > > > “method” member, where the “method” member has an implied default > > > > > > > value of “removal” when not provided. There are some normative > > > > > > > MUST and MUST NOTs defined in the RFC that covers specific use > > > > > > > cases, but in general it’s flexible to work for your redaction > > > > > > > needs. > > > > > > > > > > > > > > 1. In the ‘name’ member of the ‘redacted’ member, can we always > > > > > > > use the ‘description’ field or is it a must to use the ‘type’ > > > > > > > field for the registered redacted names? > > > > > > > > > > > > > > JG – There is no normative requirement to use the “type” field > > > > > > > when there is a registered redacted name, but I do recommend it. > > > > > > > The client will get more meaning with the use of a pre-registered > > > > > > > value as opposed to a custom value with the “description” field. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the latter is the case, where do we find the ‘registered > > > > > > > redacted names’? Are those the Values in the Appendix E of the > > > > > > > RDAP Response Profile > > > > > > > https://secure-web.cisco.com/1OIQ1ZznOOEGtb9TYBIlQtBSByoZ5yuTqoBGyrcwX5aUcLxkij4yFFgKevwKXbnXdNshnMAhX6VjrhSyLZidXV8R1TDjkUDFuax_2LVzwsw10fR3oTtKku871_UijCmMb8ESUs1gPIqR2dyDZah20jOPkaE5gLYnMxOJdosUnL_1zoXDcagAAU3ac9WdQTKPBzuq9JDmGM13RCSdSkV87_S48CV85ZnlI00XB4aQOtozWu9HJSFxifNa12mUUdua0HtfJLiDIglguaUCDNZlyMFNbl0TIrf4fU6EfXNSRK1g/https%3A%2F%2Fvalidator.rdap.org%2Fspecs%2Fgtld%2F2024-02%2Frdap-response-profile-21feb24-en.pdf%23page%3D16? > > > > > > > > > > > > > > JG – You can find the registered redacted names in the RDAP JSON > > > > > > > Values IANA Registry > > > > > > > (https://www.iana.org/assignments/rdap-json-values > > > > > > > https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-json-values) > > > > > > > using the Type value of “redacted name”. These were registered > > > > > > > when the RDAP Response Profile was completed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > FYI We checked that we will have more contact sets/fields than > > > > > > > covered in the Appendix, and also such values as ‘Registrant > > > > > > > contact’ to reference the whole object are absent in it, that’s > > > > > > > why we are wondering if we can always stick to the ‘description’ > > > > > > > field. > > > > > > > > > > > > > > JG-As noted earlier, the use of the “type” field is better than > > > > > > > using the “description” field, since the client will be able to > > > > > > > better understand its meaning. If you see the need for more > > > > > > > generic registered redacted name values, then you can go through > > > > > > > the process defined in Section 10.2 of RFC 9083 to register them > > > > > > > in the RDAP JSON Values registry > > > > > > > (https://www.iana.org/assignments/rdap-json-values > > > > > > > https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-json-values) > > > > > > > referencing the Type “redacted name”. My recommendation is to > > > > > > > leverage the “type” field for all registered redacted name > > > > > > > values, register any new generic redacted name in the RDAP JSON > > > > > > > Values registry > > > > > > > (https://www.iana.org/assignments/rdap-json-values > > > > > > > https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-json-values) > > > > > > > and use the “type” field, and finally use the “description” > > > > > > > field for custom redacted name values. > > > > > > > > > > > > > > 1. Do we get this right that we can choose either ‘type’ or > > > > > > > ‘description’ field In the reason member of the ‘redacted’ > > > > > > > member, or are they both required? Where can we find the list of > > > > > > > ‘registered redacted reasons’? > > > > > > > We saw Registries using ‘Server policy’ as a reason, is that okay > > > > > > > to use that by default? > > > > > > > > > > > > > > JG – Yes, the same pattern is followed for the “reason” member as > > > > > > > with the “name” member, where it’s better to use a “type” field > > > > > > > if there is a registered redacted reason and use the > > > > > > > “description” field otherwise. There are currently no registered > > > > > > > redacted reason values in the RDAP JSON Values registry > > > > > > > (https://www.iana.org/assignments/rdap-json-values > > > > > > > https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Frdap-json-values), > > > > > > > which can be addressed by going through the process defined in > > > > > > > Section 10.2 of RFC 9083 to register them in the RDAP JSON Values > > > > > > > registry referencing the Type “redacted reason”. The > > > > > > > registration of the “Server policy” redacted reason makes logical > > > > > > > sense. > > > > > > > > > > > > > > Looking forward to hearing from you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Ksenia Chuprina > > > > > > > Business Analyst > > > > > > > BA&P Department > > > > > > > > > > > > > > Namecheap Inc. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > regext mailing list -- [email protected] > > > > > > > To unsubscribe send an email to [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Ksenia Chuprina > > > > > Business Analyst > > > > > BA&P Department > > > > > > > > > > Namecheap Inc. > > > > > > > > > > > > > > >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
