|
Home > Archive > IIS and SMTP > February 2005 > SMTP WEIRDNESS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| AUGMAN70 2005-02-03, 5:52 pm |
| We are using a Netscreen 5XP firewall that listens on multiple IP
addresses (designated ports per IP address) and forwards them off to
designated IP addresses on the internal network. One such 'policy' is
for SMTP (25). This policy allows all incoming traffic to enter the
network and go to a system running Windows 2003 IIS/SMTP. On top of
SMTP are the GFI MailSecurity and MailEssentials products. Once the
SMTP system allows the connection, the GFI products scan the message
for content (spam, viruses, etc.) and then forward it on to an Exchange
2000 server. All outbound messages do the reverse. Up until now, we've
had no problems to speak of.
Out of the blue, I have experienced three companies (that I know of)
who have indicated they can no longer (could in 2004) send mail to our
mail gateway; after a number of hours, they would receive a generic
NDR. Nothing (that I know of) was done on our end, but this is what I
do know about the senders:
#1) One company recently performed an upgrade of the firmware on their
IronMail gateway.
#2) The other two companies use outsourced mail gateways - both use the
same DNS provider as well.
This problem creeped up the first week of January 2005 and after hours
of reviewing log files (firewall, IIS/SMTP, GFI, etc.), I'm stumped as
to how and/or why this is happening. The only log file that registers
anything is the firewall log and it shows the tunnel to be in open
states of 1,000+ seconds each time with little to no data transfer
taking place. None of the other log files register anything relating to
the sending IP/domains. The information I've been able to gather from
GFI/Microsoft is that IIS/SMTP is the next log file in line for
registering (log file entry) the information. After that, GFI's
products kick into gear (and logs are written for both).
To make matters worse, we can send them email without problems. We
don't do RDNS lookups, we don't block domains/IPs. I've re-created the
SMTP policy. We haven't seen a drop in email; we still get tons of
email from all over the place (both good and bad senders).
I'm at a total loss; CipherTrust (the makers of IronMail) Support has
suggested that IIS/SMTP is severing the connection -- why wouldn't the
SMTP log register this if it were true?
| |
| Jeff Cochran 2005-02-04, 6:00 pm |
| On 3 Feb 2005 12:08:55 -0800, "AUGMAN70" <laughey@gmail.com> wrote:
>We are using a Netscreen 5XP firewall that listens on multiple IP
>addresses (designated ports per IP address) and forwards them off to
>designated IP addresses on the internal network. One such 'policy' is
>for SMTP (25). This policy allows all incoming traffic to enter the
>network and go to a system running Windows 2003 IIS/SMTP. On top of
>SMTP are the GFI MailSecurity and MailEssentials products. Once the
>SMTP system allows the connection, the GFI products scan the message
>for content (spam, viruses, etc.) and then forward it on to an Exchange
>2000 server. All outbound messages do the reverse. Up until now, we've
>had no problems to speak of.
>
>Out of the blue, I have experienced three companies (that I know of)
>who have indicated they can no longer (could in 2004) send mail to our
>mail gateway; after a number of hours, they would receive a generic
>NDR. Nothing (that I know of) was done on our end, but this is what I
>do know about the senders:
>
>#1) One company recently performed an upgrade of the firmware on their
>IronMail gateway.
>#2) The other two companies use outsourced mail gateways - both use the
>same DNS provider as well.
>
>This problem creeped up the first week of January 2005 and after hours
>of reviewing log files (firewall, IIS/SMTP, GFI, etc.), I'm stumped as
>to how and/or why this is happening. The only log file that registers
>anything is the firewall log and it shows the tunnel to be in open
>states of 1,000+ seconds each time with little to no data transfer
>taking place. None of the other log files register anything relating to
>the sending IP/domains. The information I've been able to gather from
>GFI/Microsoft is that IIS/SMTP is the next log file in line for
>registering (log file entry) the information. After that, GFI's
>products kick into gear (and logs are written for both).
>
>To make matters worse, we can send them email without problems. We
>don't do RDNS lookups, we don't block domains/IPs. I've re-created the
>SMTP policy. We haven't seen a drop in email; we still get tons of
>email from all over the place (both good and bad senders).
>
>I'm at a total loss; CipherTrust (the makers of IronMail) Support has
>suggested that IIS/SMTP is severing the connection -- why wouldn't the
>SMTP log register this if it were true?
Have you checked to see if you've been blacklisted? Or are you using
an IP with no valid reverse DNS? Have you asked the sending companies
for the relevant log info on their end?
We had one instance recently where a system was disconnecting us and
the log message on our end looked like their spam gateway was
determining us as spamming. Turned out their gateway returned the
message because the destination mailbox was full, but it took a long
distance call and time on the phone with their IT guy to straighten it
out.
Jeff
| |
| AUGMAN70 2005-02-04, 6:00 pm |
| Jeff Cochran wrote:
> On 3 Feb 2005 12:08:55 -0800, "AUGMAN70" <laughey@gmail.com> wrote:
>
is[vbcol=seagreen]
Exchange[vbcol=seagreen]
we've[vbcol=seagreen]
our[vbcol=seagreen]
I[vbcol=seagreen]
their[vbcol=seagreen]
the[vbcol=seagreen]
hours[vbcol=seagreen]
as[vbcol=seagreen]
registers[vbcol=seagreen]
to[vbcol=seagreen]
from[vbcol=seagreen]
the[vbcol=seagreen]
has[vbcol=seagreen]
the[vbcol=seagreen]
>
> Have you checked to see if you've been blacklisted? Or are you using
> an IP with no valid reverse DNS? Have you asked the sending
companies
> for the relevant log info on their end?
>
> We had one instance recently where a system was disconnecting us and
> the log message on our end looked like their spam gateway was
> determining us as spamming. Turned out their gateway returned the
> message because the destination mailbox was full, but it took a long
> distance call and time on the phone with their IT guy to straighten
it
> out.
>
> Jeff
Hi Jeff, we are the one having the problem receiving, not sending, and
it's only from this one company. We can email them, but they cannot
email us. We checked the major blacklists for their record and they are
clean. Blacklisting doesn't matter at this point because (a) our ISP
doesn't do such a thing, (b) our firewall allows the tunnel and (c) our
internal content filter is one level upstream from where the problem
takes place - our filter isn't applied until the SMTP service accepts
the message and since it never even registers an attempt from that
particular company, our content filter never gets a chance to review
the message. The logs provided by the remote company indicate "the
remote server terminated the connection".
Either way, the problem has been solved. Turns out, we were blocking a
few IP addresses (from foreign lands) via the SMTP configuration and
although none of them were even remotely close to the IP address of the
problematic company, once I removed them and restarted the SMTP
service, they can now, once again, send us email. So, instead of
blocking a company in Spain from repeated attempts to mailbomb us, I
have to leave such a feautre off in order to remove any potential for
email problems much like this one.
Gotta love Microsoft...thanks for nothing, BG.
|
|
|
|
|