Hi there, I've tried to send this email to you several times but it keeps bouncing back?? Please can you help me with the problem outlined below, Many thanks....

To:  mailto:'support@logsat.com'" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - 'support@logsat.com'
Sent: 03 March 2004 16:29
Subject: v1.2.0.212 not rejecting emails properly?
Dear Sirs,

We are currently trialling an unregistered version of SpamFilter
(v1.2.0.212) and are experiencing a problem whereby the following is
occuring (chronologically):

a) someone attempts to send us an email and because there are already too
many incoming connections being dealt with, the email in question gets
diverted via our secondary MX record to our ISP backup server

b) our ISP then attempts to resend the emails that they are currently
holding for us on a periodical basis, approx every 5-10 mins

c) however if the email is not on our valid recipients list in SpamFilter,
the connection is then dropped, but because the email is not rejected (just
connection dropped) the ISP backup server retains the email in their queue
and will attempt to send it again

This situation has so far resulted in 44,000 emails being held on our ISP's
backup server and because of the number of emails involved any valid emails
being held up in their queue have taken up to nine days to be redelivered
(as they have to wait their turn in the queue of 44,000 emails).

Just to add more problems to this situation, because the ISP is not getting
a valid rejection response the queue is continuing to grow.

Any help would be greatly appreciated.

Regards

Michael Milne

I.T. Support Analyst
PIRA International

========================================================
This email is confidential and should not be used by anyone who is not  the
original intended recipient. If you have received this email in error
please
inform the sender and delete it from your mailbox or any other  storage
mechanism. Pira International Limited cannot accept liability  for any
statements made which are clearly the sender's own and not expressly
made on behalf of Pira International Limited or one of their agents.

Pira International  can be contacted at  01372 802000
========================================================

Mike,

What do you have your "Max Connections" set to in the SpamFilter GUI?  Also, the secondary server should be in the allow list so that SpamFilter will not see it a an attempted Relay.  Unless the secondary is also foing filtering, this will have the side effect of NOT filtering.  If your secondary is also SpamFilter, then that server will filter for you and pass the good messages on.

Regards,

Dan S. (SF User)

Max incoming SMTP connections: 100

Not sure what you mean about the secondary server?

We currently only use the 'Authorised To' filter and MAPS criteria, all other filters are disabled.

I was refering to your statement "secondary MX record to our ISP backup server"  The back-up server is wat I was talking about.  100 connections is way too low for our application but I do not know what kind of traffic you see.  We normally do not see more than 25-50 at a time but it can burst up much higher.  We have ours set to 350.

Regards,

Dan S.

Thanks for the tip on connections.

I'm still having trouble grasping what you mean about the backup server. Basically SF is our main incoming email server, however on the odd occasion where an email cannot be sent (SF down or the like), then our ISP (Easynet in the UK) gets the email instead which they store on a server which then attempts to resend the emails every so many minutes (they call them their backup servers).

The problem with the ISP solution is that if the email coming from Easynet's 'backup' server is not addressed legitimately (i.e. not on our 'Authorised To' list and is most likely spam) then when SF disconnects the session it does not indicate that it is being rejected (only disconnected). So then Easynet are not aware we do not want the email so they end up re-queueing the email. This has led to the buildup of 44,000+ emails on their 'backup' servers.

Hope this clarifies our problem,

Many thanks so far,

Mike

Pira International.

consider start using your own 2 or more mailservers en leave that isp.

after you`ve read rfc 822 or 821, you will understand why, an isp which retries every 5 minutes, will make it to my static deny list.  1800+ seconds is the rfc value,

how nice if that is spoofed infected email....

kind regards,

-eric-

Thanks for your reply. I've had a look through RFC 821/2 and I would have thought that the appropriate response to an incoming email which is not on our 'Authorised To' list would be 553 'Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect]' but instead SF just disconnects the session without giving and error/reason why to the senders SMTP sender. Surely this is why we are having problems with out ISP as their server are not being told to cancel the email which is why we are seeing this huge buildup on their servers???!!!!

We really really need help with this.

Mike

Pira International

NB: our ISP now has 242,000 emails queue'd up for us, most likely 99.9% of these are not to valid authorised receivers within our company and therefore not on our list.

PS: are there no LogSat people around to help with this? Everytime I try to email their support it bounces back undeliverable, and they don't seem to answer their phone line!

Mike,

I have been emailing LogSat support with an ongoing conversation for the past several says and have not received any bounces.  What address are you sending to?

Can you possibly give me a "Bogus" address to send to?  I would like to see if I get a bounce.  I have several companies the we, as an ISP, run Secondary mail for (mail bagging) and we do not experience anything like you are describing so I am wondering if something else is going on.  If I can assist, just let me know.

Regards,

Dan S.

Thanks Dan,

The emails I sent were to mailto:support@logsat.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - support@logsat.com , twice they were bounced back.

Any help would be beneficial right now as it has both us and our ISP stumped. We've also found another interesting hickup just now as well regarding error returns from SF.

Basically if SF accepts an email which matches in the Authorised To list, the next step is that it forwards the email on to another email server (internal here which I'll call 'dot16'). Now if the email is larger than 10Mb (our current size limit) it will be rejected by 'dot16' but instead of SF sending an error back to the sender it then try's to send the error-email onto 'dot16' instead??? This is all starting to smell very wrong.

Regards,

Mike.

Mike,

I am on my way out but will return later.  However, for starters, I have my SpamFilter's "Max Message Size" set to about 5% lower than my follow on server just to avoid the situation you are looking at.  As to the bounce to your follow on server, shouldn't the dot16 server send the return to the original sender?  It may get confusing here but the situation is avoided by making sure that the SpamFilter does the size blocking.

I will be back around 6PM EST and am willing to look further is no one else can help before then.

Regards,

Dan S.

I would really appreciate your help, however I'm in the UK and will be unable to stay on site after 5:30pm GMT so unfortunately I won't be around again until Monday.

If you are still willing/able to help on Monday you could email me your number and we can discuss this on the phone ( mailto:mikem@pira.co.uk" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - mikem@pira.co.uk ).

Hope to hear from you,

Mike

Pira International

Mike,

If you are using the "Authorized TO" list, and an incoming emails is addressed to an invalid user, SpamFilter responds per RFC by default with a 550 code as follows, and then disconnects:

If you are experiencing different behavior, please check undet the "Settings" tabs, "Customized Items" sub-tab to ensure you did not alter the error codes, especially the ones for "Response if relaying is restricted" which applies in your case. If you change the 3-letter code you are altering the RC reponse, and if the 550 is not there, indeed your secondary will keep retrying to send emails.

Regarding your question about the following:
=======================
Basically if SF accepts an email which matches in the Authorised To list, the next step is that it forwards the email on to another email server (internal here which I'll call 'dot16'). Now if the email is larger than 10Mb (our current size limit) it will be rejected by 'dot16' but instead of SF sending an error back to the sender it then try's to send the error-email onto 'dot16' instead??? This is all starting to smell very wrong.
=======================

please note that SpamFilter uses your SMTP server as a notification SMTP server. Thus is SpamFilter tries to deliver an email to your user, and your SMTP server rejects it, in the example because the msg is too large, SpamFilter needs to send a NDR (Non-delivery notification) to the sender. To do so it uses your SMTP server, so in the logs you will see SpamFilter asking your SMTP server to deliver the error email to the sender.

Also please note that there is no reverse DNS entry configured for the SMTP server you are using at 217.207.193.20, thus all your emails to mailto:support@logsat.com" CLASS="ASPForums" TITLE="WARNING: URL created by poster. - support@logsat.com are being rejected a spam since we ourselves use the "Reject if no reverse DNS" filter.

We provide support by email and thru the support forum only. Our phone line is computerized,  it forwards us the calls by email, it is not manned by staff.

Roberto F.
LogSat Software

Dear Roberto,

Many thanks for your reply. I'm sorry if I came across non-too pleased but I hope you understand that our situation was starting to get out of hand and I was just trying to move forward on getting a solution.

We are currently looking through all that you have mentioned and hopefully this will see us through to a better operational status.

One question though, you mention RFC 550 as the standard reply yet our SF defaulted to 557 after installation. From what I can see the responses are very similar and should probably work ok, but just to be sure, is 557 as effective as 550 or should I change it?

Regards

Mike

Pira International

Mike,

No problem on using the 550 error code instead of the 557. We are actually doing some research into which code is proving to be the most "listened to" by remote servers, and it's appearing that 550 is slightly more efficient than 557. We'll be changing our defaults to 550 as a matter of fact in our next builds.

Roberto F.
LogSat Software