550 5.7.1 Sender ID (PRA) Not Permitted.

Posted on September 21, 2014 • 4 min read • 733 words
Bounce Spf Sender ID Postmaster

Some of the emails I send are bounced back to me with a 'SMTP diagnostic: 550 5.7.1 Sender ID (PRA) Not Permitted' error message. What does it mean and what can I do about it?

Warning. This article contains technical information about how email communications work and about some email security considerations. Although the problem outlined here can be successfully addressed, please read this fully to understand its causes and the implications of the different solutions provided.

Sender ID is an anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.

Sender ID tries to improve on a principal deficiency in SPF: that SPF does not verify the header addresses that indicates the sending party. Such header addresses are typically displayed to the user and are used to reply to emails. Indeed such header addresses can be different from the address that SPF tries to verify; that is, SPF verifies only the 'MAIL FROM' address, also called the envelope sender.

However there are many similar email header fields that all contain sending party information; therefore Sender ID defines in RFC 4407 a Purported Responsible Address (PRA) as well as a set of heuristic rules to establish this address from the many typical headers in an email.

What has this to do with my problem

In essence, in addition to verifying the 'MAIL FROM' address, a mail server running Sender ID may also check whether the IP address from which we deliver your email matches the SPF records for the header address. In case your domain has a Hardfail SPF record defined without listing our IP addresses, your email will be rejected as illegitimate.

What can I do to solve this problem

There are several things you can do:

  • List our IP range in your SPF record. By doing so, your SPF record will still protect others from spoofed emails pretending to be yours, whilst allowing us to be a legitimate source for the emails you send. Contact Support for instructions.
  • Switch your SPF record from Hardfail to Softfail. By doing so, an email coming from our IPs may still look suspicious to others, but it will be up to the recipient's mail server to decide whether to accept it as legitimate or not.
  • Ask us to take action. This Sender ID drawback does not only affect us, but also any forwarder and mailing list sending emails on behalf of others. Being aware of this, Sender ID had to provide some way to identify as legitimate any email being legitimately forwarded by others. And there is: Sender ID proposes that we add a line to the email header, informing the recipient's mail server that we are resending an email we've received from you. This solution will certainly do the trick: as quoted bellow (from the Wikipedia), however, it is not clear within the Internet community whether it conflicts with the Simple Mail Transfer Protocol standard. For this reason, we will only apply this solution upon demand and only when no other alternatives can be applied.

Standardization issues

The pra has the disadvantage that forwarders and mailing lists can only support it by modifying the mail header, e.g. insert a Sender or Resent-Sender. The latter violates RFC 2822 and can be incompatible with RFC 822.

With SPF, mailing lists continue to work as is. Forwarders wishing to support SPF only need to modify SMTP MAIL FROM and RCPT TO, not the mail. That's no new concept; with the original RFC 821 SMTP forwarders always added their host name to the reverse path in the MAIL FROM.

The most problematic point in the core Sender ID specification is its recommendation to interpret v=spf1 policies like spf2.0/mfrom,pra instead of spf2.0/mfrom.

This was never intended by all published SPF drafts since 2003, and for an unknown large number of v=spf1 policies an evaluation for pra could cause bogus results for many cases where pra and mfrom are different.

This technical problem — in fact only four characters ,pra in the core Sender ID specification — was the base of an appeal to the Internet Architecture Board (IAB). In response to another prior appeal the IESG already noted that Sender ID cannot advance on the IETF standards track without addressing the incompatibility with a MUST in RFC 2822.

Most of the content of this article has been taken from the Wikipedia. For further reading, please visit the Wikipedia article about Sender ID.