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: '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
========================================================

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.

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.

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!

Thanks Dan,

The emails I sent were to 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.

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 (mikem@pira.co.uk).

Hope to hear from you,

Mike

Pira International

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