What is PRA ?

Thursday, August 06, 2009 - 12:09 - Support

What Is It.
The "Purported Responsible Address" (PRA) is used in an attempt to find who is the actual email sender using a set method of deriving the PRA from the actual message headers. The method I have used is defined in the draft "Internet Engineering Task Force" (IETF) document "MTA Authentication Records in DNS June 2004"

Where Can I Read More.
The latest copy of the document should be available Here.

You can also find a lot more about this sort of thing Here.

The Specification I Used.
The purported responsible address (PRA) of a message is determined by the following algorithm:

1. Locate the first non-empty Resent-Sender header in the message. If no such header is found, proceed to step 2. If it is preceded by a non-empty Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header, proceed to step 2. If the Resent-Sender header is hopelessly malformed (e.g. it appears to contain multiple mailboxes, or if the single mailbox is hopelessly malformed) then exit, without returning a PRA. Otherwise exit, returning the mailbox from the Resent-Sender header as the PRA.

2. Locate the first non-empty Resent-From header in the message. If no such header is found, proceed to step 3. If it is hopelessly malformed (e.g. one or more mailboxes in the header are hopelessly malformed) then exit without returning a PRA. If it contains multiple mailboxes, then exit without returning a PRA. Otherwise exit, returning the single mailbox from the Resent-From header as the PRA.

3. Locate the first non-empty Delivered-To, X-Envelope-To or Envelope-To header in the message. If no such header is present, proceed to step 4. If it appears to contain multiple mailboxes, then exit without returning a PRA. Otherwise, treat the contents of the header as a mailbox, and exit returning this mailbox as the PRA (unless the mailbox is hopelessly malformed, in which case exit without returning a PRA).

[Note. This means that a non-standard header that does *not* contain a single valid mailbox will cause the PRA algorithm to fail and may cause the message to be rejected. But anything else means that the process doing the MARID checks might make a different decision as to the validity of the mailbox from a subsequent MUA which attempts to display the purported responsible address by parsing the headers. Maybe it would be better to drop this step, and go back to only considering RFC(2)822 headers?] Lyon, Wong Expires - December 2004 [Page 6] MTA Authentication Records in DNS June 2004

4. Locate all the non-empty Sender headers in the message. If there are no such headers, continue to step 5. If there are multiple such headers, exit without returning a PRA. If the single non-empty Sender header is hopelessly malformed (e.g. if it appears to contain multiple mailboxes, or if the single mailbox is hopelessly malformed), exit without returning a PRA. Otherwise, exit returning the mailbox from the Sender header as the PRA.

5. Locate all the non-empty From headers in the message. If there are no such headers, or multiple such headers, exit without returning a PRA. If the single non-empty From header is hopelessly malformed (e.g. it contains one or more mailboxes that are hopelessly malformed) then exit without returning a PRA. If it contains multiple mailboxes, exit without returning a PRA. Otherwise, return the single mailbox from the From header as the PRA.