SCOUG-HELP Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 15 Aug 2004 06:44:18 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: Dups anyone? Here's the tech resolution info

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Here's what happened and why it happened. Lots of info here if you want
to wade through it.

Steven Levine wrote:
>
> I took a quick look at the headers earlier today. There were no duplicate
> sends from the source. The duplicates were because INetPro appears to
> have decided that the the send to the ISP failed even though it did not.
> The culprit may be the cleanup daemon because that's what inetpro
> component that doing the send.

Thanks for this info, Steven. We've occasionally had a similar problem
in the past where INetMail sent the messages and then either didn't
receive an acknowledgement or didn't process the acnowledgement when it
was received. Thus INetMail thought the send had failed and sent the
message again. (Thus, Message-Id was the same but the most recent
Received line was "newer".)

*And*, this seemed to happen when INetMail was heavily looping, thus the
looping took up most of the cpu time and the Internet connection to the
foreign SMTP server timed out (typically 30 or 60 seconds depending on
the server). (This is when I started checking for the loop condition
more than once per day.)

The scrambled mail files yesterday is a new problem. As near as I can
figure it out, some spammer was using Vernon in Australia to send a lot
of junk mail to bob@scoug.com and peter@scoug.com, and had malformed his
messages so that the RCPT info (something you don't see in the header
but it's the message destination, ask if you want full details)
contained HTML (maybe the guy forgot the required blank line between
header and message). Thus his HTML became part of the To structure
along with bob and peter and INetMail got very confused when it
encountered the HTML codes where the recipient (RCPT) should be.

How did this cause all the dupes? INetMail tried to send a copy of the
spam message to each one of the HTML codes and HTML text strings because
it looked like they were recipients also. But every one of them was an
invalid address. The mail queue thus filled up with a huge number of
messages that couldn't be sent. INetMail dutifully tried over and over
to keep sending them, along with the occasional valid SCOUG-Help
message. With a couple dozen mail threads now running, the outbound
SCOUG-Help messages encountered the same timeout problem that we get
when INetMail is looping. Hence the valid SCOUG-Help messages went out
but very slowly due to the extremely heavy usage, and the
acknowledgement from the foreigh server came back after the timeout.
Hence INetMail thought the message had failed in transit and sent it
again (the "Cleanup Daemon" took over).

Why did some people (like me) get only one copy, some people got two
copies, and some got more than two? Because INetMail divides the
messages up by target ISP and sends each target ISP separately. For
example, a@yy.com and b@yy.com are sent together but c@yy.com and
d@zz.com are sent separately. Since almost everybody is using a
different ISP they all get "individual treatment" from INetMail. Why
did I get only one copy of each message? Probably because my ISP has a
longer timeout period (my incoming mail has to do a double-handshake and
therefore the intermediate service I use doesn't time out as quickly as
most ISPs; it may even do a "keepalive" on the connection for this
reason).

The tentative solution is to reduce the maximum number of outbound
INetMail threads so the system can't load so heavily and it's then less
likely that a timeout will occur.

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 15 | August | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.