email missing, POP Connector

hi,

I wonder if anyone has come across this problem before.

Some users had reported over time that they did not receive email
that outside people (their customers) had sent to them. The users
had no idea of such email until they had to countercheck some matters.
Obviously not a good thing.

Going thru Admin mailbox, I found that among all the spoofs and spam,
were many NDRs to external email addrs. Checking some of these
(open the NDR, click Resend), I find that these appear to be NDRs
being sent from the SBS to the external users but had failed, i.e. the
NDRs themselves became NDRs. The Admin mailbox doesn't have
the 'original' NDR (Exchange is set to send a copy of NDR to Admin)
but the NDRs of NDRs.

These NDRs have 2 text attachments. One is the transaction with
Exchange (SMTP 550 etc), the other appears to be the email header
of the NDR that failed to make it out of SBS. Many of these header
texts appear to contain legit emails, by looking at the sender (external)
addr, recepient (valid internal addr), subject (appears to be genuine
business topic in a common format/structure for subject). Some other
NDRs I'm not so sure about, but could also be genuine mail that failed
to get thru and also failed to bounce out, these include from mailing lists,
PocketPC.com etc.

This header text shows email being d/l from POP, there's some trace
of where it was before POP. It doesn't show email failing to get to
the internal email acct, that's the unusual thing - it looks exactly like
an email that successfully made it through (the header that is).

However, not all emails are being affected, eg. many emails appear to
be affected during the first POP download on Monday morn as the
SBS is off over weekend, yet some email make it thru later and then
some other email failed the same way in the afternoon.

How do I diagnose, log and fix this? I would be grateful for any ideas
or clues.

This is a SBS2000, 2 Nics, ISA, 1GB ram, 2xOpteron, using POP
Connector to download and SMTP out to ISP's SMTP configured
in SBS SMTP connector. The only change made recently was to
install Symantec AVEE ver10 which includes File system scanner and
the mailscanner (SAVCE and SMSMSE). I don't think SAVEE is
the cause though.

TIA,
Eugene Tan

Bill
Sat Jun 25 14:57:06 CDT 2005

Hi Eugene

Is there any chance of going SMTP ? Alot of problems solved this way. If not
sure, where is your email ISP and I will check their support files.

Are any of these emails a BCC ? Pop3 struggles with these, also ISPs messing
with emails headers to combat spam doesn't help. I have been noticing this
on 2000 and 2003 (some of my clients email ISP do not do SMTP) I found I had
to instal GFI mail essentials and use their pop3 collector (lets you
configure downloads quicker than 15 mins ...lol) Get a spam filter too.

--
Thinking of upgrading .. COOL... http://www.sbsmigration.com

www.smallbizserver.net (2000 and 2003)

microsoft.public.backoffice.smallbiz2000 (2000 NG)

microsoft.public.windows.server.sbs (2003 NG)

http://groups.google.com/groups?hl=en&safe=off&group=microsoft.public.backoffice.smallbiz2000

http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&group=microsoft.public.windows.server.sbs

http://www.sbslinks.com/


"Eugene Tan" <insights-[dropthis]@post1.com> wrote in message
news:eyYP7HUeFHA.2844@TK2MSFTNGP14.phx.gbl...
> hi,
>
> I wonder if anyone has come across this problem before.
>
> Some users had reported over time that they did not receive email
> that outside people (their customers) had sent to them. The users
> had no idea of such email until they had to countercheck some matters.
> Obviously not a good thing.
>
> Going thru Admin mailbox, I found that among all the spoofs and spam,
> were many NDRs to external email addrs. Checking some of these
> (open the NDR, click Resend), I find that these appear to be NDRs
> being sent from the SBS to the external users but had failed, i.e. the
> NDRs themselves became NDRs. The Admin mailbox doesn't have
> the 'original' NDR (Exchange is set to send a copy of NDR to Admin)
> but the NDRs of NDRs.
>
> These NDRs have 2 text attachments. One is the transaction with
> Exchange (SMTP 550 etc), the other appears to be the email header
> of the NDR that failed to make it out of SBS. Many of these header
> texts appear to contain legit emails, by looking at the sender (external)
> addr, recepient (valid internal addr), subject (appears to be genuine
> business topic in a common format/structure for subject). Some other
> NDRs I'm not so sure about, but could also be genuine mail that failed
> to get thru and also failed to bounce out, these include from mailing
> lists,
> PocketPC.com etc.
>
> This header text shows email being d/l from POP, there's some trace
> of where it was before POP. It doesn't show email failing to get to
> the internal email acct, that's the unusual thing - it looks exactly like
> an email that successfully made it through (the header that is).
>
> However, not all emails are being affected, eg. many emails appear to
> be affected during the first POP download on Monday morn as the
> SBS is off over weekend, yet some email make it thru later and then
> some other email failed the same way in the afternoon.
>
> How do I diagnose, log and fix this? I would be grateful for any ideas
> or clues.
>
> This is a SBS2000, 2 Nics, ISA, 1GB ram, 2xOpteron, using POP
> Connector to download and SMTP out to ISP's SMTP configured
> in SBS SMTP connector. The only change made recently was to
> install Symantec AVEE ver10 which includes File system scanner and
> the mailscanner (SAVCE and SMSMSE). I don't think SAVEE is
> the cause though.
>
> TIA,
> Eugene Tan
>
>

Eugene
Mon Jun 27 02:42:48 CDT 2005

hi,

Thanks for replying but if you read my post in detail, you'll note that
the emails have a valid addressee, thus is not BCC. Also, I've not
noticed a problem with BCC except that it stays in the default mailbox.

The main problem here is that email is bouncing, possibly without NDR,
and I became aware when the NDRs for these email failures themselves
were not delivered, i.e. NDR of NDR This is obviously a problem.

What I'm not sure abt is whether these msgs/NDRs are fake, or my
server has been hacked or something else. When an mail doesn't
make it, an NDR is correct? Even if the addr is legit, regardless or
reason, an NDR is always generated, right?
However, in this case, I don't have the original NDRs, only the
bounced NDRs of NDRs, where the attachments appear to have
the original NDRs.

TIA,
Eugene Tan

===========================
"Bill Swan" <bill@nospamfirstresponseit.co.uk> wrote in message
news:epEdTAceFHA.1448@TK2MSFTNGP14.phx.gbl...
> Hi Eugene
>
> Is there any chance of going SMTP ? Alot of problems solved this way. If
> not sure, where is your email ISP and I will check their support files.
>
> Are any of these emails a BCC ? Pop3 struggles with these, also ISPs
> messing with emails headers to combat spam doesn't help. I have been
> noticing this on 2000 and 2003 (some of my clients email ISP do not do
> SMTP) I found I had to instal GFI mail essentials and use their pop3
> collector (lets you configure downloads quicker than 15 mins ...lol) Get a
> spam filter too.
>
> --
> Thinking of upgrading .. COOL... http://www.sbsmigration.com
>
> www.smallbizserver.net (2000 and 2003)
>
> microsoft.public.backoffice.smallbiz2000 (2000 NG)
>
> microsoft.public.windows.server.sbs (2003 NG)
>
> http://groups.google.com/groups?hl=en&safe=off&group=microsoft.public.backoffice.smallbiz2000
>
> http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&group=microsoft.public.windows.server.sbs
>
> http://www.sbslinks.com/
>
>
> "Eugene Tan" <insights-[dropthis]@post1.com> wrote in message
> news:eyYP7HUeFHA.2844@TK2MSFTNGP14.phx.gbl...
>> hi,
>>
>> I wonder if anyone has come across this problem before.
>>
>> Some users had reported over time that they did not receive email
>> that outside people (their customers) had sent to them. The users
>> had no idea of such email until they had to countercheck some matters.
>> Obviously not a good thing.
>>
>> Going thru Admin mailbox, I found that among all the spoofs and spam,
>> were many NDRs to external email addrs. Checking some of these
>> (open the NDR, click Resend), I find that these appear to be NDRs
>> being sent from the SBS to the external users but had failed, i.e. the
>> NDRs themselves became NDRs. The Admin mailbox doesn't have
>> the 'original' NDR (Exchange is set to send a copy of NDR to Admin)
>> but the NDRs of NDRs.
>>
>> These NDRs have 2 text attachments. One is the transaction with
>> Exchange (SMTP 550 etc), the other appears to be the email header
>> of the NDR that failed to make it out of SBS. Many of these header
>> texts appear to contain legit emails, by looking at the sender (external)
>> addr, recepient (valid internal addr), subject (appears to be genuine
>> business topic in a common format/structure for subject). Some other
>> NDRs I'm not so sure about, but could also be genuine mail that failed
>> to get thru and also failed to bounce out, these include from mailing
>> lists,
>> PocketPC.com etc.
>>
>> This header text shows email being d/l from POP, there's some trace
>> of where it was before POP. It doesn't show email failing to get to
>> the internal email acct, that's the unusual thing - it looks exactly like
>> an email that successfully made it through (the header that is).
>>
>> However, not all emails are being affected, eg. many emails appear to
>> be affected during the first POP download on Monday morn as the
>> SBS is off over weekend, yet some email make it thru later and then
>> some other email failed the same way in the afternoon.
>>
>> How do I diagnose, log and fix this? I would be grateful for any ideas
>> or clues.
>>
>> This is a SBS2000, 2 Nics, ISA, 1GB ram, 2xOpteron, using POP
>> Connector to download and SMTP out to ISP's SMTP configured
>> in SBS SMTP connector. The only change made recently was to
>> install Symantec AVEE ver10 which includes File system scanner and
>> the mailscanner (SAVCE and SMSMSE). I don't think SAVEE is
>> the cause though.
>>
>> TIA,
>> Eugene Tan
>>
>>
>
>

StudioTwo
Mon Jun 27 10:02:26 CDT 2005

Hello,

We used to a similar problem when customers sent us messages that were above
the maximum message size specified within exchange. They would be sent a
NDR, but this would also fail as it would be too big to send. could this be
the problem?

Do you have restrictions on both sending and receiving message sizes?

Q308303 describes how to strip attachments from the NDR (thus avoiding this
scenario): http://support.microsoft.com/default.aspx?scid=kb;en-us;308303

HTH
Stephen

"Eugene Tan" <insights-[dropthis]@post1.com> wrote in message
news:eyYP7HUeFHA.2844@TK2MSFTNGP14.phx.gbl...
> hi,
>
> I wonder if anyone has come across this problem before.
>
> Some users had reported over time that they did not receive email
> that outside people (their customers) had sent to them. The users
> had no idea of such email until they had to countercheck some matters.
> Obviously not a good thing.
>
> Going thru Admin mailbox, I found that among all the spoofs and spam,
> were many NDRs to external email addrs. Checking some of these
> (open the NDR, click Resend), I find that these appear to be NDRs
> being sent from the SBS to the external users but had failed, i.e. the
> NDRs themselves became NDRs. The Admin mailbox doesn't have
> the 'original' NDR (Exchange is set to send a copy of NDR to Admin)
> but the NDRs of NDRs.
>
> These NDRs have 2 text attachments. One is the transaction with
> Exchange (SMTP 550 etc), the other appears to be the email header
> of the NDR that failed to make it out of SBS. Many of these header
> texts appear to contain legit emails, by looking at the sender (external)
> addr, recepient (valid internal addr), subject (appears to be genuine
> business topic in a common format/structure for subject). Some other
> NDRs I'm not so sure about, but could also be genuine mail that failed
> to get thru and also failed to bounce out, these include from mailing
> lists,
> PocketPC.com etc.
>
> This header text shows email being d/l from POP, there's some trace
> of where it was before POP. It doesn't show email failing to get to
> the internal email acct, that's the unusual thing - it looks exactly like
> an email that successfully made it through (the header that is).
>
> However, not all emails are being affected, eg. many emails appear to
> be affected during the first POP download on Monday morn as the
> SBS is off over weekend, yet some email make it thru later and then
> some other email failed the same way in the afternoon.
>
> How do I diagnose, log and fix this? I would be grateful for any ideas
> or clues.
>
> This is a SBS2000, 2 Nics, ISA, 1GB ram, 2xOpteron, using POP
> Connector to download and SMTP out to ISP's SMTP configured
> in SBS SMTP connector. The only change made recently was to
> install Symantec AVEE ver10 which includes File system scanner and
> the mailscanner (SAVCE and SMSMSE). I don't think SAVEE is
> the cause though.
>
> TIA,
> Eugene Tan
>
>

Eugene
Mon Jun 27 21:48:10 CDT 2005

hi Stephen,

Thanks for this clue.
Yes, as per ExBPA, I did set some size limits of around 9MB or higher
to prevent DoS events, but if this was the cause it was surely unexpected.
I'll check with the senders concerned if this was the case.

But such size limits would be on a per message basis right, not the whole
POP to SMTP session?

Thanks for the link abt stripping attachments from NDR. Makes sense
but lost this link some time ago.

TIA,
Eugene Tan

============================
"StudioTwo" <studio_two@hotmail.com> wrote in message
news:uWEgzkyeFHA.2124@TK2MSFTNGP14.phx.gbl...
> Hello,
>
> We used to a similar problem when customers sent us messages that were
> above the maximum message size specified within exchange. They would be
> sent a NDR, but this would also fail as it would be too big to send. could
> this be the problem?
>
> Do you have restrictions on both sending and receiving message sizes?
>
> Q308303 describes how to strip attachments from the NDR (thus avoiding
> this scenario):
> http://support.microsoft.com/default.aspx?scid=kb;en-us;308303
>
> HTH
> Stephen