Talk:Frequently Asked Questions

From ASSPSMTP

Should we split the article into sections such as Features, Troubleshooting, Installation etc? --Geniusfreak

Probably, it should eventually be split up. Right now, I try to put in as many FAQs that I can think of (generally when I have my own questions that need answering) to at least populate it, and then hopefully down the road, be able to start classifying questions. --Eric B. 21:04, 6 December 2006 (MST)

I also agree that it should be split into TOC'd sections, if not separate articles. TOC'd sections would be a good start. If no one beats me to it, I'll do something this weekend. --ME2 16:02, 8 December 2006 (MST)

---

Q: How do you submit a false-postive / false-negative reports?

A: False-positive & False-negative reports are done by email. The ASSP email interface must be enabled to allow for this. Once the email interface is enabled, any emails sent to the Report Spam Address (asspspam by default) will be considered a false-negative report. Any email sent to Report not-Spam Address (asspnotspam by default) will be considered a false-positive report. ASSP will automatically process emails sent to these addresses at any of your local domains, so make sure that you don't use an address that already exists at one of your local domains.

Q: Should users email false-positive reports to asspnotspam only, or should they also add them to whitelists?

A: This is debatable. Some people believe it is better to report false-positives only to asspnotspam, but others feel that if a user is sending non-spam email, might as well add them to the whitelist. There is an additional setting in the Email Interface options called Spam/Ham Report & Whitelist Add/Remove which will automatically add any user to the whitelist when reported as ham, and will remove a spam reported user from the whitelist if he/she exists.

One important consideration to remember; all email received from someone on the whitelist is automatically copied into the notspam part of the corpus. This may have consequences for you if your users decide to report emails as nonspam and have them added to the whitelist. Any subsequent emails from that sender will automatically be added to the notspam corpus. This could be problematic for things like email lists, automated newsletters, etc, which may have advertising/spam contained within them, thereby corrupting your corpus. A potentially better solution would be to add such types of emails to either a NoProcessing list (so that they are completely ignored by ASSP), or to the redlist so that ASSP can at least process the content, ensuring that it isn't spam, but not save it to the corpus.

Q: What possible spam reason will ASSP report in the email headers?

A: This is not necessarily a complete list. Possible reasons are:

• X-Assp-Spam-Reason: Has spam address
• X-Assp-Spam-Reason: Validate Sender: Invalid HELO Format
• X-Assp-Spam-Reason: Bayesian spam
• X-Assp-Spam-Reason: Validate Sender: PTR missing
• X-Assp-Spam-Reason: BombRe:
• X-Assp-Spam-Reason: Validate Sender: missing MX/A record
• X-Assp-Spam-Reason: Failed RBL checks
• X-Assp-Spam-Reason: Has blacklisted domain
• X-Assp-Spam-Reason: Failed SPF checks
• X-Assp-Spam-Reason: Failed URIBL checks
• X-Assp-Spam-Reason: Failed URIBL checks (maximum unique domain uris exceeded)
• X-Assp-Spam-Reason: BombHeaderRe: 'Headerlength (xxlengthxx) > 10000'
• X-Assp-Spam-Reason: PB:LV1 blocked - score:xscorex (xxxreasonxxx)