Another SWEN coming in every hour

[Veronica Loell]

Jan Il wrote / skrev:
[...]

The Rule is that; any messsge that has M, MS, Microsoft in the FROM line is
to be deleted from the server. But, like the one that I posted earlier, it

[...]

Guess you don't know any Martins? ;-)

- Veronica Loell

 

[James Egan]

The Rule is that; any messsge that has M, MS, Microsoft in the FROM line is
to be deleted from the server.

I don't use OE or know the syntax the filters use so I'll have to
guess that this is a poor effort.

Does , mean OR?

Do you really want to delete everything that has an M in the from line
or just those that begin with M? Either is going to zap more than you
anticipated.

Maybe your filter failed because it is being matched further up the
line with an instruction to cease further processing or it's being
re-processed further down the line also (ie you didn't tell processing
to stop).


Jim.

 

[David Stites]

Gabriele -

Jan

I don't use OE to filter because I run my own mailserver. The rules I added
have stopped all Swens with no false positives that I can see in my logs.
They are:
Rule 2 Reject all emails that have an attachment with a .exe,.com,.dll, or
..vbs extension
Rule 3 Reject all emails that don't contain the name of a user on my system
in the To: or Cc: headers
This also stops any mail list that uses the Bcc: header which is why
Rule 1 accept mail from my mail lists.

Good luck,
Dave

 

[Jan Il]

Hi Veronica!

Jan Il wrote / skrev:
[...]

The Rule is that; any messsge that has M, MS, Microsoft in the FROM line is
to be deleted from the server. But, like the one that I posted earlier,

it
[...]

Guess you don't know any Martins? ;-)

Well...yeah....actually I do...but, the Martins I've met lately don't do
windows.....bummer.. ;-)

Jan

 

[Jan Il]

Hi James -

I don't use OE or know the syntax the filters use so I'll have to
guess that this is a poor effort.

On which part? Mine.. or OE?

Does , mean OR?

Hmm...could you explain this just a tidge more? I am afraid that I am not
familiar with OR.

Do you really want to delete everything that has an M in the from line
or just those that begin with M? Either is going to zap more than you
anticipated.

Ahm...yeah...I did do that. And, that is why I set the Rule to delete all
messages that have M, MS, or Microsoft in the FROM line from the server. I
thought I had stated that earlier in the thread, but, perhaps I did not make
that clear. Sorry for the confusion. Anyway...you see, perhaps you have
not yet recieved any Swen messages where there is just an M, or MS or
Microsoft in the FROM line. I have, in fact...a whole wazoolie of
them...and that is why I set the Rule to delete any message that has M, MS,
or Microsoft in the FROM line from the server. See??

Maybe your filter failed because it is being matched further up the
line with an instruction to cease further processing or it's being
re-processed further down the line also (ie you didn't tell processing
to stop).

Well....I only set the one Rule, which has the activity of 'delete from
server'. As such, there is no option to select the 'stop processing other
rules, so there is no other Rule applied. Thus, with the subject Rule in
place, with the action of 'delete from server', there is no way to set the
stop processing action.

Thank you very much for your additonal input, I really appreciate it. ;-)

Jan

 

[Jan Il]

Hi David -

I don't use OE to filter because I run my own mailserver. The rules I added
have stopped all Swens with no false positives that I can see in my logs.
They are:
Rule 2 Reject all emails that have an attachment with a .exe,.com,.dll, or
.vbs extension
Rule 3 Reject all emails that don't contain the name of a user on my system
in the To: or Cc: headers
This also stops any mail list that uses the Bcc: header which is why
Rule 1 accept mail from my mail lists.

Good luck,
Dave

Dave...I have set various Rules, including the ones that you suggest, and
for the majority of the Swen messages these Rules did work. The point is
that I am getting some Swen messages that none of the OE Rules are able to
prevent from downloading.

I have think that it has been determined at this point, that it is not
really the fact that the OE Rules are not working properly, but, that there
is a series of messages that the OE program data is not able to detect.

As an example, I got a message just a few minutes ago, that just has
Administrator in the FROM line, but the Subject line is blank. There is
nothing in the Subject line. This is the first one of these messages that I
have recieved, and it downloaded in spite of the Rules in place that says,
any message with an attachment, delete from server. And?????

Here is the body of the message:
******************************************************

Message from

bigfoot.com

I'm sorry I wasn't able to deliver your message to the following addresses:

Undelivered to (e-mail address removed)

Message follows:

*****************************************************
But, there is no message, just the attachment

Here is the details of this message:
****************************************************************************
****************
Return-Path: <[email protected]>
Received: from mta02bw.bigpond.com ([144.135.24.138]) by fed1mtai04.cox.net
(InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
id
<[email protected]>
for <[email protected]>; Wed, 8 Oct 2003 04:16:33 -0400
Received: from otnegq ([144.135.24.78]) by mta02bw.email.bigpond.com
(iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
with SMTP id <[email protected]> for
(e-mail address removed);
Wed, 08 Oct 2003 18:02:44 +1000 (EST)
Received: from cpe-144-136-4-17.vic.bigpond.net.au ([144.136.4.17])
by bwmam04bpa.bigpond.com(MAM REL_3_3_2d 35/9308942); Wed,
08 Oct 2003 18:06:30 +0000
Date: Wed, 08 Oct 2003 18:02:20 +1000 (EST)
Date-warning: Date header was inserted by mta02bw.email.bigpond.com
From: Administrator <[email protected]>
Subject:
To: Mail User <[email protected]>
Message-id: <[email protected]>
MIME-version: 1.0
Content-type: multipart/alternative;
boundary="Boundary_(ID_PEVtNu3OtwEnxJFllXqK1w)"
X-ID: 9533956628335948997
****************************************************************************
*
This really looks a bit out of the ordinary, at least that I have seen.
Just the Date-warning: and the boundary="Boundary part is really different
than anything I've seen yet. Besides the fact that I have not seen a Swen
message with no Subject line. ???

Thank you Dave, I really appreciate your additional input and suggestions.

Jan

 

[James Egan]

Hmm...could you explain this just a tidge more? I am afraid that I am not
familiar with OR.

It's a boolean operator that returns a value of TRUE if either (or
both) of its operands is TRUE

Ahm...yeah...I did do that. And, that is why I set the Rule to delete all
messages that have M, MS, or Microsoft in the FROM line from the server. I
thought I had stated that earlier in the thread, but, perhaps I did not make
that clear. Sorry for the confusion. Anyway...you see, perhaps you have
not yet recieved any Swen messages where there is just an M, or MS or
Microsoft in the FROM line. I have, in fact...a whole wazoolie of
them...and that is why I set the Rule to delete any message that has M, MS,
or Microsoft in the FROM line from the server. See??

You have described it differently this time (", or" instead of ",") so
it appears you weren't using oe filter syntax in your previous post.

Well....I only set the one Rule, which has the activity of 'delete from
server'. As such, there is no option to select the 'stop processing other
rules, so there is no other Rule applied. Thus, with the subject Rule in
place, with the action of 'delete from server', there is no way to set the
stop processing action.

If you haven't got your and's and or's mixed up, it must be finding a
match in an earlier rule and stopping.


Jim.

 

[Veronica Loell]

Jan Il wrote / skrev:

I have think that it has been determined at this point, that it is not
really the fact that the OE Rules are not working properly, but, that there
is a series of messages that the OE program data is not able to detect.

The simplest and most secure way to detect the swen-virus emails are by
using a tool such as MMM that looks at a couple of extra lines along
with the header. There are several such filters available, I have
designed one for example. This would mean using a tool alongside OE
which perhaps is unacceptable to some. But if you really are interested
in doing this I strongly urge you to lean in that direction.

For example theese three simple lines when matched against the header+25
lines will catch all infected swen-email, and should produce no false
positives unless of course you recieve emails with the text 1. or real
emails with corrupt MIME-headers as with 2. and 3.

1. this is the latest version of security update, the
2. Content-Type: audio/x-wav; name=
3. Content-Type: audio/x-midi; name=


- Veronica Loell

 

[Gabriele Neukam]

On that special day, Jan Il, ([email protected]) said...

Return-Path: <[email protected]>
Received: from bqok ([68.2.29.228]) by fed1mtao05.cox.net
(InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP
id <20031008055437.RIYQ10143.fed1mtao05.cox.net@bqok>;
Wed, 8 Oct 2003 01:54:37 -0400

The Return-Path is "(e-mail address removed)", the mail came over the IP number
68.2.29.228

A whois search can give you more details

Suchbegriff: 68.2.29.228
Adresse: whois.arin.netSuchergebnis:


OrgName: Cox Communications Inc.
OrgID: CXA
Address: 1400 Lake Hearn Drive
City: Atlanta
StateProv: GA
PostalCode: 30319
Country: US
NetRange: 68.0.0.0 - 68.15.255.255
CIDR: 68.0.0.0/12
NetName: COX-ATLANTA
NetHandle: NET-68-0-0-0-1
Parent: NET-68-0-0-0-0
NetType: Direct Allocation
NameServer: NS.COX.NET
NameServer: NS.WEST.COX.NET
NameServer: NS.EAST.COX.NET
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 2001-11-12
Updated: 2002-08-21
TechHandle: IC146-ARIN
TechName: Cox Communications, Inc
TechPhone: +1-404-269-7626
TechEmail: (e-mail address removed)
OrgAbuseHandle: IC146-ARIN
OrgAbuseName: Cox Communications, Inc
OrgAbusePhone: +1-404-269-7626
OrgAbuseEmail: (e-mail address removed)
OrgTechHandle: SHACK-ARIN
OrgTechName: Shackelford, Scott
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgTechHandle: WILLI-ARIN
OrgTechName: Williams, Matt
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgName: Cox Communications Inc.
OrgID: CXA
Address: 1400 Lake Hearn Drive
City: Atlanta
StateProv: GA
PostalCode: 30319
Country: US
NetRange: 68.2.0.0 - 68.3.255.255
CIDR: 68.2.0.0/15
NetName: PHRDC-68-2-0-0
NetHandle: NET-68-2-0-0-1
Parent: NET-68-0-0-0-1
NetType: Reassigned
Comment:
RegDate: 2002-05-15
Updated: 2003-02-07
OrgAbuseHandle: IC146-ARIN
OrgAbuseName: Cox Communications, Inc
OrgAbusePhone: +1-404-269-7626
OrgAbuseEmail: (e-mail address removed)
OrgTechHandle: SHACK-ARIN
OrgTechName: Shackelford, Scott
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgTechHandle: WILLI-ARIN
OrgTechName: Williams, Matt
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)

Again this was a mail from a Cox iser to another Cox user. I am afraid
this is the weak point; somehow the filter doesn't work on seemingly
internal mail. Maybe your provider has got an idea how to catch those
special cases.

Also, you can forward the infected mail *without* attachment to
(e-mail address removed) and ask the abuse support to have the owner of the
infected machine clean it or remove it from the internet. I hope they
will do that; my own ISP has a close-to-zero-tolerance with spammers and
virus spreaders. They give one warning, then they disable the mail.


Gabriele Neukam

(e-mail address removed)

 

[Jan Il]

James,

It's a boolean operator that returns a value of TRUE if either (or
both) of its operands is TRUE

'k...didn't think about VBA here, but, now I see where this comes in,
although I do use it in Access.
Sorry that I didn't add all the correct and/or's when stating what I had
added in the FROM part, it just seemed pretty straight on that these were
automatically added between when the entries were individually added in the
Rule.

--

You have described it differently this time (", or" instead of ",") so
it appears you weren't using oe filter syntax in your previous post.


If you haven't got your and's and or's mixed up, it must be finding a
match in an earlier rule and stopping.

Now, this is interesting. Do I understand that you are saying that, even
though I have just the one Rule at this point, that a Rule I might have
created at some point earlier could still have some residual effect to
somehow over ride the only existing Rule criteria? Not meaning to be lippy
here, just trying to sort this out in my head. As there is no other Rule
either above or below the only Rule now being used. But, I'm certainly no
expert, so I am willing to accept the possibility that some prior Rule might
be in some way influencing the current Rule to cause it to be in effective
as written.

I think, that the Rule, as it reads at this time ''where the FROM line
contains 'M' or 'MS' or 'Microsoft', which sets the criteria, and the
action 'delete from server', should cause any messages that have an M or MS
or Microsoft in the FROM line to be deleted from the server. If I am wrong
in this, then I would truly appreciate your pointing out where I have made a
mistake. However, the fact that the Rule, as it is now, does delete most of
the other messages that meet the Rule criteria would seem to indicate that
the Rule is working properly, at least for most of the messages.

Jim.

Thank you for your additional input and information, I really appreciate it.

Jan

 

[Jan Il]

Hi Veronica,

Jan Il wrote / skrev:

The simplest and most secure way to detect the swen-virus emails are by
using a tool such as MMM that looks at a couple of extra lines along
with the header. There are several such filters available, I have
designed one for example. This would mean using a tool alongside OE
which perhaps is unacceptable to some. But if you really are interested
in doing this I strongly urge you to lean in that direction.

For example these three simple lines when matched against the header+25
lines will catch all infected swen-email, and should produce no false
positives unless of course you receive emails with the text 1. or real
emails with corrupt MIME-headers as with 2. and 3.

1. this is the latest version of security update, the
2. Content-Type: audio/x-wav; name=
3. Content-Type: audio/x-midi; name=


- Veronica Loell

I will try this, as I have MW as well, to see how it works with what I'm
getting. I'm game for anything that might find a way to home in on the
part(s) of these messages to keep them from downloading anyway. The message
terminology and structure is changing so often it is hard to keep up with
them. I'm not sure how much internal data OE is capable of reading, but, it
would seem to be a more likely chance to control them by setting some
criteria that would address part of the internal data, which some parts do
not change, than by just external wording.

Thank you for this additional information, I really do appreciate it.

Jan

 

[Jan Il]

Hi Gabriele!

On that special day, Jan Il, ([email protected]) said...

Return-Path: <[email protected]>
Received: from bqok ([68.2.29.228]) by fed1mtao05.cox.net
(InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP
id <20031008055437.RIYQ10143.fed1mtao05.cox.net@bqok>;
Wed, 8 Oct 2003 01:54:37 -0400

The Return-Path is "(e-mail address removed)", the mail came over the IP number
68.2.29.228

A whois search can give you more details

Suchbegriff: 68.2.29.228
Adresse: whois.arin.netSuchergebnis:


OrgName: Cox Communications Inc.
OrgID: CXA
Address: 1400 Lake Hearn Drive
City: Atlanta
StateProv: GA
PostalCode: 30319
Country: US
NetRange: 68.0.0.0 - 68.15.255.255
CIDR: 68.0.0.0/12
NetName: COX-ATLANTA
NetHandle: NET-68-0-0-0-1
Parent: NET-68-0-0-0-0
NetType: Direct Allocation
NameServer: NS.COX.NET
NameServer: NS.WEST.COX.NET
NameServer: NS.EAST.COX.NET
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 2001-11-12
Updated: 2002-08-21
TechHandle: IC146-ARIN
TechName: Cox Communications, Inc
TechPhone: +1-404-269-7626
TechEmail: (e-mail address removed)
OrgAbuseHandle: IC146-ARIN
OrgAbuseName: Cox Communications, Inc
OrgAbusePhone: +1-404-269-7626
OrgAbuseEmail: (e-mail address removed)
OrgTechHandle: SHACK-ARIN
OrgTechName: Shackelford, Scott
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgTechHandle: WILLI-ARIN
OrgTechName: Williams, Matt
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgName: Cox Communications Inc.
OrgID: CXA
Address: 1400 Lake Hearn Drive
City: Atlanta
StateProv: GA
PostalCode: 30319
Country: US
NetRange: 68.2.0.0 - 68.3.255.255
CIDR: 68.2.0.0/15
NetName: PHRDC-68-2-0-0
NetHandle: NET-68-2-0-0-1
Parent: NET-68-0-0-0-1
NetType: Reassigned
Comment:
RegDate: 2002-05-15
Updated: 2003-02-07
OrgAbuseHandle: IC146-ARIN
OrgAbuseName: Cox Communications, Inc
OrgAbusePhone: +1-404-269-7626
OrgAbuseEmail: (e-mail address removed)
OrgTechHandle: SHACK-ARIN
OrgTechName: Shackelford, Scott
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)
OrgTechHandle: WILLI-ARIN
OrgTechName: Williams, Matt
OrgTechPhone: +1-404-269-7626
OrgTechEmail: (e-mail address removed)

Again this was a mail from a Cox iser to another Cox user. I am afraid
this is the weak point; somehow the filter doesn't work on seemingly
internal mail. Maybe your provider has got an idea how to catch those
special cases.

Also, you can forward the infected mail *without* attachment to
(e-mail address removed) and ask the abuse support to have the owner of the
infected machine clean it or remove it from the internet. I hope they
will do that; my own ISP has a close-to-zero-tolerance with spammers and
virus spreaders. They give one warning, then they disable the mail. >

Gabriele Neukam

(e-mail address removed)

Thank you for the breakdown, and I will send the message to the abuse site,
and also to Cox. It does seem that they have been able to curtail some of
the messages, as I have only had a few come through in the last couple of
days (I can view my account from my webmail before I open my OE).

Thank you very much for all your time and help, Gabriele, I really do
appreciate all the information. Although tedious and frustrating, this has
been an extremely educational experience for me, and I have learned a great
deal from all the input and information that all you folks here have
provided on this issue. It has helped me broaden my thinking and research
techniques, as well as troubleshooting areas, which I am sure will come in
very handy in the times ahead. I have also learned about other programs that
can help control these types of problems, and how they work. This is what I
came to this newsgroup for, and I am very glad to see this is what I'm able
to find.

Jan

 

[James Egan]

Now, this is interesting. Do I understand that you are saying that, even
though I have just the one Rule at this point, that a Rule I might have
created at some point earlier could still have some residual effect to
somehow over ride the only existing Rule criteria?

You said in another recent post "Dave...I have set various Rules..."

Do you have one rule or more than one? Surely you can't be just
relying on this one rule to stop swen?


Jim.

 

[FromTheRafters]

...and it downloaded in spite of the Rules in place that says,
any message with an attachment, delete from server.

How is OE supposed to determine whether or not the e-mail
has an attachment without downloading and looking at it? It
looks to me like this rule will cause all e-mail messages that
make it to this rule to be downloaded. This rule thwarts the
effects of its own action (if you didn't want it downloaded).
It would first download the message, find that it indeed does
have an attachment, then delete it from the server.

Unless you have the option checked elsewhere to leave
a copy on the server, downloaded e-mails are deleted
anyway ~ so this rule does nothing at all except thwart
any other rules where the action is to "not download" or
"delete from server" previous to any request to download.

It is beginning to look as if you didn't simplify as I had
previously thought that you had. The rule that you just
mentioned is in error. You must not use data which is
not in the header to effect an action of "delete from
server", or "do not download", because it is self defeating.

 

[Jan Il]

Jim,

You said in another recent post "Dave...I have set various Rules..."

Yes, I did say that, and this statement was made in order to explain
that I have experimented with various Rules, trying various types of Rules,
actions, criteria, to see which ones did and did not work. *But*, I have
also stated in numerous posts in this thread that I have only one Rule in
place at a time. It is really the only way I can test how each acts or
reacts to the different messages. The one that is now in place is the most
basic, clear, straight forward. Rule: 'where the FROM line contains 'M' or
'MS'
or 'Microsoft', Action: 'delete from server'. It does not involve any 'stop
processing' as the action 'delete from server' does not even allow you to
select 'stop processing other rules', as it is grayed out.

Do you have one rule or more than one? Surely you can't be just
relying on this one rule to stop swen?

Jim.

Yeppers...I surely am relying on this one Rule to stop the majority of the
Swen...and it *does*
do what it is supposed to do with all the Swen messages that fit the
criteria, *expect* for
certain types of the messages that are being allowed to be downloaded around
it, even though they do meet the Rule criteria. I don't believe that it is
the Rule that is the failure...but, something in the makeup of these
particular messages that is allowing them to circumvent the Rule criteria. I
said early on, that something in these messages was different, and with the
help of others like yourself here, I am beginning to see where this 'worm
hole' may be.

Why am I bothering to keep looking through the keyhole, first eating the
cookie that says "Shrink Me', then the one that does the opposite, when
there are simpler solutions at my finger tips? Simple... I'm curious. I'm
a
researcher. And, if something this vicious is able to force itself into my
inbox, then I want to know how and why. If it is somehow something that is
a result of a shortfall on the part of my ISP, or MS programming of their
security data with all the new gar'bage these days, or even myself,
well...then I want to know. While I can't do anything about MS...I can sure
present the facts to my ISP. But, that is what it will take...facts..not
just a theory. It is the facts that I am after.

I know this thread is long, and there's a lot of different input and
information on various levels and such, and I am truly sorry if my replies
to specific questions or suggestions to individual responders may seem to
confuse, I am trying to address the specifics in as detailed and clear a
manner as I can as it applies. As I am yours. And, like you, there are
a lot who have not yet experienced this particular problem, or who don't
even have OE, but, are open minded and trying to look at all aspects of
what/where/how this could be happening, and offering suggestions or
information based upon their experience.

Thank you Jim, for your time and input, I really do appreciate it.

Jan

 

[Jan Il]

Hi Rafters,

How is OE supposed to determine whether or not the e-mail
has an attachment without downloading and looking at it? It
looks to me like this rule will cause all e-mail messages that
make it to this rule to be downloaded. This rule thwarts the
effects of its own action (if you didn't want it downloaded).
It would first download the message, find that it indeed does
have an attachment, then delete it from the server.

And...you're asking 'me' how OE is supposed to determine this?? Hey,
remember me, I am the learnee here <vbg>
However, if it is indeed true, and I am not doubting you, just asking, that
the message must first be downloaded for the Rule to apply, then why does MS
provide for this action 'delete from server'. It is somewhat misleading in
it's inference by terminology that the message would indeed be deleted from
the server level at the point of contact by the Rule criteria. Being a
novice at all this, and not that familiar with all the workings of how the
programming works to seek out and determine if a message meets specific
criteria for the Rule action to act on, or at what point in the loading
process....well...I am sorta lost on this concept.

Unless you have the option checked elsewhere to leave
a copy on the server, downloaded e-mails are deleted
anyway ~ so this rule does nothing at all except thwart
any other rules where the action is to "not download" or
"delete from server" previous to any request to download.

No Rafters, I don't have any have any options in place to provide for a copy
to be left of the server. To clarify, I only have 1, One, #1, Uno, Rule in
place at this time. It is..Rule: 'where the FROM line contains "M' or 'MS'
or Microsoft'; Action: 'delete from server'. I have tied to keep it as
basic and simple as I can. There are no other Rules above or below this one
and only Rule, so there should not be anything that can interfere with this
only Rule as far as I have been able to derive.

It is beginning to look as if you didn't simplify as I had
previously thought that you had. The rule that you just
mentioned is in error. You must not use data which is
not in the header to effect an action of "delete from
server", or "do not download", because it is self defeating.

I am sorry for the confusion on my part to be more clear. But, would you
please clarify a bit more on this statement. I thought that I had referred
to the correct criteria data in the headers in the FROM line. However, if
this is not the case, then what have I left out or entered incorrectly? I
would truly appreciate it if you would explain this concept and where my
thinking is in error. I truly apologize for being so very dense on this,
but, the inference of the Rule options and what you are saying as
to the 'delete from server' is somewhat confusing. In what way is
it self-defeating?Thank you,

Jan

 

[James Egan]

Mailwasher allows for a partial DL with the first 20 lines as minimum.

If it's a minimum, how do you to increase it?

This is enough to spot a format tag for HTML, then the message is
flagged no matter how big it really is.
Downloading only the first twenty lines makes no perceptible difference
in speed over just the headers alone.

Loads of them have more than 20 lines of (body) crap before getting to
the html tag.


Jim.

 

[Bart Bailey]

In Message-ID:<[email protected]> posted on

If it's a minimum, how do you to increase it?

It can be set from 20 up to 800 lines

Loads of them have more than 20 lines of (body) crap before getting to
the html tag.

I haven't gotten any like that yet,
the <HTML> tag occurs very early in all the spam I get.

 

[Veronica Loell]

Jan Il wrote / skrev:
Small email-school ;-)

An email-program can choose between 3 things basically in regards to how
they get information about an emailmessage from the server.

1. simply getting the size of the message (usually this is done by
sending the LIST-command which returns a lista of all message-ids along
with their size.
2. getting just the header of the message. This is the part that
contains information about subject, from, to date etc. Optionally one
can get additional lines along with the header (this is what I use in my
filter for MMM3, download for each message 25 lines along with the header).
3. get the entire message.

Now as for attachments. If doing 2 the email-program will know whether
the message has any attachments because it will contain a line like:
"Content-Type: multipart/"

The thing to consider when setting your email-client to automatically
delete all messages containing attachments is that it will delete
HTML-format emails, and also emails with signatures produced by some
Microsoft programs.

- Veronica Loell

 

[James Egan]

It can be set from 20 up to 800 lines

Is that in the registered version only? I can't see an editable
setting in the free version.

Maybe it's a registry setting?


Jim.