How to use an unverified reporter contact email

An email typed into a website report is a possible route for follow-up, not proof of who sent the report. Use it only for a narrow, relevant message. Do not use it to authorize account changes or disclose private records. In IssueProbe, reporter contact email is optional and unverified; the website owner decides whether to follow up manually. IssueProbe does not email that address or send the draft response.

Separate contact from identity

A visitor can enter an address they control, mistype it, or enter someone else's address. The presence of the field does not distinguish those cases. Even a later reply does not by itself establish authority over a website account.

Keep three questions separate:

• What happened? The report and approved evidence describe an observed problem or suggestion.
• Where could you ask a question? The contact address offers a possible destination.
• Who may receive private information or change an account? Your normal authenticated account process must answer that question.

For example, a report that says an invoice download failed can justify checking the download behavior. It does not justify attaching an invoice to an email sent to the supplied address. Send the person through your established authenticated support process if the next step requires account-specific information.

Decide whether a follow-up adds value

Read the report before contacting anyone. A message is useful when it can clarify one missing fact or communicate a reviewed next step. It is not useful merely because an address is present.

| Situation | Safer next step | |---|---| | One reproduction step is missing | Ask one question about the action, without requesting private values. | | The evidence supports only a possible cause | Describe the uncertainty; do not present a diagnosis as established. | | The visitor asks for an account change | Use your normal authenticated account process. | | No contact address was provided | Continue the report review without promising an individual reply. | | The address appears mistaken or the recipient says the report is not theirs | Stop that follow-up rather than sending more report detail. |

A missing address does not make a report unusable. Clear actions, expected behavior, and observed behavior still help an owner investigate. The guide to writing a useful website problem report explains that factual core.

Ask for observations, not secrets

A good clarification question narrows the behavior you need to check. It should not turn a short report into a request for a private data export.

Useful questions include:

• Did the error appear before or after you selected Save?
• Did the button stay disabled, or could you select it again?
• Did the same action work after you opened the page again?

Do not request a password, authentication code, cookie value, access token, payment value, or full request body. Avoid asking someone to forward their entire browser storage or an unreviewed screenshot. A screenshot can contain private information even when the written report does not.

IssueProbe's browser-state evidence contains only names, presence states, and sizes. Network evidence excludes query values, headers, and bodies. Manual follow-up should not casually undo those limits. Consult the widget privacy rules when deciding what context is appropriate.

Review the draft before using your own mail client

An investigation draft is a proposal, not a sent message. Before copying it into a manual reply, check each sentence against what you actually know.

1. Remove private source paths, repository excerpts, and account details.
2. Match the wording to the conclusion status and its unknown facts.
3. Remove any promise of a release date you cannot support.
4. Do not say the problem is fixed before verification.
5. Keep the message about this report, not a newsletter or unrelated promotion.

For a clarification request, a neutral opening might be:

We received a website problem report with this contact address. If you sent it, did the error appear before or after you selected Save? Please do not send passwords or private account information.

This is an illustrative template, not a customer quote or an IssueProbe email. Adapt it to the report and avoid adding sensitive details that could reach the wrong person.

Know where IssueProbe shows the address

IssueProbe stores the optional contact email separately from browser evidence and normalizes it to lowercase. Lowercase storage does not verify ownership or correct a typing mistake.

Only an authorized human or an agent with reports:read can see the address, and only on report detail. It is absent from report lists and public receipts. It does not enter investigation context or the report notification webhook payload.

Saving an owner draft does not send email. Adding an owner note does not send a visitor message. Recording a disposition does not send the draft either. These are separate review actions, described in the disposition guide and the API reference.

IssueProbe is a website report investigator, not a help desk or a conversation thread. If you choose to follow up, you use your own communication channel and remain responsible for what you disclose.

Keep the review record useful without copying contact data

Record the technical observation or decision that matters to the next reviewer. A note such as “Still missing whether the error appeared before Save” is more useful than copying the contact address into another field.

Keep identity checks in your established account process. Keep private account records out of visitor-facing drafts. Keep the report decision separate from any manual conversation. That separation lets you continue investigating a useful report without treating an unverified address as authority.