You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ted Mittelstaedt <te...@ipinc.net> on 2010/02/09 21:58:01 UTC
Newest spammer trick - non-blank subject lines?
OK All,
Please let me know if anyone has seen this one before.
We have SA configured to insert "*****SPAM***** in the
beginning of the subject lines of spams before sending them on to
customers, then mail the message as an attachment to the user
along with the SA report as to why it's spam.
Lately I've seen a new trick the spammers are using.
They are putting characters in the subject line that
are not text characters - I don't know what they are,
I haven't looked into this closely yet. Our SA installation
is correctly tagging this as spam and sending it forward
to the user.
The problem is the mail client program, specifically
Thunderbird. There must be a bug in T-bird that is tickled
by these non-text characters because although the Subject
line exists with ***SPAM*** in it if I look at the actual
message in the mailbox with an editor, T-bird displays
the subject line as a BLANK subject. Of course, since the
Subject is blank then you don't see that it is SPAM and
you have to go to the bother of opening it before you see
the SA report that it's spam.
This has only happened to a few spams so far, and I want
to nip it in the bud.
Now, why don't I just write a rule in T-bird that trashes mail
that has a blank subject line, I hear you ask?
It's because we have a few moronic customers who seem to
think it's OK to send out e-mails with blank subject lines!!
It would be most useful if when SA was creating the subject
lines of the e-mails with the spams attached, that instead of
just blindly copying over the Subject line from the spam and
inserting the *****SPAM***** in front of the subject, that
SA stripped out all the non-text characters in the Subject
line.
Any suggestions appreciated! (even the smart-ass ones but
they have to be clever)
Thanks!
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 09 February 2010, Mike Cardwell wrote:
>On 09/02/2010 22:56, Ted Mittelstaedt wrote:
>
>I sometimes send email without adding a Subject line. I guess that makes
>me "moronic" in your eyes. Oh well.
Chuckle, so do I, entirely too often, Mike. But kmail checks before sending
it, and if the Subject: line is blank, it calls it to my attention & offers
me a chance to fix it. Saved my bum many a time. ;)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
All theoretical chemistry is really physics; and all theoretical chemists
know it.
-- Richard P. Feynman
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mark Martinec wrote:
> On Wednesday February 10 2010 10:45:37 Mike Cardwell wrote:
>> On 10/02/2010 00:31, Kai Schaetzl wrote:
>>>> MISSING_SUBJECT,
>>>>
>>>> Now, why the message that SA is creating is getting TWO Subject: lines
>>>> is a different question.
>>> because SA thinks it's got no subject, so it adds one as it is instructed
>>> to tag the subject. Obviously, it wants to see at least a whitespace
>>> after the colon to accept it as a header.
>> I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of
>> these commands lead to SpamAssassin outputting a single "Subject:
>> *****SPAM*****" header:
>>
>> echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
>> echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
>
> Indeed, the bug was fixed with v3.3.0 (Bug 6016).
>
>
> Kai Schaetzl wrote:
>> I did some research on this matter some
>> time ago and if I remember correctly the latest RFCs (5322, maybe 2822)
>> indeed require a whitespace while older RFCs (822) were not 100% clear
>> about this.
>
> This is incorrect. A space is not required after a colon.
> Both the RFC 5322 and RFC 2822 are perfectly clear on this.
>
>
> Ted Mittelstaedt wrote:
>>> So Thunderbird displays the last Subject line header it comes across.
>>> Is that incorrect behaviour for an MUA?
>> I think it is. Setting aside the question of whether they are supposed
>> to be there or not, the purpose of an MUA is to make it easier for
>> the user to interact with a mail message. Multiple Subject: lines
>> can contain multiple amounts of information, and only displaying the
>> last Subject line is denying the user information that they are
>> supposed to be able to see see.
>
> The RFC 5322 (and RFC 2822) require that a Subject header field
> appears zero or one time. Multiple Subject header fields are not allowed.
> A MUA can do whatever it pleases with syntactically invalid mail messages:
> garbage-in, garbage-out.
>
> Mark
The intent of the people who wrote the MUA under question was to assist
users to read mail, it was NOT to advance an agenda on the
Internet. If you want to use MUA's which attempt to enforce agendas
then there are plenty of those out there - you can start with Outlook.
I would assume that by definition any MUA written to help users has
a flaw in it if it does something that makes it harder for the user
to read mail. That is why I consider this incorrect behavior. An
MUA that's goal was to assist should at least make an effort to notify
the user that there's a problem with the message. And as a matter
of fact, Thunderbird DOES do this quite a lot with other types of errors
on e-mail messages.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Mark Martinec <Ma...@ijs.si>.
On Wednesday February 10 2010 10:45:37 Mike Cardwell wrote:
> On 10/02/2010 00:31, Kai Schaetzl wrote:
> >> MISSING_SUBJECT,
> >>
> >> Now, why the message that SA is creating is getting TWO Subject: lines
> >> is a different question.
> >
> > because SA thinks it's got no subject, so it adds one as it is instructed
> > to tag the subject. Obviously, it wants to see at least a whitespace
> > after the colon to accept it as a header.
>
> I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of
> these commands lead to SpamAssassin outputting a single "Subject:
> *****SPAM*****" header:
>
> echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
> echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
Indeed, the bug was fixed with v3.3.0 (Bug 6016).
Kai Schaetzl wrote:
> I did some research on this matter some
> time ago and if I remember correctly the latest RFCs (5322, maybe 2822)
> indeed require a whitespace while older RFCs (822) were not 100% clear
> about this.
This is incorrect. A space is not required after a colon.
Both the RFC 5322 and RFC 2822 are perfectly clear on this.
Ted Mittelstaedt wrote:
>> So Thunderbird displays the last Subject line header it comes across.
>> Is that incorrect behaviour for an MUA?
>
> I think it is. Setting aside the question of whether they are supposed
> to be there or not, the purpose of an MUA is to make it easier for
> the user to interact with a mail message. Multiple Subject: lines
> can contain multiple amounts of information, and only displaying the
> last Subject line is denying the user information that they are
> supposed to be able to see see.
The RFC 5322 (and RFC 2822) require that a Subject header field
appears zero or one time. Multiple Subject header fields are not allowed.
A MUA can do whatever it pleases with syntactically invalid mail messages:
garbage-in, garbage-out.
Mark
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Kai Schaetzl wrote:
> Ted Mittelstaedt wrote on Tue, 09 Feb 2010 14:56:49 -0800:
>
>> MISSING_SUBJECT,
>
>> Now, why the message that SA is creating is getting TWO Subject: lines
>> is a different question.
>
> because SA thinks it's got no subject, so it adds one as it is instructed
> to tag the subject. Obviously, it wants to see at least a whitespace after
> the colon to accept it as a header.
Ah, I see, I see. The caveat of course is that the message must be
spam, since a regular non-spam message isn't going to trigger the
subject tagging. Such as the test message I typed into port 25.
Ted
> I did some research on this matter some
> time ago and if I remember correctly the latest RFCs (5322, maybe 2822)
> indeed require a whitespace while older RFCs (822) were not 100% clear
> about this. And it's good practice for clients to be forgiving in the
> interpretation of received messages. Thus, Thunderbird finds two subjects
> and displays the second one. I'm sure it's not the only program that does
> that.
> What SA probably should do is use the existing subject header, repair it
> with a whitespace and then tag it.
> To be sure that there are really no characters (you said there are some
> unprintable characters, but it rather looks like there are no characters at
> all) you should examine that message with a hex editor.
>
> Kai
>
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 10/02/2010 00:31, Kai Schaetzl wrote:
>> MISSING_SUBJECT,
>
>> Now, why the message that SA is creating is getting TWO Subject: lines
>> is a different question.
>
> because SA thinks it's got no subject, so it adds one as it is instructed
> to tag the subject. Obviously, it wants to see at least a whitespace after
> the colon to accept it as a header.
I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of
these commands lead to SpamAssassin outputting a single "Subject:
*****SPAM*****" header:
echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Kai Schaetzl <ma...@conactive.com>.
Ted Mittelstaedt wrote on Tue, 09 Feb 2010 14:56:49 -0800:
> MISSING_SUBJECT,
> Now, why the message that SA is creating is getting TWO Subject: lines
> is a different question.
because SA thinks it's got no subject, so it adds one as it is instructed
to tag the subject. Obviously, it wants to see at least a whitespace after
the colon to accept it as a header. I did some research on this matter some
time ago and if I remember correctly the latest RFCs (5322, maybe 2822)
indeed require a whitespace while older RFCs (822) were not 100% clear
about this. And it's good practice for clients to be forgiving in the
interpretation of received messages. Thus, Thunderbird finds two subjects
and displays the second one. I'm sure it's not the only program that does
that.
What SA probably should do is use the existing subject header, repair it
with a whitespace and then tag it.
To be sure that there are really no characters (you said there are some
unprintable characters, but it rather looks like there are no characters at
all) you should examine that message with a hex editor.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mike Cardwell wrote:
> On 10/02/2010 00:04, Ted Mittelstaedt wrote:
>
>>>> Thunderbird only displays the SECOND subject line.
>>> So Thunderbird displays the last Subject line header it comes across. Is
>>> that incorrect behaviour for an MUA?
>> I think it is. Setting aside the question of whether they are supposed
>> to be there or not, the purpose of an MUA is to make it easier for
>> the user to interact with a mail message. Multiple Subject: lines
>> can contain multiple amounts of information, and only displaying the
>> last Subject line is denying the user information that they are
>> supposed to be able to see see.
>>
>> A deeper question is do all parts of t-bird treat this equally. If
>> the filtering in t-bird reacts to both Subject line contents then
>> this definitely is a bug. A user might have a filter saying
>> "delete all mail with viagrera in its subject line except mail
>> that has "fred" in it's subject line. The spammer sends a message
>> with the first subject line having viagrera in it, the second
>> subject line having fred in it, and the message is not deleted - but
>> the display only shows viagrea.
>
> You could probably have tested that yourself in the time it took you to
> write that paragraph.
>
Yes but since this is a spamassassin mailing list, I doubt most
users would be interested in a long discussion of problems with
t-bird.
If your a t-bird user who cares, you will investigate it. I don't,
frankly. Once I saw that SA was producing the double "Subject: " line
entries then it seems to me that further discussion on t-bird's
behavior is not warranted, epically on this mailing list.
>>> Is it valid for an email to have
>>> more than one Subject line?
>> I do not think this defined anywhere. But I won't swear to it. I
>> think it's not particularly valid, however because the results are
>> undefined.
>
> Did you check? I would bet that it is defined...
>
> I just took a quick gander at rfc2822 and it states:
>
> "No multiple occurrences of fields (except resent and received).*"
>
> There might be other RFCs involved, but it looks to me from that as
> though it's only valid for an email to have one Subject header. It's
> understandable that an MUA might not display an invalidly formatted
> email correctly.
>
I'll repeat, it seems to me that further discussion on t-bird's
behavior is not warranted, epically on this mailing list.
>>> Bring it up with Mozilla.
>>>
>> Since this is a SA bug I think I will file it with Mozilla just
>> to have it in the database, but I would only argue for internal
>> consistency in t-bird.
>
> You've no reason to believe there is any internal inconsistency with
> regards to how Thunderbird treats Subject lines. And if it's true that
> it's not valid for an email to have more than one Subject line then this
> is not a Thunderbird bug, but still something that they may or may not
> wish to workaround.
>
I'll repeat, it seems to me that further discussion on t-bird's
behavior is not warranted, epically on this mailing list.
Seriously! I know it's a fun diversion, but lets get back to the
real issue.
>> At this point I am up against a wall. For starters this is an old ver
>> of sa, old sendmail, etc. This server is scheduled for re-gen soon and
>> there's no point in filing a bug on the old code. I will continue to
>> observe and once the server is re-gened then if it keeps happening then
>> I'll look into it further. I'll probably have to run the server for a
>> few hours with SA turned off to get the raw spam, not something that is
>> going to be very popular.
>
> Alternatively, configure your MTA to deliver an unmodified second copy
> of all incoming email to a separate maildir.
>
Yup.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 10/02/2010 00:04, Ted Mittelstaedt wrote:
>>> Thunderbird only displays the SECOND subject line.
>>
>> So Thunderbird displays the last Subject line header it comes across. Is
>> that incorrect behaviour for an MUA?
>
> I think it is. Setting aside the question of whether they are supposed
> to be there or not, the purpose of an MUA is to make it easier for
> the user to interact with a mail message. Multiple Subject: lines
> can contain multiple amounts of information, and only displaying the
> last Subject line is denying the user information that they are
> supposed to be able to see see.
>
> A deeper question is do all parts of t-bird treat this equally. If
> the filtering in t-bird reacts to both Subject line contents then
> this definitely is a bug. A user might have a filter saying
> "delete all mail with viagrera in its subject line except mail
> that has "fred" in it's subject line. The spammer sends a message
> with the first subject line having viagrera in it, the second
> subject line having fred in it, and the message is not deleted - but
> the display only shows viagrea.
You could probably have tested that yourself in the time it took you to
write that paragraph.
>> Is it valid for an email to have
>> more than one Subject line?
>
> I do not think this defined anywhere. But I won't swear to it. I
> think it's not particularly valid, however because the results are
> undefined.
Did you check? I would bet that it is defined...
I just took a quick gander at rfc2822 and it states:
"No multiple occurrences of fields (except resent and received).*"
There might be other RFCs involved, but it looks to me from that as
though it's only valid for an email to have one Subject header. It's
understandable that an MUA might not display an invalidly formatted
email correctly.
>> Bring it up with Mozilla.
>>
>
> Since this is a SA bug I think I will file it with Mozilla just
> to have it in the database, but I would only argue for internal
> consistency in t-bird.
You've no reason to believe there is any internal inconsistency with
regards to how Thunderbird treats Subject lines. And if it's true that
it's not valid for an email to have more than one Subject line then this
is not a Thunderbird bug, but still something that they may or may not
wish to workaround.
> At this point I am up against a wall. For starters this is an old ver
> of sa, old sendmail, etc. This server is scheduled for re-gen soon and
> there's no point in filing a bug on the old code. I will continue to
> observe and once the server is re-gened then if it keeps happening then
> I'll look into it further. I'll probably have to run the server for a
> few hours with SA turned off to get the raw spam, not something that is
> going to be very popular.
Alternatively, configure your MTA to deliver an unmodified second copy
of all incoming email to a separate maildir.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Per Jessen <pe...@computer.org>.
Ted Mittelstaedt wrote:
> Multiple Subject: lines can contain multiple amounts of information,
> and only displaying the last Subject line is denying the user
> information that they are supposed to be able to see see.
Multiple Subject: lines are not allowed according to RFC5322 - only zero
or one only.
/Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: "Ted Mittelstaedt" <te...@ipinc.net>
> At this point I am up against a wall. For starters this is an old ver
> of sa, old sendmail, etc. This server is scheduled for re-gen soon and
> there's no point in filing a bug on the old code. I will continue to
> observe and once the server is re-gened then if it keeps happening then
> I'll look into it further. I'll probably have to run the server for a
> few hours with SA turned off to get the raw spam, not something that is
> going to be very popular.
An old (really old) version of SA might show that problem. I seem to
remember it being noted and fixed a long time ago. (2.3xish is when I
started fiddling with this beastie.)
You may be seriously stuck if you cannot upgrade. You might have to
generate a special filter for your milter that looks for an empty
second subject line and simply deletes it.
{^_^}
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mike Cardwell wrote:
> On 09/02/2010 22:56, Ted Mittelstaedt wrote:
>
> I sometimes send email without adding a Subject line. I guess that makes
> me "moronic" in your eyes. Oh well.
>
>> OK I did it - and this one is really, really cool!!!
>
> Not really.
>
>> SA processes it and here's the result:
>>
>>
>> From maumet@ionizer.nl Tue Feb 9 14:22:38 2010
>> Return-Path: <ma...@ionizer.nl>
>> Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com
>> [71.87.206.218])
>> by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540
>> for <ne...@ipinc.net>; Tue, 9 Feb 2010 14:22:35 -0800 (PST)
>> (envelope-from maumet@ionizer.nl)
>> From: Bugarewicz <ma...@ionizer.nl>
>> To: newuser@ipinc.net
>> MIME-Version: 1.0
>> Content-Type: multipart/mixed; boundary="----------=_4B71E02E.A0717A8B"
>> Date: Tue, 09 Feb 2010 17:22:37 -0500
>> Subject: *****SPAM*****
>> Subject:
>
> <snip rest of message>
>
>> Thunderbird only displays the SECOND subject line.
>
> So Thunderbird displays the last Subject line header it comes across. Is
> that incorrect behaviour for an MUA?
I think it is. Setting aside the question of whether they are supposed
to be there or not, the purpose of an MUA is to make it easier for
the user to interact with a mail message. Multiple Subject: lines
can contain multiple amounts of information, and only displaying the
last Subject line is denying the user information that they are
supposed to be able to see see.
A deeper question is do all parts of t-bird treat this equally. If
the filtering in t-bird reacts to both Subject line contents then
this definitely is a bug. A user might have a filter saying
"delete all mail with viagrera in its subject line except mail
that has "fred" in it's subject line. The spammer sends a message
with the first subject line having viagrera in it, the second
subject line having fred in it, and the message is not deleted - but
the display only shows viagrea.
> Is it valid for an email to have
> more than one Subject line?
I do not think this defined anywhere. But I won't swear to it. I
think it's not particularly valid, however because the results are
undefined.
> Bring it up with Mozilla.
>
Since this is a SA bug I think I will file it with Mozilla just
to have it in the database, but I would only argue for internal
consistency in t-bird.
>> Now, why the message that SA is creating is getting TWO Subject: lines
>> is a different question.
>>
>> cat -v does not show any non-printable chars.
>
> Try saving it to disk and uploading it using the file upload method to
> spamalyser.com. It might show characters that you can't see.
>
To determine this I tailed it from the mail file then cat -v'ed it.
this is on the actual UNIX server the mailbox is on. The mailbox is
in mbox format. If you understand how cat -v works you will understand
that there are no chars I can't see.
I can try uploading to spamalyser but this is after SA has processed
the message, so the internal structure of the message has been altered
already and whatever condition caused the bug is probably gone. I need
the raw message.
>> Here's the original header from the SA attachment:
>
> <snip to subject>
>
>> Subject:
>
> So that's just a blank subject line? Using SpamAssassin 3.3 here, if I
> run this command:
>
> echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
>
> I end up with a single Subject line of:
>
> Subject: *****SPAM*****
>
> And no additional empty subject line. That's how it should work.
>
And that is how it works here, too, when the normal blank-subject-line
spam comes in.
Something is different with these spams that is causing the SA parser to
duplicate the Subject line.
At this point I am up against a wall. For starters this is an old ver
of sa, old sendmail, etc. This server is scheduled for re-gen soon and
there's no point in filing a bug on the old code. I will continue to
observe and once the server is re-gened then if it keeps happening then
I'll look into it further. I'll probably have to run the server for a
few hours with SA turned off to get the raw spam, not something that is
going to be very popular.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 09/02/2010 22:56, Ted Mittelstaedt wrote:
I sometimes send email without adding a Subject line. I guess that makes
me "moronic" in your eyes. Oh well.
> OK I did it - and this one is really, really cool!!!
Not really.
> SA processes it and here's the result:
>
>
> From maumet@ionizer.nl Tue Feb 9 14:22:38 2010
> Return-Path: <ma...@ionizer.nl>
> Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com
> [71.87.206.218])
> by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540
> for <ne...@ipinc.net>; Tue, 9 Feb 2010 14:22:35 -0800 (PST)
> (envelope-from maumet@ionizer.nl)
> From: Bugarewicz <ma...@ionizer.nl>
> To: newuser@ipinc.net
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="----------=_4B71E02E.A0717A8B"
> Date: Tue, 09 Feb 2010 17:22:37 -0500
> Subject: *****SPAM*****
> Subject:
<snip rest of message>
> Thunderbird only displays the SECOND subject line.
So Thunderbird displays the last Subject line header it comes across. Is
that incorrect behaviour for an MUA? Is it valid for an email to have
more than one Subject line? Bring it up with Mozilla.
> Now, why the message that SA is creating is getting TWO Subject: lines
> is a different question.
>
> cat -v does not show any non-printable chars.
Try saving it to disk and uploading it using the file upload method to
spamalyser.com. It might show characters that you can't see.
> Here's the original header from the SA attachment:
<snip to subject>
> Subject:
So that's just a blank subject line? Using SpamAssassin 3.3 here, if I
run this command:
echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin
I end up with a single Subject line of:
Subject: *****SPAM*****
And no additional empty subject line. That's how it should work.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Martin Gregorie wrote:
> On Tue, 2010-02-09 at 15:44 -0800, Ted Mittelstaedt wrote:
>> if I load it up in vi then vi claims there is a single blank
>> space after the colon.
>>
> It would be better to use od or beav rather than vi - both use
> unambiguous notation for non-printable bytes. beav (if you have it) will
> show you exactly what's there in a scrolling screen. So will
> "od -c file" if you pipe it through less.
>
Apparently you missed my statement earlier that I already
ran it through cat -v
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-09 at 15:44 -0800, Ted Mittelstaedt wrote:
> if I load it up in vi then vi claims there is a single blank
> space after the colon.
>
It would be better to use od or beav rather than vi - both use
unambiguous notation for non-printable bytes. beav (if you have it) will
show you exactly what's there in a scrolling screen. So will
"od -c file" if you pipe it through less.
Martin
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Karsten Bräckelmann wrote:
> On Tue, 2010-02-09 at 14:56 -0800, Ted Mittelstaedt wrote:
>> Karsten Bräckelmann wrote:
>
>>> Even though this most likely is a TB bug, it would be interesting to
>>> have a look at these headers. If possible, the raw one, prior to your SA
>>> header munging, err, rewriting option.
>> OK I did it - and this one is really, really cool!!!
>>
>> Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail
>> message.
>>
>> SA processes it and here's the result:
> [...]
>> Date: Tue, 09 Feb 2010 17:22:37 -0500
>> Subject: *****SPAM*****
>> Subject:
>
> The second one does not have a space (or tab) after the colon. An
> artifact of copy-n-paste, or the same with the raw message?
>
if I load it up in vi then vi claims there is a single blank
space after the colon.
>
>> Thunderbird only displays the SECOND subject line.
>>
>> Now, why the message that SA is creating is getting TWO Subject: lines
>> is a different question.
>>
>> cat -v does not show any non-printable chars.
>>
>> Here's the original header from the SA attachment:
> [...]
>> Date: Tue, 09 Feb 2010 17:22:37 -0500
>> Subject:
>
> Single Subject header. No white-space here either. Again, copy-n-paste?
>
No. once more, vi claims there is a single blank space after the colon
> What about the RAW, incoming mail, as fed into SA? No white-space there
> either? Any monkey business in the original header?
>
I don't have that. All mail that comes in to here goes through
sa-milter.
However, I telnetted into port 25 and just typed in a test message.
When I used "Subject:" WITHOUT a trailing space after the colon, the
resulting message in my inbox - with SA headers that of course
don't say the message is spam - DOES HAVE a single trailing space after
the colon.
It DOES NOT have 2 "Subject: lines, however.
> This might after all turn out to be a SA header re-write bug. :(
>
>
I suspect it is. I also tried this test on another mailserver we
have here that's running a similar setup EXCEPT for SA - and it
DOES NOT have the trailing space after the Subject: So clearly
SA is adding that trailing space.
I'm not sure, though, that the addition of the trailing space in
the Subject: line has any relevance to the duplicated Subject line.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-09 at 14:56 -0800, Ted Mittelstaedt wrote:
> Karsten Bräckelmann wrote:
> > Even though this most likely is a TB bug, it would be interesting to
> > have a look at these headers. If possible, the raw one, prior to your SA
> > header munging, err, rewriting option.
>
> OK I did it - and this one is really, really cool!!!
>
> Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail
> message.
>
> SA processes it and here's the result:
[...]
> Date: Tue, 09 Feb 2010 17:22:37 -0500
> Subject: *****SPAM*****
> Subject:
The second one does not have a space (or tab) after the colon. An
artifact of copy-n-paste, or the same with the raw message?
> Thunderbird only displays the SECOND subject line.
>
> Now, why the message that SA is creating is getting TWO Subject: lines
> is a different question.
>
> cat -v does not show any non-printable chars.
>
> Here's the original header from the SA attachment:
[...]
> Date: Tue, 09 Feb 2010 17:22:37 -0500
> Subject:
Single Subject header. No white-space here either. Again, copy-n-paste?
What about the RAW, incoming mail, as fed into SA? No white-space there
either? Any monkey business in the original header?
This might after all turn out to be a SA header re-write bug. :(
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: "Ted Mittelstaedt" <te...@ipinc.net>
Sent: Tuesday, 2010/February/09 14:56
> Karsten Bräckelmann wrote:
>> On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote:
>>> The problem is the mail client program, specifically
>>> Thunderbird. There must be a bug in T-bird that is tickled
>>> by these non-text characters because although the Subject
>>> line exists with ***SPAM*** in it if I look at the actual
>>> message in the mailbox with an editor, T-bird displays
>>> the subject line as a BLANK subject.
>>
>> As you said, this appears to be a thunderbird issue. Went there to
>> report it?
>>
>>
>>> Now, why don't I just write a rule in T-bird that trashes mail
>>> that has a blank subject line, I hear you ask?
>>
>> Err, nope. :) Note that the Subject actually is NOT empty, as you said.
>> And unless filtering in TB on (raw or decoded) headers is affected by
>> the very same bug /displaying/ the Subject header in a specific widget
>> is... Very unlikely. What's invisible to the eye in the UI seriously
>> isn't invisible to code logic.
>>
>> This appears to be a client *rendering*, displaying bug. Not to be
>> confused with an actual empty header (which isn't the same as a missing
>> header either) to filter on.
>>
>>
>> Even though this most likely is a TB bug, it would be interesting to
>> have a look at these headers. If possible, the raw one, prior to your SA
>> header munging, err, rewriting option.
>>
>
> OK I did it - and this one is really, really cool!!!
>
> Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail
> message.
>
> SA processes it and here's the result:
>
>
> From maumet@ionizer.nl Tue Feb 9 14:22:38 2010
> Return-Path: <ma...@ionizer.nl>
> Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com
> [71.87.206.218])
> by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540
> for <ne...@ipinc.net>; Tue, 9 Feb 2010 14:22:35 -0800 (PST)
> (envelope-from maumet@ionizer.nl)
> From: Bugarewicz <ma...@ionizer.nl>
> To: newuser@ipinc.net
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="----------=_4B71E02E.A0717A8B"
> Date: Tue, 09 Feb 2010 17:22:37 -0500
> Subject: *****SPAM*****
> Subject:
> Message-ID: <12...@nosbih.ba>
> X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net
> [65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST)
> X-Spam-Flag: YES
> X-Spam-Status: Yes, score=11.7 required=4.1
> tests=DYN_RDNS_AND_INLINE_IMAGE,
>
> EMPTY_MESSAGE,MISSING_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_XBL,
> RDNS_DYNAMIC,SPF_NEUTRAL,TVD_SPACE_RATIO autolearn=disabled
> version=3.2.3
> X-Spam-Level: ***********
> X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.ipinc.net
> Status: O
> X-Status:
> X-Keywords:
> X-UID: 25585826
>
>
> Thunderbird only displays the SECOND subject line.
>
>
> Now, why the message that SA is creating is getting TWO Subject: lines is
> a different question.
>
> cat -v does not show any non-printable chars.
>
> Here's the original header from the SA attachment:
I don't see a problem here with what got through the emails for that
header here. I submit it's a bug in your setup, Ted. Empty subjects
here end up looking quite normal here.
===8<---
To: undisclosed recipients:;
Subject: *****SPAM***** 007.9 **
Date: Tue, 9 Feb 2010 02:11:22 -0800 (PST)
Message-Id: <36...@web82008.mail.mud.yahoo.com>
===8<---
I have SpamAssassin provide the markup. How do you generate your markup?
{^_^}
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Karsten Bräckelmann wrote:
> On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote:
>> The problem is the mail client program, specifically
>> Thunderbird. There must be a bug in T-bird that is tickled
>> by these non-text characters because although the Subject
>> line exists with ***SPAM*** in it if I look at the actual
>> message in the mailbox with an editor, T-bird displays
>> the subject line as a BLANK subject.
>
> As you said, this appears to be a thunderbird issue. Went there to
> report it?
>
>
>> Now, why don't I just write a rule in T-bird that trashes mail
>> that has a blank subject line, I hear you ask?
>
> Err, nope. :) Note that the Subject actually is NOT empty, as you said.
> And unless filtering in TB on (raw or decoded) headers is affected by
> the very same bug /displaying/ the Subject header in a specific widget
> is... Very unlikely. What's invisible to the eye in the UI seriously
> isn't invisible to code logic.
>
> This appears to be a client *rendering*, displaying bug. Not to be
> confused with an actual empty header (which isn't the same as a missing
> header either) to filter on.
>
>
> Even though this most likely is a TB bug, it would be interesting to
> have a look at these headers. If possible, the raw one, prior to your SA
> header munging, err, rewriting option.
>
OK I did it - and this one is really, really cool!!!
Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail
message.
SA processes it and here's the result:
From maumet@ionizer.nl Tue Feb 9 14:22:38 2010
Return-Path: <ma...@ionizer.nl>
Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com
[71.87.206.218])
by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540
for <ne...@ipinc.net>; Tue, 9 Feb 2010 14:22:35 -0800 (PST)
(envelope-from maumet@ionizer.nl)
From: Bugarewicz <ma...@ionizer.nl>
To: newuser@ipinc.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4B71E02E.A0717A8B"
Date: Tue, 09 Feb 2010 17:22:37 -0500
Subject: *****SPAM*****
Subject:
Message-ID: <12...@nosbih.ba>
X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net
[65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST)
X-Spam-Flag: YES
X-Spam-Status: Yes, score=11.7 required=4.1 tests=DYN_RDNS_AND_INLINE_IMAGE,
EMPTY_MESSAGE,MISSING_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_XBL,
RDNS_DYNAMIC,SPF_NEUTRAL,TVD_SPACE_RATIO autolearn=disabled
version=3.2.3
X-Spam-Level: ***********
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.ipinc.net
Status: O
X-Status:
X-Keywords:
X-UID: 25585826
Thunderbird only displays the SECOND subject line.
Now, why the message that SA is creating is getting TWO Subject: lines
is a different question.
cat -v does not show any non-printable chars.
Here's the original header from the SA attachment:
------------=_4B71E02E.A0717A8B
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: attachment
Content-Transfer-Encoding: 8bit
X-Envelope-From: <ma...@ionizer.nl>
X-Envelope-To: <ne...@ipinc.net>
Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com
[71.87.206.218])
by mail.ipinc.net(8.13.8/8.13.8) with SMTP id o19MMY9W075540
Tue, 9 Feb 2010 14:22:34 -0800 (PST)
(envelope-from <ma...@ionizer.nl>
From: Bugarewicz <ma...@ionizer.nl>
To: newuser@ipinc.net
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="-------------0BCB4D94223158510682CA52847"
Date: Tue, 09 Feb 2010 17:22:37 -0500
Subject:
Message-ID: <12...@nosbih.ba>
X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net
[65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST)
This is a multi-part message in MIME format.
---------------0BCB4D94223158510682CA52847
Content-Type: text/plain; charset=ISO-8859-9; format=flowed
Content-Transfer-Encoding: 7bit
---------------0BCB4D94223158510682CA52847
Content-Type: image/jpeg;
name="mimosa.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline
/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZ
lo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl
+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAAR
CAEQAV8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
.
.
.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote:
> The problem is the mail client program, specifically
> Thunderbird. There must be a bug in T-bird that is tickled
> by these non-text characters because although the Subject
> line exists with ***SPAM*** in it if I look at the actual
> message in the mailbox with an editor, T-bird displays
> the subject line as a BLANK subject.
As you said, this appears to be a thunderbird issue. Went there to
report it?
> Now, why don't I just write a rule in T-bird that trashes mail
> that has a blank subject line, I hear you ask?
Err, nope. :) Note that the Subject actually is NOT empty, as you said.
And unless filtering in TB on (raw or decoded) headers is affected by
the very same bug /displaying/ the Subject header in a specific widget
is... Very unlikely. What's invisible to the eye in the UI seriously
isn't invisible to code logic.
This appears to be a client *rendering*, displaying bug. Not to be
confused with an actual empty header (which isn't the same as a missing
header either) to filter on.
Even though this most likely is a TB bug, it would be interesting to
have a look at these headers. If possible, the raw one, prior to your SA
header munging, err, rewriting option.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-09 at 13:50 -0800, Ted Mittelstaedt wrote:
> > > Thunderbird. There must be a bug in T-bird that is tickled
> >
> > Submit a bug report against thunderbird.
>
> I don't want to have to play wack-a-mole with every mail
> client out there.
TB doesn't display the Subject header. It is a TB bug, weather you like
it or not.
> I can just imagine that bug report anyway:
>
> Dear t-bird maintainers:
>
> I am getting spams that have non-ASCII characters in the
> subject line and t-bird is displaying the entire subject line
> as a blank line. I really want to see what my spammer friends
> are putting in their subject lines, so could you please fix
> t-bird so that it displays the bogus characters that my spammer
> friends are putting in their spams to me?
This bug report is insufficient and NEEDINFO. ;) Seriously, this needs
an attachment at the very least with the headers.
And again, as I mentioned in a previous post -- yes, seeing these
headers would be nice. For this audience, too. Yes, that even enables
some of us to check other MUAs. So, well, you wouldn't need to report it
for those...
> I'd stand a better chance of that bug being fixed if I
> DIDN'T report it!!!
Now there's OSS involvement speaking. Sorry, Ted.
If you or someone else don't report it, it won't be fixed. Period.
Unless it accidentally gets fixed by an unrelated code change nearby.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-09 at 14:31 -0800, jdow wrote:
> From: "Ted Mittelstaedt" <te...@ipinc.net>
> Sent: Tuesday, 2010/February/09 13:50
>
>
> > Darxus@ChaosReigns.com wrote:
> >> On 02/09, Ted Mittelstaedt wrote:
> >>> Thunderbird. There must be a bug in T-bird that is tickled
> >>
> >> Submit a bug report against thunderbird.
> >>
> >
> > I don't want to have to play wack-a-mole with every mail
> > client out there.
> >
> > I can just imagine that bug report anyway:
> >
> > Dear t-bird maintainers:
> >
> > I am getting spams that have non-ASCII characters in the
> > subject line and t-bird is displaying the entire subject line
> > as a blank line. I really want to see what my spammer friends
> > are putting in their subject lines, so could you please fix
> > t-bird so that it displays the bogus characters that my spammer
> > friends are putting in their spams to me?
> >
> > I'd stand a better chance of that bug being fixed if I
> > DIDN'T report it!!!
> >
> > Ted
>
> Ted, you cannot expect any more help from them than you give to
> expired accounts, you know. You MUST give them some data to work
> with. Figure out what those characters are. I am betting it would
> be a simple "cr/lf" pair or maybe even a simple "lf". But without
> good knowledge of what it is how can the T'bird people fix it?
> "Insufficient data" is as good a reason as "insufficient account."
>
Agreed. Have you looked at their bug tracker to see it its a known
problem? If it is, adding a 'me too' comment should raise its urgency.
If there's no matching bug report, howinhell can you expect them to know
there's something that needs fixing?
If their bug tracker accepts attachments, attach the whole message.
Otherwise, stuff the Subkect: line through 'od' and send them the
output.
Re wack_a_mole: I think you'll find the major MUAs have already woken
up: non-ASCII doesn't disturb Evolution, the only MUA I use. Besides, I
have the distinct impression that FireFox occupies most of Mozilla's
attention and TB is definitely sucking on the hind teat.
Martin
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: "Ted Mittelstaedt" <te...@ipinc.net>
Sent: Tuesday, 2010/February/09 13:50
> Darxus@ChaosReigns.com wrote:
>> On 02/09, Ted Mittelstaedt wrote:
>>> Thunderbird. There must be a bug in T-bird that is tickled
>>
>> Submit a bug report against thunderbird.
>>
>
> I don't want to have to play wack-a-mole with every mail
> client out there.
>
> I can just imagine that bug report anyway:
>
> Dear t-bird maintainers:
>
> I am getting spams that have non-ASCII characters in the
> subject line and t-bird is displaying the entire subject line
> as a blank line. I really want to see what my spammer friends
> are putting in their subject lines, so could you please fix
> t-bird so that it displays the bogus characters that my spammer
> friends are putting in their spams to me?
>
> I'd stand a better chance of that bug being fixed if I
> DIDN'T report it!!!
>
> Ted
Ted, you cannot expect any more help from them than you give to
expired accounts, you know. You MUST give them some data to work
with. Figure out what those characters are. I am betting it would
be a simple "cr/lf" pair or maybe even a simple "lf". But without
good knowledge of what it is how can the T'bird people fix it?
"Insufficient data" is as good a reason as "insufficient account."
{^_-}
Re: Newest spammer trick - non-blank subject lines?
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 09 February 2010, Ted Mittelstaedt wrote:
>Darxus@ChaosReigns.com wrote:
>> On 02/09, Ted Mittelstaedt wrote:
>>> Thunderbird. There must be a bug in T-bird that is tickled
>>
>> Submit a bug report against thunderbird.
>
>I don't want to have to play wack-a-mole with every mail
>client out there.
>
>I can just imagine that bug report anyway:
>
>Dear t-bird maintainers:
>
> I am getting spams that have non-ASCII characters in the
>subject line and t-bird is displaying the entire subject line
>as a blank line. I really want to see what my spammer friends
>are putting in their subject lines, so could you please fix
>t-bird so that it displays the bogus characters that my spammer
>friends are putting in their spams to me?
>
> I'd stand a better chance of that bug being fixed if I
>DIDN'T report it!!!
>
>Ted
>
One thing I've noted Ted, is that if I have all the fonts for most of the
worlds languages installed, some of that stuff then becomes visible. That of
course doesn't mean I can read it, but all those pictograms from the oriental
languages are sorta purtty. ;-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Don't go around saying the world owes you a living. The world owes you
nothing. It was here first.
-- Mark Twain
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Darxus@ChaosReigns.com wrote:
> On 02/09, Ted Mittelstaedt wrote:
>> Thunderbird. There must be a bug in T-bird that is tickled
>
> Submit a bug report against thunderbird.
>
I don't want to have to play wack-a-mole with every mail
client out there.
I can just imagine that bug report anyway:
Dear t-bird maintainers:
I am getting spams that have non-ASCII characters in the
subject line and t-bird is displaying the entire subject line
as a blank line. I really want to see what my spammer friends
are putting in their subject lines, so could you please fix
t-bird so that it displays the bogus characters that my spammer
friends are putting in their spams to me?
I'd stand a better chance of that bug being fixed if I
DIDN'T report it!!!
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by te...@cnysupport.com.
Quoting jdow <jd...@earthlink.net>:
> From: <Da...@ChaosReigns.com>
> Sent: Tuesday, 2010/February/09 13:35
>
>
>> On 02/09, Ted Mittelstaedt wrote:
>>> Thunderbird. There must be a bug in T-bird that is tickled
>>
>> Submit a bug report against thunderbird.
>
> I seem to remember "way back when" that a cr/lf pair in the subject
> line could result in strange things being displayed in the Outlook
> Express subject line. If T'bird scrolls the subject in that case
> you'd get the effect he's talking about.
I'm guessing that it's nothing more interesting than a bunch of
backspaces. If so, it's a *really* old trick.
Terry
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: <Da...@ChaosReigns.com>
Sent: Tuesday, 2010/February/09 13:35
> On 02/09, Ted Mittelstaedt wrote:
>> Thunderbird. There must be a bug in T-bird that is tickled
>
> Submit a bug report against thunderbird.
I seem to remember "way back when" that a cr/lf pair in the subject
line could result in strange things being displayed in the Outlook
Express subject line. If T'bird scrolls the subject in that case
you'd get the effect he's talking about.
{^_^}
Re: Newest spammer trick - non-blank subject lines?
Posted by Da...@ChaosReigns.com.
On 02/09, Ted Mittelstaedt wrote:
> Thunderbird. There must be a bug in T-bird that is tickled
Submit a bug report against thunderbird.
--
"Dance, dance, wherever you may be" - Lord of the Dance
http://www.ChaosReigns.com
Re: Newest spammer trick - non-blank subject lines?
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 09 February 2010, Ted Mittelstaedt wrote:
>Gene Heskett wrote:
>>
>> Put a valid subject line required into your TOS, mail it to everybody, &
>> then do it a day later, bounce it at them if no subject line content.
>> They will either jump ship in which case offer to hold the door, or come
>> around and do it right in a day or so.
>
>I have doubts that the offenders can even read at all, let alone
>read a TOS or even know what it is. We have customers
>who call in for tech support and when I tell them to open their
>web browser they don't know what I'm talking about. I swear to
>God this is true, I'm not making a joke!
Tell them you aren't really running a school, but there may be computer
classes at the senior center, where they make fairly valiant efforts to teach
old farts in my age category how to use that spanking new winders box they
just bought at Wallies cuz their kids told them to. I think there is an
enrollment fee involved for those classes though.
>I got a call the other day from a customer who is a dialup
>customer who was planning on buying one of those Atom-based
>half-a-laptop netbooks and wanted to know how to put a modem on it -
>and she was NOT planning on doing this because she was
>traveling - she was planning on keeping her dialup as
>her main Internet connection at home!! (don't even ask
>what she is currently using, just imagine)
And old 56k Zoom maybe? They were pretty good modems in their day. I keep
one around just in case.
>We've got calls in the past from customers who disconnected
>service from us (went to some other DSL provider than us)
>and wanted to know why their e-mail stopped working (and
>expected us to fix it!)
Most ISP's will fwd it to the new address, usually for 30 days while they
sort that basket of rattlesnakes.
Chuckle. Yup, I think I have one such in the neighborhood. Asked me a
question about winderz a year or so back, with obviously no ability to grok
the language, and about which I know just enough to reach for a linux dvd and
fix it. I said, sorry, I don't even know how to turn a windows machine on.
They probably think I must be some sort of a twit/arse, but hell, they
thought that before they asked for free help. We had already tangled a
couple of times because their cats would starve if we didn't feed ours 4x
what she can eat a day, 3 or 4 times a day! Gets old, & then a scrap between
our fixed pussy, and a froggy tom cost us $200 for stitches & antibiotics 6
weeks back. I have some traps, but apparently that one has seen the
patterns, I've caught quite a few cats, but not the troublemaker. But then I
am not much of a cat lover, having said on several occasions that it was a
shame we had so many cats & so few good recipes... But in this house, I'm a
definite minority. ;(
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Q: Why don't lawyers go to the beach?
A: The cats keep trying to bury them.
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Gene Heskett <ge...@verizon.net>.
On Wednesday 10 February 2010, Per Jessen wrote:
>Gene Heskett wrote:
>>>> A lot of older people still believe that giving the PC the wrong
>>>> command will cause it to explode in a shower of sparks, thanks to
>>>> Hollywood.
>>>
>>>No ageism here please :-) - a lot people will believe all kinds of
>>>things about PCs.
>>>
>>>
>>>/Per Jessen, Zürich
>>
>> That is only because common sense is a limited availability trait, and
>> with more people, there simply is not enough to go around.
>
>+1
Thanks Per. That is an observation based on 75 years of observing. ;-)
>
>/Per Jessen, Zürich
>
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
How should I know if it works? That's what beta testers are for. I
only coded it.
-- Attributed to Linus Torvalds, somewhere in a posting
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
Posted by Per Jessen <pe...@computer.org>.
Gene Heskett wrote:
>>> A lot of older people still believe that giving the PC the wrong
>>> command will cause it to explode in a shower of sparks, thanks to
>>> Hollywood.
>>
>>No ageism here please :-) - a lot people will believe all kinds of
>>things about PCs.
>>
>>
>>/Per Jessen, Zürich
>>
> That is only because common sense is a limited availability trait, and
> with more people, there simply is not enough to go around.
+1
/Per Jessen, Zürich
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Gene Heskett <ge...@verizon.net>.
On Wednesday 10 February 2010, Per Jessen wrote:
>jd wrote:
>> Kurt Buff さんは書きました:
>>> Uh, paranoia is not mitigated by ignorance. Remember the earlier
>>> description of her friend: retired and partially disabled. This
>>> probably means older and not nearly as educated as we are about
>>> computers, and set in his/her ways. This, augmented by scare stories
>>> in the mass media, probably contribute to the difficulty.
>>
>> A lot of older people still believe that giving the PC the wrong
>> command will cause it to explode in a shower of sparks, thanks to
>> Hollywood.
>
>No ageism here please :-) - a lot people will believe all kinds of
>things about PCs.
>
>
>/Per Jessen, Zürich
>
That is only because common sense is a limited availability trait, and with
more people, there simply is not enough to go around. Like this dirtball, we
haven't made any new dirt, not in big enough quantities to count since that
crater near the yucatan 65 million years ago. Same for common sense.
If you happen to run across some, grab it & hoard it.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Piece of cake!
-- G.S. Koblas
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
Posted by Per Jessen <pe...@computer.org>.
jd wrote:
> Kurt Buff さんは書きました:
>>
>> Uh, paranoia is not mitigated by ignorance. Remember the earlier
>> description of her friend: retired and partially disabled. This
>> probably means older and not nearly as educated as we are about
>> computers, and set in his/her ways. This, augmented by scare stories
>> in the mass media, probably contribute to the difficulty.
>>
>
> A lot of older people still believe that giving the PC the wrong
> command will cause it to explode in a shower of sparks, thanks to
> Hollywood.
No ageism here please :-) - a lot people will believe all kinds of
things about PCs.
/Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
Posted by Martin Gregorie <ma...@gregorie.org>.
On Tue, 2010-02-09 at 17:51 -0800, jdow wrote:
> And for the type of applications he wants his best bet is Windows,
> sadly enough. And, predictably, he's infected. He and I are paranoid
> different ways. I am rather careful about my browsing and my system's
> still clean. I got nailed ONCE so far - that's from being online since
> the 80s. That was during an install. I simply started over with a full
> format. Since then - negativum perspirium. And that is with using IE
> and (mostly) FireFox on my part. Safe browsing is the key.
>
.... also a good anti-virus scanner with a current subscription and
regular updates sitting behind a NAT firewall router with no port
forwarding.
I've been online since '90 and no infections until I stopped using 'doze
in 2002. None since then either.
Martin
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: "Karsten Bräckelmann" <gu...@rudersport.de>
Sent: Tuesday, 2010/February/09 14:40
> On Tue, 2010-02-09 at 14:27 -0800, jdow wrote:
>> I have a thoroughly retired and partially disabled friend I try to
>> help out, such as he'll let me. (I thought I was paranoid until I
>> met him...) I am slowly breaking him of the thought pattern that
>> opening Internet Explorer [...]
>
> Being paranoid. Using IE... *boggle*
>
> Nope, he is definitely not paranoid enough, if he never questioned the
> part about needing IE. Let alone never ever read / heard anything about
> security and main-stream mom-and-pap computer usage.
>
> Come on, IE exploits have been all over the general news in this country
> quite a few times.
Even with FireFox he calls THAT connecting to the Internet.
And for the type of applications he wants his best bet is Windows,
sadly enough. And, predictably, he's infected. He and I are paranoid
different ways. I am rather careful about my browsing and my system's
still clean. I got nailed ONCE so far - that's from being online since
the 80s. That was during an install. I simply started over with a full
format. Since then - negativum perspirium. And that is with using IE
and (mostly) FireFox on my part. Safe browsing is the key.
{^_-}
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Gene Heskett <ge...@verizon.net>.
On Wednesday 10 February 2010, terry@cnysupport.com wrote:
>Quoting jd <on...@garlic.com>:
>> Kurt Buff さんは書きました:
>>> Uh, paranoia is not mitigated by ignorance. Remember the earlier
>>> description of her friend: retired and partially disabled. This
>>> probably means older and not nearly as educated as we are about
>>> computers, and set in his/her ways. This, augmented by scare
>
>stories
>
>>> in the mass media, probably contribute to the difficulty.
>>
>> A lot of older people still believe that giving the PC the wrong
>> command will cause it to explode in a shower of sparks, thanks to
>> Hollywood. It seems that Hollywood is still doing that.
>>
>> I can't count how many times my boss's boss would yell at me when a
>
>PC
>
>> quit working, afraid I'd given it some command that would cause it
>> to explode.
>
>While explosions aren't a big problem, smoke and damage was completely
>possible.
>
>Back in the "olden days" before flat panel displays and smart CRTs, it
>was entirely possible to select a refresh rate or resolution that
>would cause a monitor to smoke and die.
>
>AFAIK, this is not possible with current hardware.
>
>Terry
>
True, but X's paranoia lives on. I have preached before, but perhaps not to
this choir.
If you enjoy a good rant, by someone who has been there and done that, read
on.
The grand and glorious failures generally occurred 20-10 years ago for the
most part. The usual cause was trying to run the monitors at a lower scan
rate than they had transformer iron to handle. Generally speaking this is
very very rarely a vertical sweep problem, for 2 reasons, but first &
foremost, those transformers were iron cored, and because of that had a much
softer saturation failure than the highly tuned ferrite cores used in the
horizontal scan (and high voltage) circuits. There, the sweep currant
amplitude determines the width, but that amplitude delivered to the coils of
the deflection yoke is determined by the rate of rise or fall of the current
in the transformer. The width is now regulated, usually by adjusting the
supply voltage downward at the lower sweep frequencies.
However, the slower sweep rates, because this is a 'velocity' to amplitude
conversion, allows the current in the transformer to rise for a longer period
of time before its turned off & reversed to retrace the beam to the left side
of the CRT. If this current is allowed to rise for long enough, the ferrite
core will become saturated, which is a fancy way of saying the core no longer
has an influence on the circuit inductance, and the effective inductance is
then no more than if the core had been physically removed. The rate of
current rise is then largely un-impeded and can rise many tens of amps per
microsecond, quite high by the time the transistor's drive is removed and it
_tries_ to turn off. Junction temps in the transistor rise until it
explodes, usually blowing bits of epoxy-B off the top. Correspondingly
during this same time frame, the circulating currents cause the supplies
capacitors to overheat, and occasionally those electrolytics will vent, or at
least push the tops up into a definite dome shape.
A similar effect can also be triggered by heat in that ferrite core. Most
ferrite mixes have a quite low 'curie' point, often below 100C! The 'curie'
point is that point in the process of heating an iron alloy, where the iron
loses its magnetic properties. So at temp X, the ferrite disappears from the
magnetic circuit, and like steel, if cooled quickly enough, will not regain
those magnetic properties ever again. Its still steel, or in this case
ferrite, but you cannot pick it up with a magnet. Exhaust valves in lots of
engines have been made from it since WW-II times, its then called Austenitic
(SP?) steel.
All this because somebody replaced an ega rated monitor that could run at
22khz, with a vga rated one that was designed to run at a minimum of 31khz,
and their card could only muster up 28khz. The results were predictable, a
failure, the only question was how long it took. And it was a big enough
problem for the monitor makers that they were quickly fitted with protective
circuitry. So that is not now a problem in terms of being a fire hazard and
has not been for much of a decade now.
Conversely, going the other way, at the top end, the power supply runs out of
headroom, the high voltage gets soft, the pix narrower and probably dimmer,
but generally speaking a 70khz rated monitor will not be damaged by a 90khz
drive. Similarly, a 15khz rated monitor is not damaged, even on a long term
basis, by running it at 19 khz, I have been doing that for many years on what
this group would definitely call a 'legacy computer', a TRS-80 Color Computer
3. It is, when its hooked up, the second, fully independent monitor I can
use.
So, IMNSHO, X is way overdue to lose that paranoia, the monitor folks fixed
that problem nearly a decade ago. They (X) are trying to protect the user
from a situation that no longer exists in 99.999% of the environment.
More trivia, lots more, than you wanted to know I'm sure. ;-)
Joanne could confirm this, but she has more respect for the lists topic, I
think...
Me, I get interested when the topic drifts away in my direction of knowledge.
My apologies in this case would be somewhat less than sincere.
Now, back to your regularly scheduled discussions. Spamassassin I believe it
was. ;)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
One tree to rule them all,
One tree to find them,
One tree to bring them all,
and to itself bind them.
-- Gavin Koch <ga...@cygnus.com>
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Gene Heskett <ge...@verizon.net>.
On Wednesday 10 February 2010, Bowie Bailey wrote:
>jd wrote:
>> A lot of older people still believe that giving the PC the wrong
>> command will cause it to explode in a shower of sparks, thanks to
>> Hollywood. It seems that Hollywood is still doing that.
>
>Electronics generating sparks when overloaded? Yes.
>
>Generating smoke? Yes.
>
>Flames? Yes.
>
>A dynamic explosion? No.
>
>(Never did figure out why all the electronics consoles in movies seem to
>contain explosives...)
Explosion? Most certainly a resounding yes, Bowie. I once had a house in
Nebraska, with a quarter sized dent in the plaster & lathe ceiling about 1/4"
deep over the kitchen table. Poor folks at the time, I had bought an old 6
volt CB radio, and _thought_ I had it converted to 12 volts, and was testing
it. After about 30 minutes powered up on a 12 volt supply, one of the power
supply filters, a 350 volt rated item, decided it had had enough of the 600
volts it was getting, and exploded. The top of the alu can put that dent in
the plastered ceiling, and I had a heck of a time cleaning up all the
exploded antifreeze soaked kraft paper & see through tinfoil they are made
of. The antifreeze of course being 1000's of times purer than what you put
in your cars radiator, but its still ethylene glycol none the less.
Lets just say that I am glad I had no body parts in the way... I realized
that I had missed a connection that needed to be moved to the 12 volt
position, fixed that, and replaced the filter, and it ran just fine in my
hunting truck for as long as I owned it, another 6 or 7 years.
The movie folks of course have their own definition of reality. ;-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein
Re: OT::Making a PC explode (was Re: Newest spammer trick -
non-blank subject lines?)
Posted by te...@cnysupport.com.
Quoting jd <on...@garlic.com>:
> Kurt Buff さんは書きました:
>>
>> Uh, paranoia is not mitigated by ignorance. Remember the earlier
>> description of her friend: retired and partially disabled. This
>> probably means older and not nearly as educated as we are about
>> computers, and set in his/her ways. This, augmented by scare
stories
>> in the mass media, probably contribute to the difficulty.
>>
>
> A lot of older people still believe that giving the PC the wrong
> command will cause it to explode in a shower of sparks, thanks to
> Hollywood. It seems that Hollywood is still doing that.
>
> I can't count how many times my boss's boss would yell at me when a
PC
> quit working, afraid I'd given it some command that would cause it
> to explode.
While explosions aren't a big problem, smoke and damage was completely
possible.
Back in the "olden days" before flat panel displays and smart CRTs, it
was entirely possible to select a refresh rate or resolution that
would cause a monitor to smoke and die.
AFAIK, this is not possible with current hardware.
Terry
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Ted Mittelstaedt <te...@ipinc.net>.
jd wrote:
> Kurt Buff さんは書きました:
>> Uh, paranoia is not mitigated by ignorance. Remember the earlier
>> description of her friend: retired and partially disabled. This
>> probably means older and not nearly as educated as we are about
>> computers, and set in his/her ways. This, augmented by scare stories
>> in the mass media, probably contribute to the difficulty.
>>
>
> A lot of older people still believe that giving the PC the wrong
> command will cause it to explode in a shower of sparks, thanks to
> Hollywood. It seems that Hollywood is still doing that.
>
> I can't count how many times my boss's boss would yell at me when a PC
> quit working, afraid I'd given it some command that would cause it to
> explode.
>
Back in 1995 one day at Central Point Software I was walking by the
server room when I heard a funny noise, I ran in just in time to
see the IBM monitor spew out a huge cloud of greasy stinky smoke. I
held my breath, ran in and unplugged it and carried it out into the
hall. The flyback transformer had melted down. I later found out from
someone else that this was a common occurrence with those IBM monitors.
The monitor was in a rack, right underneath our fiber distribution
panel. That would have been rather messy if it had caught on fire.
Ted
Re: [SPAM:9.6] Re: OT::Making a PC explode (was Re: Newest spammer
trick - non-blank subject lines?)
Posted by Christian Brel <br...@copperproductions.co.uk>.
On Wed, 10 Feb 2010 12:32:06 -0800 (PST)
John Hardin <jh...@impsec.org> wrote:
> On Wed, 10 Feb 2010, Bowie Bailey wrote:
>
> > jd wrote:
> >> A lot of older people still believe that giving the PC the wrong
> >> command will cause it to explode in a shower of sparks, thanks to
> >> Hollywood. It seems that Hollywood is still doing that.
> >
> > Electronics generating sparks when overloaded? Yes.
> >
> > Generating smoke? Yes.
> >
> > Flames? Yes.
>
> http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
>
Wow, forgot about that! Thanks for the memory!
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by John Hardin <jh...@impsec.org>.
On Wed, 10 Feb 2010, Bowie Bailey wrote:
> jd wrote:
>> A lot of older people still believe that giving the PC the wrong
>> command will cause it to explode in a shower of sparks, thanks to
>> Hollywood. It seems that Hollywood is still doing that.
>
> Electronics generating sparks when overloaded? Yes.
>
> Generating smoke? Yes.
>
> Flames? Yes.
http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Rights can only ever be individual, which means that you cannot
gain a right by joining a mob, no matter how shiny the issued
badges are, or how many of your neighbors are part of it. -- Marko
-----------------------------------------------------------------------
2 days until Abraham Lincoln's and Charles Darwin's 201st Birthdays
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Charles Gregory <cg...@hwcn.org>.
On Wed, 10 Feb 2010, Bowie Bailey wrote:
> Electronics generating sparks when overloaded? Yes.
> Generating smoke? Yes.
> Flames? Yes.
> A dynamic explosion? No.
> (Never did figure out why all the electronics consoles in movies seem to
> contain explosives...)
Self-destruct mechanism, obviously! :)
PS. Explosions are not 100% unreal. Ever had a capacitor pop?
Even the small ones can make quite a loud bang.... :)
- Charles
Re: [SPAM:9.6] Re: OT::Making a PC explode (was Re: Newest spammer
trick - non-blank subject lines?)
Posted by Christian Brel <br...@copperproductions.co.uk>.
On Wed, 10 Feb 2010 12:42:46 -0500
Bowie Bailey <Bo...@BUC.com> wrote:
> jd wrote:
> > A lot of older people still believe that giving the PC the wrong
> > command will cause it to explode in a shower of sparks, thanks to
> > Hollywood. It seems that Hollywood is still doing that.
> >
>
> Electronics generating sparks when overloaded? Yes.
>
> Generating smoke? Yes.
>
> Flames? Yes.
>
> A dynamic explosion? No.
>
> (Never did figure out why all the electronics consoles in movies seem
> to contain explosives...)
>
It's a simple mistake - but the repair technician substitutes the 4700uf
smoothing caps with Le Maitre theatrical maroons.... (the very small
ones I hasten to add, the really big ones you put into a car a
disconnected car stereo, wired across the supply cables and leave the
car unlocked :-) If the thief is local, you'll hear the bang....)
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by Bowie Bailey <Bo...@BUC.com>.
jd wrote:
> A lot of older people still believe that giving the PC the wrong
> command will cause it to explode in a shower of sparks, thanks to
> Hollywood. It seems that Hollywood is still doing that.
>
Electronics generating sparks when overloaded? Yes.
Generating smoke? Yes.
Flames? Yes.
A dynamic explosion? No.
(Never did figure out why all the electronics consoles in movies seem to
contain explosives...)
--
Bowie
OT::Making a PC explode (was Re: Newest spammer trick - non-blank
subject lines?)
Posted by jd <on...@garlic.com>.
Kurt Buff さんは書きました:
>
> Uh, paranoia is not mitigated by ignorance. Remember the earlier
> description of her friend: retired and partially disabled. This
> probably means older and not nearly as educated as we are about
> computers, and set in his/her ways. This, augmented by scare stories
> in the mass media, probably contribute to the difficulty.
>
A lot of older people still believe that giving the PC the wrong
command will cause it to explode in a shower of sparks, thanks to
Hollywood. It seems that Hollywood is still doing that.
I can't count how many times my boss's boss would yell at me when a PC
quit working, afraid I'd given it some command that would cause it to
explode.
--
jd
Re: Newest spammer trick - non-blank subject lines?
Posted by Kurt Buff <ku...@gmail.com>.
2010/2/9 Karsten Bräckelmann <gu...@rudersport.de>:
> On Tue, 2010-02-09 at 14:27 -0800, jdow wrote:
>> I have a thoroughly retired and partially disabled friend I try to
>> help out, such as he'll let me. (I thought I was paranoid until I
>> met him...) I am slowly breaking him of the thought pattern that
>> opening Internet Explorer [...]
>
> Being paranoid. Using IE... *boggle*
>
> Nope, he is definitely not paranoid enough, if he never questioned the
> part about needing IE. Let alone never ever read / heard anything about
> security and main-stream mom-and-pap computer usage.
>
> Come on, IE exploits have been all over the general news in this country
> quite a few times.
Uh, paranoia is not mitigated by ignorance. Remember the earlier
description of her friend: retired and partially disabled. This
probably means older and not nearly as educated as we are about
computers, and set in his/her ways. This, augmented by scare stories
in the mass media, probably contribute to the difficulty.
If I had to guess, for this friend of hers, new == deeply suspicious
Kurt
Re: Newest spammer trick - non-blank subject lines?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-02-09 at 14:27 -0800, jdow wrote:
> I have a thoroughly retired and partially disabled friend I try to
> help out, such as he'll let me. (I thought I was paranoid until I
> met him...) I am slowly breaking him of the thought pattern that
> opening Internet Explorer [...]
Being paranoid. Using IE... *boggle*
Nope, he is definitely not paranoid enough, if he never questioned the
part about needing IE. Let alone never ever read / heard anything about
security and main-stream mom-and-pap computer usage.
Come on, IE exploits have been all over the general news in this country
quite a few times.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
Posted by jdow <jd...@earthlink.net>.
From: "Ted Mittelstaedt" <te...@ipinc.net>
Sent: Tuesday, 2010/February/09 13:24
> Gene Heskett wrote:
>> On Tuesday 09 February 2010, Ted Mittelstaedt wrote:
>>> OK All,
>>>
>>> Please let me know if anyone has seen this one before.
>>>
>>> We have SA configured to insert "*****SPAM***** in the
>>> beginning of the subject lines of spams before sending them on to
>>> customers, then mail the message as an attachment to the user
>>> along with the SA report as to why it's spam.
>>>
>>> Lately I've seen a new trick the spammers are using.
>>>
>>> They are putting characters in the subject line that
>>> are not text characters - I don't know what they are,
>>> I haven't looked into this closely yet. Our SA installation
>>> is correctly tagging this as spam and sending it forward
>>> to the user.
>>>
>>> The problem is the mail client program, specifically
>>> Thunderbird. There must be a bug in T-bird that is tickled
>>> by these non-text characters because although the Subject
>>> line exists with ***SPAM*** in it if I look at the actual
>>> message in the mailbox with an editor, T-bird displays
>>> the subject line as a BLANK subject. Of course, since the
>>> Subject is blank then you don't see that it is SPAM and
>>> you have to go to the bother of opening it before you see
>>> the SA report that it's spam.
>>>
>>> This has only happened to a few spams so far, and I want
>>> to nip it in the bud.
>>>
>>> Now, why don't I just write a rule in T-bird that trashes mail
>>> that has a blank subject line, I hear you ask?
>>>
>>> It's because we have a few moronic customers who seem to
>>> think it's OK to send out e-mails with blank subject lines!!
>>
>> Put a valid subject line required into your TOS, mail it to everybody, &
>> then do it a day later, bounce it at them if no subject line content.
>> They will either jump ship in which case offer to hold the door, or come
>> around and do >> it right in a day or so.
>>
>
> I have doubts that the offenders can even read at all, let alone
> read a TOS or even know what it is. We have customers
> who call in for tech support and when I tell them to open their
> web browser they don't know what I'm talking about. I swear to
> God this is true, I'm not making a joke!
I have a thoroughly retired and partially disabled friend I try to
help out, such as he'll let me. (I thought I was paranoid until I
met him...) I am slowly breaking him of the thought pattern that
opening Internet Explorer connected him to the Internet. He WAS at
one time on dial-up where this might have be true. He's on DSL now.
So he's always connected. He still talks about connecting when he
means opening the browser.
> I got a call the other day from a customer who is a dialup
> customer who was planning on buying one of those Atom-based
> half-a-laptop netbooks and wanted to know how to put a modem on it -
> and she was NOT planning on doing this because she was
> traveling - she was planning on keeping her dialup as
> her main Internet connection at home!! (don't even ask
> what she is currently using, just imagine)
Two tin cans and a string? {^_-}
> We've got calls in the past from customers who disconnected
> service from us (went to some other DSL provider than us)
> and wanted to know why their e-mail stopped working (and
> expected us to fix it!)
Ah yes, and they won't take, "It is not a free service we offer
to everybody, " for an answer, will they? Perhaps offer then a
one month period for forwarding email to their new address once
they can provide it - for say $10.00 or something like that. It
would give them time to inform all their correspondents of their
new email address. After the first month allow them to continue
it for a full "email only" account rate.
{^_-}
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Gene Heskett wrote:
> On Tuesday 09 February 2010, Ted Mittelstaedt wrote:
>> OK All,
>>
>> Please let me know if anyone has seen this one before.
>>
>> We have SA configured to insert "*****SPAM***** in the
>> beginning of the subject lines of spams before sending them on to
>> customers, then mail the message as an attachment to the user
>> along with the SA report as to why it's spam.
>>
>> Lately I've seen a new trick the spammers are using.
>>
>> They are putting characters in the subject line that
>> are not text characters - I don't know what they are,
>> I haven't looked into this closely yet. Our SA installation
>> is correctly tagging this as spam and sending it forward
>> to the user.
>>
>> The problem is the mail client program, specifically
>> Thunderbird. There must be a bug in T-bird that is tickled
>> by these non-text characters because although the Subject
>> line exists with ***SPAM*** in it if I look at the actual
>> message in the mailbox with an editor, T-bird displays
>> the subject line as a BLANK subject. Of course, since the
>> Subject is blank then you don't see that it is SPAM and
>> you have to go to the bother of opening it before you see
>> the SA report that it's spam.
>>
>> This has only happened to a few spams so far, and I want
>> to nip it in the bud.
>>
>> Now, why don't I just write a rule in T-bird that trashes mail
>> that has a blank subject line, I hear you ask?
>>
>> It's because we have a few moronic customers who seem to
>> think it's OK to send out e-mails with blank subject lines!!
>
> Put a valid subject line required into your TOS, mail it to everybody, & then
> do it a day later, bounce it at them if no subject line content. They will
> either jump ship in which case offer to hold the door, or come around and do
> it right in a day or so.
>
I have doubts that the offenders can even read at all, let alone
read a TOS or even know what it is. We have customers
who call in for tech support and when I tell them to open their
web browser they don't know what I'm talking about. I swear to
God this is true, I'm not making a joke!
I got a call the other day from a customer who is a dialup
customer who was planning on buying one of those Atom-based
half-a-laptop netbooks and wanted to know how to put a modem on it -
and she was NOT planning on doing this because she was
traveling - she was planning on keeping her dialup as
her main Internet connection at home!! (don't even ask
what she is currently using, just imagine)
We've got calls in the past from customers who disconnected
service from us (went to some other DSL provider than us)
and wanted to know why their e-mail stopped working (and
expected us to fix it!)
Ted
>> It would be most useful if when SA was creating the subject
>> lines of the e-mails with the spams attached, that instead of
>> just blindly copying over the Subject line from the spam and
>> inserting the *****SPAM***** in front of the subject, that
>> SA stripped out all the non-text characters in the Subject
>> line.
>>
>> Any suggestions appreciated! (even the smart-ass ones but
>> they have to be clever)
>>
>> Thanks!
>> Ted
>>
>
>
Re: Newest spammer trick - non-blank subject lines?
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 09 February 2010, Ted Mittelstaedt wrote:
>OK All,
>
> Please let me know if anyone has seen this one before.
>
> We have SA configured to insert "*****SPAM***** in the
>beginning of the subject lines of spams before sending them on to
>customers, then mail the message as an attachment to the user
>along with the SA report as to why it's spam.
>
> Lately I've seen a new trick the spammers are using.
>
> They are putting characters in the subject line that
>are not text characters - I don't know what they are,
>I haven't looked into this closely yet. Our SA installation
>is correctly tagging this as spam and sending it forward
>to the user.
>
> The problem is the mail client program, specifically
>Thunderbird. There must be a bug in T-bird that is tickled
>by these non-text characters because although the Subject
>line exists with ***SPAM*** in it if I look at the actual
>message in the mailbox with an editor, T-bird displays
>the subject line as a BLANK subject. Of course, since the
>Subject is blank then you don't see that it is SPAM and
>you have to go to the bother of opening it before you see
>the SA report that it's spam.
>
> This has only happened to a few spams so far, and I want
>to nip it in the bud.
>
> Now, why don't I just write a rule in T-bird that trashes mail
>that has a blank subject line, I hear you ask?
>
> It's because we have a few moronic customers who seem to
>think it's OK to send out e-mails with blank subject lines!!
Put a valid subject line required into your TOS, mail it to everybody, & then
do it a day later, bounce it at them if no subject line content. They will
either jump ship in which case offer to hold the door, or come around and do
it right in a day or so.
> It would be most useful if when SA was creating the subject
>lines of the e-mails with the spams attached, that instead of
>just blindly copying over the Subject line from the spam and
>inserting the *****SPAM***** in front of the subject, that
>SA stripped out all the non-text characters in the Subject
>line.
>
> Any suggestions appreciated! (even the smart-ass ones but
>they have to be clever)
>
>Thanks!
>Ted
>
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Hurd and architecture in one sentence? Uh-oh...
- Al Viro on linux-kernel
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 16:23, David Morton wrote:
>> On this system, not much. On the scale of about 6,000 messages a day.
>
> Very light duty then. :)
>
>> Even if SpamAssassin isn't used during SMTP, there's nothing stopping
>> somebody who wants to DOS you from just setting their DOS tool to hold
>> open connections and spend lots of time waiting between issuing SMTP
>> commands... It could even go straight through to the DATA phase and send
>> a 10MB email at a speed of 1 byte per second.
>
> True, though most MTA's have some defenses built for this, but waiting
> to scan for spam by nature takes time, and so these defenses must be
> lowered to allow it.
>
>> I don't think moving SpamAssassin to after the SMTP transaction has
>> finished would help prevent someone from performing a DOS.
>>
>> If you *can* do SMTP time spam scanning, then that's the best place for it.
>
> - From experience with larger ISP settings, and some large enterprise
> settings, it doesn't take a malicious attempt - normal traffic can be
> bursty and bring a system to its knees. From a practical standpoint,
> it's just a whole lot easier to have the front line smtpd servers
> swallow the email as fast as possible (some quick rbl or greylisting
> aside) and then you can process in batches behind the lines.
>
> It's scary when email starts piling up faster than all your scanners can
> chew... but most admins I've met would prefer that to other mail servers
> getting connection errors and possible bouncing or sending problem
> reports back to the sender.
I must admit, I have seen this several times before. Looking at the logs
on our servers at work we've rejected on average 151 emails per minute
for the past week. We do SpamAssassin scanning during SMTP here as well
and the vast majority of the time it's fine, but it does cause problems
during spikes.
To me this just says that we don't have enough servers to deal with the
spikes, but it happens infrequently enough that it's not worth
investing. I still think SMTP time scanning is both practical and desirable.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by David Morton <mo...@dgrmm.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Cardwell wrote:
> On this system, not much. On the scale of about 6,000 messages a day.
Very light duty then. :)
> Even if SpamAssassin isn't used during SMTP, there's nothing stopping
> somebody who wants to DOS you from just setting their DOS tool to hold
> open connections and spend lots of time waiting between issuing SMTP
> commands... It could even go straight through to the DATA phase and send
> a 10MB email at a speed of 1 byte per second.
True, though most MTA's have some defenses built for this, but waiting
to scan for spam by nature takes time, and so these defenses must be
lowered to allow it.
> I don't think moving SpamAssassin to after the SMTP transaction has
> finished would help prevent someone from performing a DOS.
>
> If you *can* do SMTP time spam scanning, then that's the best place for it.
- From experience with larger ISP settings, and some large enterprise
settings, it doesn't take a malicious attempt - normal traffic can be
bursty and bring a system to its knees. From a practical standpoint,
it's just a whole lot easier to have the front line smtpd servers
swallow the email as fast as possible (some quick rbl or greylisting
aside) and then you can process in batches behind the lines.
It's scary when email starts piling up faster than all your scanners can
chew... but most admins I've met would prefer that to other mail servers
getting connection errors and possible bouncing or sending problem
reports back to the sender.
- --
David Morton <mo...@dgrmm.net>
Morton Software & Design http://www.dgrmm.net - Ruby on Rails
PHP Applications
Maia Mailguard http://www.maiamailguard.com - Spam management
for mail servers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLdC8CUy30ODPkzl0RAlSnAJ4tjvtTkZnfTSt3xyDMsMx/A0565wCfb1GT
qgz12JDzpApjgoLmcN208e8=
=XivG
-----END PGP SIGNATURE-----
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 15:49, David Morton wrote:
>> At SMTP time I return a 5xx code during the "DATA" phase for messages
>> classified as Spam. However, I also deliver the message into a read only
>
> What kind of mail load do you service?
On this system, not much. On the scale of about 6,000 messages a day.
> It takes a significant amount of
> time for spamassassin to process a message, and holding the connection
> open during that time can easily allow for a DoS by flooding your mail
> server with connections. This is why amavisd* variants always accept
> the mail and then process - it helps keep the incoming smtpd process
> from jamming.
SpamAssassin seems to average about 5 seconds per message here. I have
other light weight checks which take place before spamassassin as well.
Even if SpamAssassin isn't used during SMTP, there's nothing stopping
somebody who wants to DOS you from just setting their DOS tool to hold
open connections and spend lots of time waiting between issuing SMTP
commands... It could even go straight through to the DATA phase and send
a 10MB email at a speed of 1 byte per second.
I don't think moving SpamAssassin to after the SMTP transaction has
finished would help prevent someone from performing a DOS.
If you *can* do SMTP time spam scanning, then that's the best place for it.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Henrik K <he...@hege.li>.
On Thu, Feb 11, 2010 at 09:49:32AM -0600, David Morton wrote:
>
> This is why amavisd* variants always accept the mail and then process
You are wrong: amavisd-milter works fine here.
Pre-queue filtering is generally well understood with it's pros and cons, no
point taking it up here.
Re: Newest spammer trick - non-blank subject lines?
Posted by David Morton <mo...@dgrmm.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Cardwell wrote:
> At SMTP time I return a 5xx code during the "DATA" phase for messages
> classified as Spam. However, I also deliver the message into a read only
What kind of mail load do you service? It takes a significant amount of
time for spamassassin to process a message, and holding the connection
open during that time can easily allow for a DoS by flooding your mail
server with connections. This is why amavisd* variants always accept
the mail and then process - it helps keep the incoming smtpd process
from jamming.
- --
David Morton <mo...@dgrmm.net>
Morton Software & Design http://www.dgrmm.net - Ruby on Rails
PHP Applications
Maia Mailguard http://www.maiamailguard.com - Spam management
for mail servers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLdCcMUy30ODPkzl0RAvn8AKDGCHegd5F+GxMT0+6yTWBV0qtDZQCeMMXg
oLBV5aIBYMqx9wH5VACx57s=
=/4HM
-----END PGP SIGNATURE-----
Re: Newest spammer trick - non-blank subject lines?
Posted by Matt Garretson <ma...@assembly.state.ny.us>.
On 2/11/2010 8:08 AM, Per Jessen wrote:
> The only minor issue I see is that a lot
> of people don't understand NDRs (or can't be bothered to try to).
True. Also, a lot of mail relays mangle NDR's beyond usability.
Re: Newest spammer trick - non-blank subject lines?
Posted by Per Jessen <pe...@computer.org>.
RW wrote:
>> >
>> > Bob could also have just clicked the link in the NDR.
>> Some people - e.g. /me - do not try to pass Turing tests. Obviously
>> you are not interested in my mails anyway ....
>
> But it's only applied to mail classified as spam, and unlike CR it
> generates no additional backscatter.
>
>> Apart from that why should I decode captchas from some random site?
>> After all, they could come from a third site so that people solve
>> them to the the other can log automatically into the third one ...
>
> Because the NDR is generated by *your* mail server in response to
> *your* email.
>
> I think it's rather a good idea.
I agree, it's not bad at all. The only minor issue I see is that a lot
of people don't understand NDRs (or can't be bothered to try to).
/Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
Posted by RW <rw...@googlemail.com>.
On Thu, 11 Feb 2010 12:26:03 +0100
Bernd Petrovitsch <be...@petrovitsch.priv.at> wrote:
> On Don, 2010-02-11 at 10:38 +0000, Mike Cardwell wrote:
> > On 11/02/2010 08:27, LuKreme wrote:
> > >> At SMTP time I return a 5xx code during the "DATA" phase for
> > >> messages classified as Spam. However, I also deliver the message
> > >> into a read only "Junk E-Mail" folder for the user,
> > >
> > > This is just wrong. Either accept the message, or reject the
> > message. Rejecting the message while secretly accepting it is just
> > completely wrong.
> [...]
> > > Let's say your filter catches a legitimate message to
> > user@yourdomain.tld from bob@mydomain.tld. Bob gets an erro saying
> > the message was spammy and didn't go through, so he goes to his
> > gmail account and sends it again, hoping for better results. This
> > time it goes through.
> >
> > Bob could also have just clicked the link in the NDR.
> Some people - e.g. /me - do not try to pass Turing tests. Obviously
> you are not interested in my mails anyway ....
But it's only applied to mail classified as spam, and unlike CR it
generates no additional backscatter.
> Apart from that why should I decode captchas from some random site?
> After all, they could come from a third site so that people solve them
> to the the other can log automatically into the third one ...
Because the NDR is generated by *your* mail server in response to
*your* email.
I think it's rather a good idea.
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 19:52, Bernd Petrovitsch wrote:
>> I want you to describe a scenario where the sender or recipient are
>> actually worse off because of the particular two features I've
> The point is: The sender is worse off because he needs to invest time
> for the workaround which is caused by the receiver. The receiver is
> worse off because some senders plain simply give up when they are
> expected to pass a Turing test.
> No, I don't have numbers. But I'm pretty sure I'm not the only one.
>
>> described. You've failed to even attempt that so far.
> You see only two alternatives:
> - keep these two features (and tell the senders that they should
> actually be happy that they can invest time and effort to work around
> FPs caused by the receiver spam).
> - or deactivate it.
> I proposed the 3rd solution:
> - repair your spam-detection (change weight/limits, use Bayes,
> greylistung, etc.) to not generate so many FPs that you actually need
> an additional workaround.
> That would actually remove the cause and not fiddle with the symptoms.
>
>> I know this system works well because I've been using it for a long time.
> To use your own words: Ridiculous. Just because someone uses something
> for a long time doesn't make it good (or is even an indication for it).
> Apart from that: You very probably don't know how many FPs didn't come
> through because of people disliking Turing tests.
Your assuming that my false positive rate is bad. I would be surprised
if it was worse than the average on this list. It's very good. But if my
additions knock 0.1% more off the rate, then I'm happy. Out.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by LuKreme <kr...@kreme.com>.
On 11-Feb-2010, at 15:42, Kris Deugau wrote:
>
> Hmm. I'd say the balance is slightly in favour of Mike's system - you CAN NOT *prevent* all false-positives, so providing some way to let senders know relatively quickly that their mail got caught seems to me to be a positive.
An NDN means that a message was NOT DELIVERED. The natural thing to do when you get an NDN is to double check the address you sent to and if that is right then decide if it's worth trying to get the message through. If it is, you either re-craft the message, or you send it from another source. Or your forget about it and consider the message undelivered. To then have a undelivered message turn out to have been successfully delivered simply tells me that that person's mailserver is unreliable.
This means that Mike's method is likely to create duplicate messages, and is guaranteed to create confusion about whether a specific message was delivered. Imagine these messages being generated by a mailing list.
Never having seen one of the NDNs from Mike's system, I can't say exactly what they look like, but since I deal with severely malformed and suspicious NDNs every single day, it is very unlikely that I would look at any URL inside a NDN, much less even consider clicking on it.
--
NO ONE CARES WHAT MY DEFINITION OF "IS" IS
Bart chalkboard Ep. AABF02
Re: Newest spammer trick - non-blank subject lines?
Posted by Bernd Petrovitsch <be...@petrovitsch.priv.at>.
On Don, 2010-02-11 at 17:42 -0500, Kris Deugau wrote:
> Bernd Petrovitsch wrote:
[...]
> > I proposed the 3rd solution:
> > - repair your spam-detection (change weight/limits, use Bayes,
> > greylistung, etc.) to not generate so many FPs that you actually need
> > an additional workaround.
> > That would actually remove the cause and not fiddle with the symptoms.
>
> :/ Until you have a business customer whose one FP for the year was
> moderately time-sensitive, and which missing out on in time cost them a
> juicy contract.... and guess who they're upset at for spam-tagging that
> one message, never mind how much junk the filter has kept out of their
> inbox?
I was more in "private" area - and the commercial. AFAICT almost every
company I know of plain simply *never* rejects email just because some
tool may think it's got too many spam points.
So for them this is a non-issue anyways.
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
Posted by Kris Deugau <kd...@vianet.ca>.
Bernd Petrovitsch wrote:
> On Don, 2010-02-11 at 18:26 +0000, Mike Cardwell wrote:
> [...]
>> I want you to describe a scenario where the sender or recipient are
>> actually worse off because of the particular two features I've
> The point is: The sender is worse off because he needs to invest time
> for the workaround which is caused by the receiver. The receiver is
> worse off because some senders plain simply give up when they are
> expected to pass a Turing test.
> No, I don't have numbers. But I'm pretty sure I'm not the only one.
Hmm. I'd say the balance is slightly in favour of Mike's system - you
CAN NOT *prevent* all false-positives, so providing some way to let
senders know relatively quickly that their mail got caught seems to me
to be a positive.
Some FPs are due to the sender's attempt to avoid some other
differently-broken mail system elsewhere - I got an interesting call
back from someone I notified about a webform generating mail missing a
Message-Id header. (I've found it to be a pretty good spamsign here to
see a Message-Id generated by one of our MXes.) Apparently, they used
to generate one... and somewhere along the line their colo/hosting
host's outbound relays started rejecting these messages based on that
Message-Id.
> I proposed the 3rd solution:
> - repair your spam-detection (change weight/limits, use Bayes,
> greylistung, etc.) to not generate so many FPs that you actually need
> an additional workaround.
> That would actually remove the cause and not fiddle with the symptoms.
:/ Until you have a business customer whose one FP for the year was
moderately time-sensitive, and which missing out on in time cost them a
juicy contract.... and guess who they're upset at for spam-tagging that
one message, never mind how much junk the filter has kept out of their
inbox?
-kgd
Re: Newest spammer trick - non-blank subject lines?
Posted by Bernd Petrovitsch <be...@petrovitsch.priv.at>.
On Don, 2010-02-11 at 18:26 +0000, Mike Cardwell wrote:
[...]
> I want you to describe a scenario where the sender or recipient are
> actually worse off because of the particular two features I've
The point is: The sender is worse off because he needs to invest time
for the workaround which is caused by the receiver. The receiver is
worse off because some senders plain simply give up when they are
expected to pass a Turing test.
No, I don't have numbers. But I'm pretty sure I'm not the only one.
> described. You've failed to even attempt that so far.
You see only two alternatives:
- keep these two features (and tell the senders that they should
actually be happy that they can invest time and effort to work around
FPs caused by the receiver spam).
- or deactivate it.
I proposed the 3rd solution:
- repair your spam-detection (change weight/limits, use Bayes,
greylistung, etc.) to not generate so many FPs that you actually need
an additional workaround.
That would actually remove the cause and not fiddle with the symptoms.
> I know this system works well because I've been using it for a long time.
To use your own words: Ridiculous. Just because someone uses something
for a long time doesn't make it good (or is even an indication for it).
Apart from that: You very probably don't know how many FPs didn't come
through because of people disliking Turing tests.
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
Posted by Mark Martinec <Ma...@ijs.si>.
On Friday February 12 2010 00:28:24 David Morton wrote:
> Of course you 5xx reject unknown users and other low hanging fruit
> that identifes bad stuff - but then the rest is accepted to process
> later. This is exactly how most amavisd variants work.
Btw, with the most recent advances in SpamAssassin 3.3.0 (master_deadline
time limiting), in Postfix (smtpd_proxy_options=speed_adjust), and in
the coming amavisd-new release (warm restart, reworked time limiting),
amavisd will behave much better in a pre-queue (proxy) setup when
combined with Postfix and SA 3.3.0. This gives admin more choice
to choose between a pre-queue and post-queue setups.
Mark
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
David Morton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ted Mittelstaedt wrote:
>
>> The claim that amavisd* variants accept then process mail
>> is nonsense, nobody who runs a large mailserver with amavisd could
>> possibly have their server configured in this manner without it melting
>> down, so please no more of this ridiculous talk.
>
> ?? Of course you 5xx reject unknown users and other low hanging fruit
> that identifes bad stuff - but then the rest is accepted to process
> later. This is exactly how most amavisd variants work.
>
Yes, and this is exactly how everything else works, too. So what? That
is not what the poster stated when he claimed that amavisd* queued
everything.
As I said, please no more of this rediculous talk.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by David Morton <mo...@dgrmm.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ted Mittelstaedt wrote:
> The claim that amavisd* variants accept then process mail
> is nonsense, nobody who runs a large mailserver with amavisd could
> possibly have their server configured in this manner without it melting
> down, so please no more of this ridiculous talk.
?? Of course you 5xx reject unknown users and other low hanging fruit
that identifes bad stuff - but then the rest is accepted to process
later. This is exactly how most amavisd variants work.
- --
David Morton <mo...@dgrmm.net>
Morton Software & Design http://www.dgrmm.net - Ruby on Rails
PHP Applications
Maia Mailguard http://www.maiamailguard.com - Spam management
for mail servers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLdJKYUy30ODPkzl0RArlNAJ9ccE6wA/XcAlmUkSr4X0AXgVaT1ACfbZpr
GyD+ExM0KUAEq8jPhAfCEE4=
=jbCy
-----END PGP SIGNATURE-----
Re: Newest spammer trick - non-blank subject lines?
Posted by RW <rw...@googlemail.com>.
On Thu, 11 Feb 2010 16:40:04 -0800
Ted Mittelstaedt <te...@ipinc.net> wrote:
> case - but I sure as hell would never be foolish enough to try and
> defend it. These hacks simply scream "I got mine and I don't give
> a damn if you got yours",
Isn't that really your position - that 5xx responses make the botnet
move on to someone else. You also seem to arguing that his idea is bad
because it make a botnet less efficient at delivering spam.
Your argument that it doesn't scale can be applied equally well
to rejecting spam per se. Even if spammers do lay-off addresses where
spam filters reject at the smtp level, they can't afford to do that
if it's ubiquitous.
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mike Cardwell wrote:
> On 11/02/2010 19:29, Ted Mittelstaedt wrote:
>
>
> All I can see above is a long list of dubious predictions of what
> spammers would do if everybody used the same system as me. I can't be
> bothered with this thread anymore.
You can't be bothered - yet you continued responding to someone
else on this thread.. Uh huh.
Sounds like you know I'm right and you can't think of a logical
defense (since there isn't one) so your going to turn and run off
with your tail between your legs.
If anyone had any doubts that you weren't an inexperienced mail admin
who knows just enough to be dangerous you just dispelled them.
If you can't defend your hack in an open forum, then it's exactly as
I said, nothing new, nothing revolutionary, just a cheap hack that
only works if -one- site is doing it. I'll slip it in my file of
other cheap hacks that only work if one site is doing them. Who
knows maybe I might even have to use it one day for some border
case - but I sure as hell would never be foolish enough to try and
defend it. These hacks simply scream "I got mine and I don't give
a damn if you got yours", hardly the attitude for an Internet admin
to have.
What exactly do you think the SA ruleset is, Mike? It is nothing more
than a "dubious predictions of what spammers would do"
Good Lord, and on top of that, a hijacked thread, too! <headshake>
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 19:29, Ted Mittelstaedt wrote:
> Secondly with regards to this reject-but-save system that Mike is
> expounding on - it is an instance of a system that only works because
> a few people (or one person) is doing it. It is totally worthless as
> anything that can be scaled to multiple sites for a very simple reason.
>
> Right now one of the constants in the e-mail universe is that an error
> 5xx means you failed to deliver your mail.
>
> If many people deploy "reject-but-save-a-copy" then this breaks that
> assumption and the spammers response is extremely predictable - they
> will simply assume that EVERY error 5xx carries with it a chance for
> a successful delivery - so they will then program their spambots to
> continually retry no matter what the error.
>
> Right now if their spambot gets an error 5xx it schedules the victim
> address for removal - because the spambot only has a limited amount of
> time it can do things on whatever host system it has hijacked, and it
> can't spend time sending to addresses that are rejected when there are
> so many more out there that will accept the spam.
>
> If you remove that assumption by having a lot of sites deploy this
> hack of Mike's, then the spambots will simply continually send to
> millions of nonexistent e-mail addresses on your server - because
> of the chance that your running the Mike Hack and those nonexistent
> addresses your telling the spambot that are nonexistent are really
> existing.
>
> The spammers don't care that their spam is delivered to a junk mail
> folder. If the user isn't automatically deleting their junkmail unread
> (in which case there's no point in the Mike Hack in the first place)
> then they ARE having to periodically read at least the subject lines
> of messages in the Junk Mail folder. In short, the Mike Hack only has
> value if the users are periodically opening up and reading the subject
> lines of messages in the Junk Mail folder.
>
> And the spammers thought is that their spam is so attractive that
> all the user has to do is read the subject line and they will open
> it. They aren't thinking "my spam got delivered to someone's junk
> mail folder, boo hoo" They are thinking "Zowie, my mail got delivered
> to someone's folder - it's just going to be a few more weeks and I'll
> be rich, yipee yipee!!" Spammers are the most optimistic people you
> will ever meet. Only an optimist would think that the sewage they send
> out is something that people want to read.
>
> Mike I'm not sure why you think this hack of yours is so clever. It's
> just a cheap hack. I can think of a dozen more for filtering spam,
> some I've read other people expounding on over the years as the
> greatest thing since sliced bread, all of which work - and all of
> which are totally unscalable.
>
> If you want to write a clever spam filter than write one that everyone
> can use. Otherwise the more you defend this, the more you look like
> an inexperienced mail admin who knows just enough to be dangerous.
All I can see above is a long list of dubious predictions of what
spammers would do if everybody used the same system as me. I can't be
bothered with this thread anymore. Feel free to make dubious assumptions
of why that may be. Out.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Mike Cardwell wrote:
> On 11/02/2010 17:08, Bernd Petrovitsch wrote:
>
>>> Let me explain this in simple terms.
>>>
>>> Normal behaviour:
>>>
>>> Spam filtering causes a 5xx rejection. You get an NDR. You either
>>> contact the user some other way or not at all.
>> Spam filtering rejects valid non-spam because it mis-identified it as
>> "spam".
>
> Yes. It's called a "false positive".
>
>>> Behaviour on my system:
>>>
>>> Spam filtering causes a 5xx rejection. You get an NDR. You either
>>> contact the user some other way or not at all. But ... the recipient can
>> Spam filtering rejects valid non-spam because it mis-identified it as
>> "spam". Now *I* have to do something to work around *Your* buggy/screwed
>> spamcheck.
>
> No different to a normal situation where the features I've described
> aren't in place.
>
>> You just have to hope that I´m really, really that interested to my mail
>> through. If it's an answer per PM to e.g. typical ML mails (like this
>> here), you would loose.
>
> No different to a normal situation where the features I've described
> aren't in place.
>
>>> still access the email if it's something they were expecting, *and* if
>>> the sender still wants to contact the recipient they now have an *extra*
>>> option to make their life easier - they can click a URL and fill in a
>>> captcha.
>>>
>>> So ... my system provides 2 extra little features which makes some
>>> senders and some recipients lives more easy.
>> No, you are pushing effort from your side out to others. If you want to
>> do something for the (valid) sender, fix the FP rate by changing
>> whatever it needs so that my on-spam mail gets through.
>
> Ridiculous claim. In a normal situation the effort relies on the sender
> to get their mail through after a false positive occurs, or it wont get
> through at all.
>
> With the 2 features I described, the sender is provided with an extra
> simple option to get the mail through, and the recipient has also been
> provided with an option to get the mail through.
>
>>> Neither sender nor recipient would benefit from me removing those
>>> features from my system.
>> Of course anyone can do as they think it´s best. But that doesn´t imply
>> that other think the same.
>
> I want you to describe a scenario where the sender or recipient are
> actually worse off because of the particular two features I've
> described. You've failed to even attempt that so far.
>
> I know this system works well because I've been using it for a long time.
>
I'm going to make 2 points here since you all hijacked my thread for
this discussion, I feel I have the right to. ;-)
First of all with regards to accepting then processing mail, that's
bogus. It's imperative to issue an error 5xx to the sending server
before the server closes TCP connection, if your going to reject the
mail. Otherwise if you accept the message, your telling the spammer
that they have a valid e-mail address, even if such a recipient address
does not exist on your system, and your then encouraging them to spam.
The claim that amavisd* variants accept then process mail
is nonsense, nobody who runs a large mailserver with amavisd could
possibly have their server configured in this manner without it melting
down, so please no more of this ridiculous talk.
Secondly with regards to this reject-but-save system that Mike is
expounding on - it is an instance of a system that only works because
a few people (or one person) is doing it. It is totally worthless as
anything that can be scaled to multiple sites for a very simple reason.
Right now one of the constants in the e-mail universe is that an error
5xx means you failed to deliver your mail.
If many people deploy "reject-but-save-a-copy" then this breaks that
assumption and the spammers response is extremely predictable - they
will simply assume that EVERY error 5xx carries with it a chance for
a successful delivery - so they will then program their spambots to
continually retry no matter what the error.
Right now if their spambot gets an error 5xx it schedules the victim
address for removal - because the spambot only has a limited amount of
time it can do things on whatever host system it has hijacked, and it
can't spend time sending to addresses that are rejected when there are
so many more out there that will accept the spam.
If you remove that assumption by having a lot of sites deploy this
hack of Mike's, then the spambots will simply continually send to
millions of nonexistent e-mail addresses on your server - because
of the chance that your running the Mike Hack and those nonexistent
addresses your telling the spambot that are nonexistent are really
existing.
The spammers don't care that their spam is delivered to a junk mail
folder. If the user isn't automatically deleting their junkmail unread
(in which case there's no point in the Mike Hack in the first place)
then they ARE having to periodically read at least the subject lines
of messages in the Junk Mail folder. In short, the Mike Hack only has
value if the users are periodically opening up and reading the subject
lines of messages in the Junk Mail folder.
And the spammers thought is that their spam is so attractive that
all the user has to do is read the subject line and they will open
it. They aren't thinking "my spam got delivered to someone's junk
mail folder, boo hoo" They are thinking "Zowie, my mail got delivered
to someone's folder - it's just going to be a few more weeks and I'll
be rich, yipee yipee!!" Spammers are the most optimistic people you
will ever meet. Only an optimist would think that the sewage they send
out is something that people want to read.
Mike I'm not sure why you think this hack of yours is so clever. It's
just a cheap hack. I can think of a dozen more for filtering spam,
some I've read other people expounding on over the years as the
greatest thing since sliced bread, all of which work - and all of
which are totally unscalable.
If you want to write a clever spam filter than write one that everyone
can use. Otherwise the more you defend this, the more you look like
an inexperienced mail admin who knows just enough to be dangerous.
Ted
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 17:08, Bernd Petrovitsch wrote:
>> Let me explain this in simple terms.
>>
>> Normal behaviour:
>>
>> Spam filtering causes a 5xx rejection. You get an NDR. You either
>> contact the user some other way or not at all.
> Spam filtering rejects valid non-spam because it mis-identified it as
> "spam".
Yes. It's called a "false positive".
>> Behaviour on my system:
>>
>> Spam filtering causes a 5xx rejection. You get an NDR. You either
>> contact the user some other way or not at all. But ... the recipient can
> Spam filtering rejects valid non-spam because it mis-identified it as
> "spam". Now *I* have to do something to work around *Your* buggy/screwed
> spamcheck.
No different to a normal situation where the features I've described
aren't in place.
> You just have to hope that I´m really, really that interested to my mail
> through. If it's an answer per PM to e.g. typical ML mails (like this
> here), you would loose.
No different to a normal situation where the features I've described
aren't in place.
>> still access the email if it's something they were expecting, *and* if
>> the sender still wants to contact the recipient they now have an *extra*
>> option to make their life easier - they can click a URL and fill in a
>> captcha.
>>
>> So ... my system provides 2 extra little features which makes some
>> senders and some recipients lives more easy.
> No, you are pushing effort from your side out to others. If you want to
> do something for the (valid) sender, fix the FP rate by changing
> whatever it needs so that my on-spam mail gets through.
Ridiculous claim. In a normal situation the effort relies on the sender
to get their mail through after a false positive occurs, or it wont get
through at all.
With the 2 features I described, the sender is provided with an extra
simple option to get the mail through, and the recipient has also been
provided with an option to get the mail through.
>> Neither sender nor recipient would benefit from me removing those
>> features from my system.
> Of course anyone can do as they think it´s best. But that doesn´t imply
> that other think the same.
I want you to describe a scenario where the sender or recipient are
actually worse off because of the particular two features I've
described. You've failed to even attempt that so far.
I know this system works well because I've been using it for a long time.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Bernd Petrovitsch <be...@petrovitsch.priv.at>.
On Don, 2010-02-11 at 11:52 +0000, Mike Cardwell wrote:
[...]
> Let me explain this in simple terms.
>
> Normal behaviour:
>
> Spam filtering causes a 5xx rejection. You get an NDR. You either
> contact the user some other way or not at all.
Spam filtering rejects valid non-spam because it mis-identified it as
"spam".
> Behaviour on my system:
>
> Spam filtering causes a 5xx rejection. You get an NDR. You either
> contact the user some other way or not at all. But ... the recipient can
Spam filtering rejects valid non-spam because it mis-identified it as
"spam". Now *I* have to do something to work around *Your* buggy/screwed
spamcheck.
You just have to hope that I´m really, really that interested to my mail
through. If it's an answer per PM to e.g. typical ML mails (like this
here), you would loose.
> still access the email if it's something they were expecting, *and* if
> the sender still wants to contact the recipient they now have an *extra*
> option to make their life easier - they can click a URL and fill in a
> captcha.
>
> So ... my system provides 2 extra little features which makes some
> senders and some recipients lives more easy.
No, you are pushing effort from your side out to others. If you want to
do something for the (valid) sender, fix the FP rate by changing
whatever it needs so that my on-spam mail gets through.
> Neither sender nor recipient would benefit from me removing those
> features from my system.
Of course anyone can do as they think it´s best. But that doesn´t imply
that other think the same.
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 11:26, Bernd Petrovitsch wrote:
>>>> At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user,
>>>
>>> This is just wrong. Either accept the message, or reject the
>> message. Rejecting the message while secretly accepting it is just
>> completely wrong.
> [...]
>>> Let's say your filter catches a legitimate message to
>> user@yourdomain.tld from bob@mydomain.tld. Bob gets an erro saying
>> the message was spammy and didn't go through, so he goes to his gmail
>> account and sends it again, hoping for better results. This time it
>> goes through.
>>
>> Bob could also have just clicked the link in the NDR.
> Some people - e.g. /me - do not try to pass Turing tests. Obviously you
> are not interested in my mails anyway ....
If you email somebody and the spam filtering rejects the message, you
assume they don't want your mail and don't bother trying to contact them
again? Not even if it's obviously beneficial for you to do so?
> Apart from that why should I decode captchas from some random site?
> After all, they could come from a third site so that people solve them
> to the the other can log automatically into the third one ...
It's not some random email from a "random site". It's an NDR to an email
that you yourself sent.
Let me explain this in simple terms.
Normal behaviour:
Spam filtering causes a 5xx rejection. You get an NDR. You either
contact the user some other way or not at all.
Behaviour on my system:
Spam filtering causes a 5xx rejection. You get an NDR. You either
contact the user some other way or not at all. But ... the recipient can
still access the email if it's something they were expecting, *and* if
the sender still wants to contact the recipient they now have an *extra*
option to make their life easier - they can click a URL and fill in a
captcha.
So ... my system provides 2 extra little features which makes some
senders and some recipients lives more easy.
Neither sender nor recipient would benefit from me removing those
features from my system.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Bernd Petrovitsch <be...@petrovitsch.priv.at>.
On Don, 2010-02-11 at 10:38 +0000, Mike Cardwell wrote:
> On 11/02/2010 08:27, LuKreme wrote:
> >> At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user,
> >
> > This is just wrong. Either accept the message, or reject the
> message. Rejecting the message while secretly accepting it is just
> completely wrong.
[...]
> > Let's say your filter catches a legitimate message to
> user@yourdomain.tld from bob@mydomain.tld. Bob gets an erro saying
> the message was spammy and didn't go through, so he goes to his gmail
> account and sends it again, hoping for better results. This time it
> goes through.
>
> Bob could also have just clicked the link in the NDR.
Some people - e.g. /me - do not try to pass Turing tests. Obviously you
are not interested in my mails anyway ....
Apart from that why should I decode captchas from some random site?
After all, they could come from a third site so that people solve them
to the the other can log automatically into the third one ...
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/02/2010 08:27, LuKreme wrote:
>> At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user,
>
> This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong.
"This is just wrong" is not a very good argument for your case.
Hopefully you'll do better below.
> Let's say your filter catches a legitimate message to user@yourdomain.tld from bob@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through.
Bob could also have just clicked the link in the NDR.
> Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't.
>
> How have you helped your user?
You've described one scenario out of many. One where my system wouldn't
provide any additional benefit, but at the same time it doesn't make
either the sender or the recipient worse off. You didn't even describe a
scenario which is particularly common. Here's another scenario. One
which is definitely more common:
A user goes to some website and signs up. They're sent an automated
confirmation email. The mail server classifies the incoming email as
spam and rejects it. In my system, the user is expecting a confirmation
email and doesn't receive it so checks their Junk E-Mail folder and
finds it there. In a "normal" system which just 5xx's, the user has to
wait longer just to make sure that the email wasn't delayed and then has
to jump through loops to find an alternative means of confirming the signup.
A couple of days ago I bought a lottery ticket online for the
EuroMillions lottery this Friday. The order email got a score of 5.5.
Mainly because the "HK_LOTTO" rule fired which applied a score of 3.6. I
noticed that I never received a confirmation email, so I looked in my
Junk E-Mail folder and there it was. Highly useful.
> As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam...
Your SpamAssassin installation would, "almost certainly," classify an
NDR, which your *own system* generated, as spam? I rarely use "LOL", but
in this case I think it's appropriate... LOL.
> I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk.
Providing the URL *might* provide benefit for *some* people. Again, the
existance of the URL doesn't make either the sender or the recipient
worse off in any way.
You've failed to convince me.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by LuKreme <kr...@kreme.com>.
On 10-Feb-2010, at 02:42, Mike Cardwell wrote:
>
> At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user,
This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong.
Let's say your filter catches a legitimate message to user@yourdomain.tld from bob@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through.
Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't.
How have you helped your user?
As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam...
I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk.
--
'How do you know I'm mad?' said Alice 'You must be' said the Cat
'or you wouldn't have come here.'
Re: Newest spammer trick - non-blank subject lines?
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 10/02/2010 00:31, Kai Schaetzl wrote:
>> Our SA installation
>> is correctly tagging this as spam and sending it forward
>> to the user.
>
> Well, the usual procedure (*) is to add headers that identify the message
> as spam and maybe even show the score, so users can have the mail client
> file it to junk. I would consider adding "Spam" in the subject as a
> courtesy. You do not have control over the subject at all, it could even
> come from another system and be already "tagged" as spam there. However,
> you have control over the headers you add yourself and there's where the
> music should play.
>
> (*) I personally think that it's a waste to deliver all these messages,
> anyway. We put all messages over a certain score in quarantine and there's
> almost never a need to release one.
At SMTP time I return a 5xx code during the "DATA" phase for messages
classified as Spam. However, I also deliver the message into a read only
"Junk E-Mail" folder for the user, immediately marked as Seen and
flagged as Junk. Email in "Junk E-Mail" folders is automatically deleted
after a week.
In the 5xx code, I also include a special URL which the sender will
hopefully see if they read their NDR. They can then click that URL and
fill in a captcha in order to release the email. Releasing the email
removes it from the recipients Junk E-Mail folder, and places a copy in
their INBOX.
So... the sender gets notified if the message is filtered and if they're
human they can "unclassify" it as such. While the recipient isn't
bothered by Spam, however if they're expecting a message which doesn't
arrive due to spam filtering, they know they can just peak in their
"Junk E-Mail" folder and it will be there.
Best of both Worlds.
--
Mike Cardwell : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Kai Schaetzl wrote:
> Ted Mittelstaedt wrote on Tue, 09 Feb 2010 12:58:01 -0800:
>
>> Our SA installation
>> is correctly tagging this as spam and sending it forward
>> to the user.
>
> Well, the usual procedure (*) is to add headers that identify the message
> as spam and maybe even show the score, so users can have the mail client
> file it to junk. I would consider adding "Spam" in the subject as a
> courtesy. You do not have control over the subject at all, it could even
> come from another system and be already "tagged" as spam there. However,
> you have control over the headers you add yourself and there's where the
> music should play.
>
In an ideal world.
> (*) I personally think that it's a waste to deliver all these messages,
> anyway. We put all messages over a certain score in quarantine and there's
> almost never a need to release one.
>
That would mean even more expensive support labor having to be spent on
e-mail since now we would have to putz around with a quarantine. One of
our ISP customers does this with mailscanner, (we built his server, BTW)
but they have a lot fewer end user customers.
With us, we have a great many very uneducated/inexperienced/untrained
users and subject line munging is about the most they can handle. I'd
estimate only about 2% of them actually use the filtering in their
MUA's and 1% of them avail themselves of the procmail-based filtering
on the server. Even less than that avail themselves of the PHP-based
interface for SA that I put onto the server that allows them to
TURN OFF the subject line munging.
There's no question that subject-line munging is inelegant and a
perversion of the Correct Way to do e-mail. But it's necessary when
your dealing with mail users who you have to hit over the head with
a 2 x 4 to get them to notice something.
Ted
> I was about to ask about the message, but I just see that you posted it
> now.
>
> Kai
>
Re: Newest spammer trick - non-blank subject lines?
Posted by Kai Schaetzl <ma...@conactive.com>.
Ted Mittelstaedt wrote on Tue, 09 Feb 2010 12:58:01 -0800:
> Our SA installation
> is correctly tagging this as spam and sending it forward
> to the user.
Well, the usual procedure (*) is to add headers that identify the message
as spam and maybe even show the score, so users can have the mail client
file it to junk. I would consider adding "Spam" in the subject as a
courtesy. You do not have control over the subject at all, it could even
come from another system and be already "tagged" as spam there. However,
you have control over the headers you add yourself and there's where the
music should play.
(*) I personally think that it's a waste to deliver all these messages,
anyway. We put all messages over a certain score in quarantine and there's
almost never a need to release one.
I was about to ask about the message, but I just see that you posted it
now.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com