Sender Policy Framework

back

Description

The softfail result may cause automatic report. See thread.gmane.org for previous discussions on this idea.

Rationale

The use of softfail is described by RFC4408 as follows

The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time.

We can enforce that feedback directly from the receiving server.

Functioning

A receiving MTA that gets a softfail result MAY lookup the RP RR type (Responsible Person, see RFC 1183) for the name _spf_softfail.domain., where domain is the label of the SPFv3 record being examined. If the RP is found and has an mbox-dname entry, and the receiving MTA accepts the message, it MAY send a copy of the headers (including new SPF-Received) of the message wrapped as ARF to the address thus found.

Note

That would require the addition of a Feedback Type Name of spf-softfail in the IANA section.