On 08/30/2012 07:45 PM, Rajesh M wrote:
Hi all,

One of my customers is having an issue with emails being incorrectly
classified as spam by SpamAssassin. They are using a 3rd party site with
a form to handle registrations from customers. The form is configured to
send the mail to a specific user on their domain (in this case lets call
that [email protected])...the form is also setup so that the From and
reply-to addresses point to whatever email addresss the user filling out
the form inputs.

I can see in my spamdyke logs that those messages are originating from
skyride.digiknows.com, so I went ahead and tried whitelisting that
address in spamdyke for the whitelist_senders list, but where I'm having
problems is that spamassassin is still classifying the mail as spam. I
tried whitelist_from *@skyride.digiknows.com as well as
whitelist_from_rcvd (not sure if I fully understand how this one works
though).

Running the latest release of QMT/QTP.

Here is a snippet from my local.cf

ok_locales all
skip_rbl_checks 1

required_score 5
report_safe 0
rewrite_header Subject [SPAM] SA1

use_pyzor 1

use_auto_whitelist 1

bayes_path /home/vpopmail/.spamassassin/bayes
use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1
bayes_auto_learn_threshold_spam 6.5
bayes_auto_learn_threshold_nonspam 0.1
bayes_auto_expire 1
loadplugin Mail::SpamAssassin::Plugin::URIDNSBL

score FH_DATE_PAST_20XX 0.0

# Rule2XSBody - speedup by compilation of rulseset to native code
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

trusted_networks 69.7.35.11 69.7.35.25 69.7.35.131 69.7.35.42

whitelist_from *@skyride.digiknow.com
whitelist_from_rcvd *@skyride.digiknow.com skyride.digiknow.com
whitelist_allows_relays [email protected]


Anyone have any ideas?

Thanks!

--
Casey James Price

Smile Global Technical Support
Submit or check trouble tickets http://billing.smileglobal.com
www.smileglobal.com <http://www.smileglobal.com>

Follow us on Twitter <https://twitter.com/#%21/SmileInternet>
Find us on Facebook <https://www.facebook.com/smileglobal>


hi,

we also had a similar issue where our website was on server A and
qmailtoaster ie email service for the same website was on server B.

the issue is that the email form generally connects the smtp server on the
same machine ie server A for sending out emails which is the problem
because qmail toaster starts applying spamassassin rules to it.

what you need to do is -- in your email form put the ip address of your
server B ie the actual email server, carry out smtp authentication and
then send the email. make sure that you connect on the submission port ie
port 587 in the stock qmail toaster for this purpose so that spamassassin
would not be used at all once you authenticate.


---- sample ----

<?php
require_once "/usr/share/pear/Mail.php";
require_once "/usr/share/pear/Mail/mime.php";


date_default_timezone_set('Asia/Calcutta');
$dt = date(DATE_RFC2822);

$from = "test <[email protected]>";
$to = "test1<[email protected]>";
$subject = "Hi!";
$body = "Hi,\n\nHow are you?";
$port = "587";
$host = "xxx.xxx.xxx.xxx";
$username = "[email protected]";
$password = "xxxxx";

$headers = array ('From' => $from,
   'To' => $to,
'Date' => $dt,
   'Subject' => $subject);
$smtp = Mail::factory('smtp',
   array ('host' => $host,
     'port' => $port,
     'auth' => true,
     'username' => $username,
     'password' => $password));

$mail = $smtp->send($to, $headers, $body);

if (PEAR::isError($mail)) {
   echo("<p>" . $mail->getMessage() . "</p>");
  } else {
   echo("<p>Message successfully sent!</p>");
  }
?>


---- sample ----


give this a try. if you still face any issues let me know.

rajesh








---------------------------------------------------------------------

Very good advice here. Authenticated sessions bypass SpamAssassin entirely.

If that cannot be done for some reason, the RELAYCLIENT variable can be set in tcp.smtp for a specific IP address. This is less desirable, as it's less secure and requires maintenance should the address of the web host change.

You should be able to adjust SA rules as well, as you've attempted to do. You need to look at the message headers to determine which rules are firing, causing the message to score above your threshold. There's likely some content that's triggering a combination of rules. I'm not familiar off hand with SA whitelisting, so I can't say why your configuration for that isn't quite working.

Clevelandmetroparks, eh? My nephews are playing Big Met this morning. Wish I was there. :(


--
-Eric 'shubes'




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to