Obtain redacted evidence of successor-address routing #13

Open
opened 2026-10-20 21:40:25 +00:00 by phg · 0 comments
Owner

Part of #1

Question

Obtain the missing Congress checkout and mail-delivery evidence needed to decide whether prevouch can reliably route successor vouchers through application-owned return addresses.

This is a HITL prerequisite task, surfaced by Establish Congress voucher replication and incoming-email evidence. The public documentation and supplied email do not establish the exact recipient field or alias preservation. The researcher could not inspect an authorized checkout or identify a known parent/successor pair.

Apply the seller-direct ticket-access requirement from Define central-purchase workflow and fulfillment: identify the ticket holder's email separately from any buyer/contact email and the successor-recipient field. Verify whether ticket-access email can go directly to each holder while successor vouchers go to the separate prevouch return address. The purchase workflow is settled in that decision; this task supplies seller-specific evidence of address behavior.

The person with legitimate access should provide one of the following evidence paths:

  1. A redacted existing checkout/order capture showing the successor-recipient field label, its relationship to the buyer/contact email, its default when blank, and whether it can be changed before replication; or equivalent issuer configuration/source that establishes these facts.
  2. For routing validation, a known predecessor/successor pair with a distinct application return address and a trusted inbound envelope-recipient record showing whether the intended alias survived delivery or forwarding. Redaction must preserve the relationship using consistent placeholders while removing voucher codes, personal addresses, order secrets, and redeem links.

Record the event/year and voucher class, what was directly observed, and any remaining gaps. An existing authorized example or issuer configuration is sufficient; the task does not authorize buying tickets, redeeming vouchers, changing a live order, or contacting organizers. Ordinary email To/X-Original-To headers alone cannot establish the controlled ingress boundary.

Resolve when the evidence has been inspected and a sanitized artifact or precise observation record is linked from the resolution comment. Leave the routing/trust policy to Choose successor routing and incoming-voucher trust rules. If access is unavailable, keep this task open and record the exact missing prerequisite; do not invent the field or assume arrival order proves lineage.

Part of #1 ## Question Obtain the missing Congress checkout and mail-delivery evidence needed to decide whether prevouch can reliably route successor vouchers through application-owned return addresses. This is a HITL prerequisite task, surfaced by [Establish Congress voucher replication and incoming-email evidence](https://git.s1q.dev/MISChaufen/prevouch/issues/2). The public documentation and supplied email do not establish the exact recipient field or alias preservation. The researcher could not inspect an authorized checkout or identify a known parent/successor pair. Apply the seller-direct ticket-access requirement from [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15): identify the ticket holder's email separately from any buyer/contact email and the successor-recipient field. Verify whether ticket-access email can go directly to each holder while successor vouchers go to the separate prevouch return address. The purchase workflow is settled in that decision; this task supplies seller-specific evidence of address behavior. The person with legitimate access should provide one of the following evidence paths: 1. A redacted existing checkout/order capture showing the successor-recipient field label, its relationship to the buyer/contact email, its default when blank, and whether it can be changed before replication; or equivalent issuer configuration/source that establishes these facts. 2. For routing validation, a known predecessor/successor pair with a distinct application return address and a trusted inbound envelope-recipient record showing whether the intended alias survived delivery or forwarding. Redaction must preserve the relationship using consistent placeholders while removing voucher codes, personal addresses, order secrets, and redeem links. Record the event/year and voucher class, what was directly observed, and any remaining gaps. An existing authorized example or issuer configuration is sufficient; the task does not authorize buying tickets, redeeming vouchers, changing a live order, or contacting organizers. Ordinary email To/X-Original-To headers alone cannot establish the controlled ingress boundary. Resolve when the evidence has been inspected and a sanitized artifact or precise observation record is linked from the resolution comment. Leave the routing/trust policy to [Choose successor routing and incoming-voucher trust rules](https://git.s1q.dev/MISChaufen/prevouch/issues/6). If access is unavailable, keep this task open and record the exact missing prerequisite; do not invent the field or assume arrival order proves lineage.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
MISChaufen/prevouch#13
No description provided.