[Spamassassin Wiki] Update of "Rules/SPF_HELO_FAIL" by AndrewDaviel

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.

The "Rules/SPF_HELO_FAIL" page has been changed by AndrewDaviel:
http://wiki.apache.org/spamassassin/Rules/SPF_HELO_FAIL?action=diff&rev1=6&rev2=7

- ## page was copied from Rules/SPF_HELO_SOFTFAIL
+ ## page was copied from Rules/SPF_HELO_FAIL
  ## page was copied from Rules/SPF_SOFTFAIL
  ## page was copied from Rules/SPF_PASS
  ## page was copied from Rules/SPF_NEUTRAL
  #language en
- == SpamAssassin Rule: SPF_HELO_SOFTFAIL ==
+ == SpamAssassin Rule: SPF_HELO_FAIL ==
  
- ''Standard description:'' SPF: HELO does not match SPF record (softfail)
+ ''Standard description:'' SPF: HELO does not match SPF record (fail)
  
  
  === Explanation ===
@@ -17, +17 @@

  
  In a normal mail client, the HELO command uses the internet name of the computer sending the mail, so that someone might use their computer 1-2-3-dyn.bigisp.com to send mail through bigisp.com's mail relay, which has an SPF record indicating that that's allowed.
  
- ==== Soft Fail ====
+ ==== Fail ====
  
- A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
+ A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.
  
- 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.
+ If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see RFC 2821) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see RFC 3464), in addition to an appropriate reply text. The check_host() function may return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided by the sender's domain. For example: 
  
  From [[http://www.openspf.org/RFC_4408#op-result-softfail|RFC 4408]]