RE: Source: smtpsvc; Event ID: 4000
|
Logged in as: Guest
|
|
Users viewing this topic:
none
|
|
Login | |
|
RE: Source: smtpsvc; Event ID: 4000 - 19.May2004 4:25:00 PM
|
|
|
TroubleT77
Posts: 2
Joined: 18.May2004
From: Tulsa, OK
Status: offline
|
I was searching for help with the problem listed above and found this message board. I currently have GFI MailSecurity and MailEssentials on an external SMTP server and it sends mail to our internal Exchange 5.5 server.
The problem I'm interested in is I have the error "connection dropped by remote host" happening with some emails coming IN and it's my local domain that is disconnecting. It always does it with United air line confirmation emails. I do not have any of my NDR notifications turned on in MailEssentials and I usually only have average 10 emails in my queue. I have also ran a ping x.x.x.x -t on the internal server from our external server and do not get any request time out. I've been looking at Microsoft sites and am getting nowhere so I thought I would try GFI.
Please let me know if there's anything I can try, thanks.
T. Ewing
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 27.May2004 9:15:00 AM
|
|
|
garconer
Posts: 1
Joined: 26.May2004
From: Rio de Janeiro
Status: offline
|
It¦s a firewall Issue. Your firewall is not set correctly. The following rule may apply:
Service: STMP Port: 25 Protocol: TCP (I usually set also UDP) Direction: Outgoing Permit: ALL
I had same problem in the past. I¦m sure it will solve your problem.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 3.Jun.2004 3:30:00 PM
|
|
|
TroubleT77
Posts: 2
Joined: 18.May2004
From: Tulsa, OK
Status: offline
|
Thanks for the help but we have the firewall setup the way you described and I checked into disabling the 8BitMIME and we had to do that a year ago. All of our email seems to work, except the darn United Airline confirmation emails, they just will not deliver. Any more suggestions, I'm willing to try anything? Thanks.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 4.Jun.2004 4:24:00 AM
|
|
|
Lynx
Posts: 1
Joined: 3.Jun.2004
From: Biel, Switzerland
Status: offline
|
I've got the same Problem as "Ruth" and "deltamflynn". Every 11 Minutes I get a record in the system log saying: Message delivery to the remote domain 'redmouse.ch' failed for the following reason: The connection was dropped by the remote host. This happens for all my internal Domains every 11 Minutes. 99 % of the good mail is deliverd. Only 1% or so of good mail is delayed or dropped.
- Usually there are about 100 Mail in the Queue. - There is no Fire Wall between Gateway Server and Mail Server. - We are getting about 150 Mails/hour
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 15.Jul.2004 4:21:00 PM
|
|
|
qnguyen
Posts: 44
Joined: 6.Apr.2004
Status: offline
|
Has anyone find a was to fix this ID 4000 problem yet? I have just got all the good e-mail setting in the queue and the sender got an e-mail telling them that the e-mail was delay. It was working find until this morning. I did not make any changes to the system. Can someone at GFI support give us an update Please. Thank You Very Much
Tony
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 15.Jul.2004 4:48:00 PM
|
|
|
elcic12
Posts: 8
Joined: 14.Jul.2004
Status: offline
|
I'm encoutering the same issue. Started just this week, after running MSEC 8 just fine for nine months. I did just upgrade from 8 to 8.1 this last weekend. This was the only change to the relay server since upgrading from ME6 to MSEC8 last November. The message was logged once at the time of the upgrade, then began repeat every 6 minutes about 50 hours later. All the messages reference the local (incoming) domain. I am relaying to Exchange 5.5 I attempted the MS fix in article 286673 (turn off 8bitmime verb), to no avail. I do not, however, have any conclusive evidence that it is MSEC that's causing the issue.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 27.Jul.2004 11:20:00 AM
|
|
|
elcic12
Posts: 8
Joined: 14.Jul.2004
Status: offline
|
Additional observations:
Certain problem messages cause this, but other legit mail continues to flow while the Event ID 4000 is being logged. The event is logged at regular intervals, 6 minutes apart. I have found that stopping the SMTP Virtual Server, removing the problem mail, then restarting resolves the issue, albeit temporarily. At one point, the warning reappaered, then resolved without any administrative intervention. I've found 2 pieces of mail in particular that caused the issue (btw, one was a United Airlines booking confirmation); neither were spam per se, but both were HTML mail containing HTML scripts that were disabled by MSEC's exploit engine. Anyone else making any headway on thisn one?
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 30.Jul.2004 9:50:00 AM
|
|
|
Nicks
Posts: 2741
Joined: 17.Mar.2003
Status: offline
|
Hi,
What is the firewall software that you are using in your network?
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 30.Jul.2004 1:17:00 PM
|
|
|
elcic12
Posts: 8
Joined: 14.Jul.2004
Status: offline
|
I'm using a Cisco PIX. However, both the MSEC gateway and the Exchagne server are behind it, on the same subnet.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 30.Aug.2004 3:50:00 PM
|
|
|
helpdesk@boingo.com
Posts: 4
Status: offline
|
I see this event ID too on my e-mail gateway after I installed ME10 on my exchange 2k server. When this happens all my mail are queue on the e-mail gateway and does not recover unless I reboot both servers.
Telnet to exchange server at port 25 gets reply but when you send a test messages using a mail utility called "blat" the exchange server refuses the connection.
I am currently waiting for ME10 fix for this issue. Hope this helps.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 6.Sep.2004 6:39:00 AM
|
|
|
Nicks
Posts: 2741
Joined: 17.Mar.2003
Status: offline
|
Please note that SMTP connections, the sending and receiving of emails are all done by IIS or Exchagne server. MailEssentials does not control the SMTP connection. MailEssentials will just scan the items that are passing trough the SMTP server.
If the problem is in the connection, MailEssentials should not be interfering with this.
However, if you still think that MailEssentials could be causing the problem, please email us at support@gfi.com so we can check further the issue.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 10.Sep.2004 4:54:00 PM
|
|
|
shelby
Posts: 24
Joined: 9.Sep.2004
From: White Oak
Status: offline
|
I am having the same problem with SMTP errors the system event logwith Mail Security 8 on a gateway server in trying to send to SPAM type domains. It is indeed as if NDRs are being sent, but I have NDRs disabled on Exchange. Does anyone know where else I need to look? From all testing I've done, I don't think I'm open to relay.
Someone else mentioned frequently losing relay connectivity to the internal email srver - I noticed this seemed to happen when the system event log filled -which was occurring frequently. I set the event log to overwrite earliest events and stopped losing the connection.
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 22.Sep.2004 7:59:00 PM
|
|
|
boombeeshark
Posts: 1
Joined: 22.Sep.2004
From: Australia
Status: offline
|
I have been following this post and I believe I have a solution (or at least a pointer in the correct direction).
I have a Windows 2000 server running IIS SMTP as the SMTP relay for a web site. I have been receiving numerous "4000" errors and performed a network monitor on one of the failures. The final response from the host of these failures was
See http://pobox.com/~djb/docs/smtplf.html
If you visit this web site you will see the problem stems from "Bare LFs" in the e-mails. Basically, such character strings are no allowed by the RFC standard, however, different mail systems handle these situations differently. In my case, we were sending to a server running QMail (which rejects these e-mails).
I posted this information to Microsoft and their response was as follows:
------------------------------------------------- Hi Russell,
Thanks for posting and letting us know you've figured out the issue.
Yes, the problem here is that some mail servers don't allow/accept Bare LF messages.
IIS's SMTP mail service however, chooses to relay all emails without modifications. That is, it doesn't reject the Bare LF mails, nor does it modify them. It simply relays them.
Per my research, here are some reasons for this design:
I. RFC 2821 doesn't describe clearly about what actions a mail server should take for Bare LF messages.
Here is a quote from RFC 2821:
2.3.7 Lines
SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
As you can see it states "SMTP client implementations MUST NOT transmit these characters".
However, the IIS SMTP service here is not a SMTP client in this case. There is no situation where SMTP service generates the mail. It is just relaying mail unmodified though. The RFC is notably silent on both: - What is the appropriate behavior when receiving a bare LF - How to seamlessly interoperate with an "old" RFC822/RFC821 system if stricter guidelines are enforced (rather than observed).
II. When designing a SMTP mail server, it is hard to judge what the appropriate thing to do for the Bare LF case is: - Reject the mail like Qmail has done? - Automatically "fix up" the mail and change LF to CRLF? - Automatically detect this in mail and NDR it?
Although it looks like "fix up" may be a good idea, but it begs a few questions like: - What if the message is binary MIME (signed even)? - What if the remote server *will* accept this?
This is why Windows 2000 SMTP chooses to simply relay all messages to comply with both new (RFC 2821) and old (RFC822/RFC821) mail servers.
Hope this helps! -------------------------------------------------
So, in my situation the problem is the web site that generates the e-mails for relay (it doesn't adhere to the standard), with the Microsoft SMTP service simply relaying exactly what it is receiving.
In other cases, you will need to refer to the sender of the e-mail and advise them their e-mails are not conforming to the standard. Alternatively, you will need to contact your product vendor and investigate how they handle such "protocol violations" and options available to prevent the system hanging and / or an update to accept such situations
I hope this helps.
Regards, Russell Sumich Windows 2003 MCSE, Windows 2000 MCSE, Windows NT 4.0 MCSE and CCA
|
|
|
|
RE: Source: smtpsvc; Event ID: 4000 - 29.Jun.2005 5:15:00 PM
|
|
|
LewisM
Posts: 1
Joined: 28.Jun.2005
From: Florida
Status: offline
|
I am receiving the same error messages in the event log and we are using Exchange 2000 and Symantec's Mail Security 4.5 and it started when we installed the mail security. Also receiving event 4001. Most emails are spam with little to no sender info. Just want to know the fix or workaround, will try the stop and restart SMTP virtual server and set event log to overwrite and will post my results.
|
|
|
|
New Messages |
No New Messages |
Hot Topic w/ New Messages |
Hot Topic w/o New Messages |
Locked w/ New Messages |
Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|