You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by Apache Wiki <wi...@apache.org> on 2012/04/27 20:20:46 UTC

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

Dear Wiki user,

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

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

- 2.5.2. Neutral
+ #language en
+ == SpamAssassin Rule: SPF_NEUTRAL ==
+ 
+ ''Standard description:'' SPF: sender does not match SPF record (neutral)
+ 
+ === Explanation ===
+ 
+ SPF ([[http://www.openspf.org|Sender Policy Framework]])
+ is an open standard specifying a technical method to prevent sender address forgery. The sender's domain is matched against a list of allowed mail relays for that domain. This states, for example, that mail from someone@example.com should have come via mail.example.com and not mail.badguys.info.
+ 
+ This often breaks where users have forwarded their email to another domain, but the forwarding mechanism is not SPF-aware. Such a user would see SPF_FAIL tags on some of their incoming mail.
+ 
+ ==== Neutral ====
  
  The domain owner has explicitly stated that he cannot or does not want to assert whether or not the IP address is authorized. 
  A "Neutral" result MUST be treated exactly like the "None" result; the distinction exists only for informational purposes. 
  Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1).
  
  
- 
- From http://www.openspf.org/RFC_4408#op-result-neutral
+ From [[http://www.openspf.org/RFC_4408#op-result-neutral|RFC 4408]]
  
  
- 2.5.5. SoftFail
+ === Further Info ===
  
+ The default scores for this rule can be found [[http://spamassassin.apache.org/tests.html|in the online list of tests]].
- 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.
  
- 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.
+ ----
+ CategoryRule
  
- 2.5.1. None
- 
- no records were published by the domain or  no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized.
- 
- 2.5.4. Fail
- 
- explicit statement that the client is not authorized to use the domain in the given identity.
-