Print Page | Close Window

Web interface password emails not working

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
Printed Date: 18 January 2019 at 3:23pm

Topic: Web interface password emails not working
Posted By: RBarrow
Subject: Web interface password emails not working
Date Posted: 09 June 2011 at 3:25pm
Interesting issue...
Mails released from quarantine is delivered but clicking on send password does not send email to user?
Where do I look for this??

Posted By: yapadu
Date Posted: 09 June 2011 at 6:44pm
Messages release from quarantine are send from your spamfilter servers, messages for the web interface would be sent from your web-server.

You will need to test that your web-server is able to send email.

I am a user of SF, not an employee. Use any advice offered at your own risk.

Posted By: RBarrow
Date Posted: 10 June 2011 at 11:31am
This is a Windows 2008 server with IIS 7 and SMTP enabled...I have the SMTP pointed to our main SMTP server (which also is how the spamfilter pushs out) and still nothing.
Is there something I need to change in the .asp code to make it work with IIS 7?
The indians are coming off the reservation....Ouch

Posted By: RBarrow
Date Posted: 13 June 2011 at 10:33am
*** BUMP  ***

Posted By: RBarrow
Date Posted: 14 June 2011 at 9:34am
I guess there is no answer for this?  Anyone?

Posted By: RBarrow
Date Posted: 14 June 2011 at 11:29pm
OK.. it appears that the deliver from Quarantine isn't working properly either.  I found the Send Password function on the website simply adds a record to the quarantine table with the Deliver flag set to 1.
The software is supposed to blast that out just like it would blast out a quarantined email that was flagged for delivery.  I have a bunch of records in the table with the deliver flag set to 1 but they are NOT being delivered.
What is going on?  This is getting pretty bad response from my customers...and I need to get it resolved...

Posted By: yapadu
Date Posted: 15 June 2011 at 6:20am
Not sure what the issue might be, but check to confirm your install thinks it is registered.  The unregistered one does not release from quarantine.

I am a user of SF, not an employee. Use any advice offered at your own risk.

Posted By: RBarrow
Date Posted: 16 June 2011 at 11:35am

It shows as registered and I am running (but it was doing the same under .844 as well.

Is there a problem with the last few builds?

Posted By: RBarrow
Date Posted: 16 June 2011 at 11:41am
OK...I stand corrected once again.  Releases from the quarantine DO appear to work...but registration and password reminders ARE NOT working.  Both appear to work the same way from my review of the code:
1> Flagging a quarantined email to be sent changes the deliver flag to 1 (true)
2> A process runs in the app that sends the email.
In the case of the registration and password process, it appears to work in a similar fashion:
1> add a new record the quarantine table with delivery flag set to 1 (true)
2> and ????
confirmed the records ARE being added by the web registration process (and the password reminder part) and are setting there with the delivery flag turned on...but they never get processed.
Any ideas....????
PS - we just recently switched modes to the Enterprise case this makes any difference.

Posted By: RBarrow
Date Posted: 16 June 2011 at 11:54am
I downgraded to version 827 and things are NOW working.
So...maybe an issue with 844 and 845?

Posted By: LogSat
Date Posted: 20 June 2011 at 7:33pm

I apologize for not seeing this thread sooner, initially we mistakenly thought it was related to another 3rd party web admin tool, and thus we (wrongly) ignored it.

SpamFilter processes the deliver of password emails in the same way as when releasing items from the quarantine. As you correctly noticed, a password-reminder email is added to a new record the quarantine table with delivery flag set to 1 (true), and then it's delivered by SpamFilter. There should not be any differences between SpamFilter ISP "standard" and "Enterprise", nor between the older versions (827) and the latest ones (844 and 845).

There is no reason I can think of why this should work after downgrading, it's rather odd. If you'd like to zip us the log for one of the days you were using the new version and this process was not working, along with the recipient email address for one of the password emails recipient, we'll try to see if the logs have any records of what is happening.

Have you tried re-upgrading to the latest version to see if the issue persists? Also, have you by any chance migrated SpamFilter to a new server and/or renamed the server running SpamFilter? I ask because in installations with multiple SpamFilter servers, each SpamFilter server uses the "tblServers" table to locate messages that that specific SpamFilter server is responsible for. This is done via the field "ServerID". For each message in the quarantine, the ServerID field in the tblQuarantine must match the ServerID field in the tblServers, which in turn must match the tblServersServerID entry present in the SpamFilter.ini file. If the problem still occurs, If you are only running one SpamFilter in your environment, you could first of all try setting the value tblServersServerID=0 in the SpamFilter.ini file. We use the special value of "0" as sort of a wildcard, which allows that SpamFilter server to handle all the messages located in the tblQuarantine, even if they ServerIDs mismatch.

Roberto Franceschetti" rel="nofollow - LogSat Software" rel="nofollow - Spam Filter ISP

Print Page | Close Window