Discussion:
Anti-Spam ideas for usenet/list harvested email addresses
(too old to reply)
Jacob Anawalt
2003-09-23 19:16:38 UTC
Permalink
To me the big question is how do I avoid the spam in the first place,
besides avoiding email all together? I want to participate on the web, I
just don't want so much junk email nor do I want to have my mailbox or ISP
suffering from gigabytes of worm attachments or advertising data.

We've all done or seen people do this: jacob at cachevalley dot com,
***@cachevalley.com, ***@cachevalley.nospam.com, etc.

Are we kidding ourselves thinking that if we can write a filter rule that
just catches SoBig.[A-Z], that someone else can't turn all of those 'safe'
addresses back into the real email address?

I've already mentioned the web authorization idea and the rotate your
email address on some schedule ideas in another thread. I've even seen a
web site go so far as to use a .js file function to put together the email
address from a bunch of fragments when you click the mailto link. That
would take more work to parse, but it is still possible by having an email
grabbing webbot that can run javascript.

Another though I've had on the mailing list issues (besides wondering why
I'm trying to make mail act like a news client with threads and looking
for a 'watch thread' capable client) is if I had an email address to use
on mailing lists that only accepted email from the list servers I was on
and reject all others I should only get the spam that relayed through the
list.

The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.

Some ideas for rules to accept or reject the email may include:

If HELO does not match a reverse DNS lookup and doesn't match the domain
of RCPT TO: or to a user specified value then the mail is rejected.

A looser match would be just on the HELO <name> where the name given is
some md5hash of the user's email address and some value noted on the
mailing list. People start getting spammed, the list admin changes the key
used to generate the name value and people go to the web to see what it
has been changed to.

A tighter setup might be to have the hash in the MAIL FROM: <value> and
have it be a hash of the subscriber's list password and their email
address. That way the subscriber can change their list password at any
time they see spam coming “from” the list.

I'm sure there are other better ideas to be had along the lines of how to
quickly identify that the sending server is who they say they are and look
up a safe list to see if the user accepts email from that server.

A side benefit of using an email address that only accepts list traffic
for some would be that it would reject the second email if someone replies
to you and the list. People using this setup could have their .sig say
"This email address only accepts authorized list traffic, please reply to
the list."

Since we have seen that a greater volume of worm mail is possible with
email addresses usenet and mailing lists, it seems a setup based on this
system could help cut down the cost of fighting spam generated from those
sources. The rules would be based on a simple lists, with each user
responsible for maintaining their list. Much less CPU power, bandwidth and
storage space would be required to match those rules because the matching
is done before delivery is accepted. Mailing lists could publish to their
subscribe page the values they use for HELO and MAIL FROM when sending the
messages to all subscribers.

Compare this to the "dog chasing cars" method of inventing a new filter
rule that looks through the MIME data to decide if this is the latest worm
you don't want or the kissing picture that you do. Sure it's cool to be a
geek and figure out the rules. If you like doing this, do it. Maybe spam
isn't a cost to you but a benifit if you consider your enjoyment at
solving each filter puzzle. I think that's why I like finding bugs, to
help find and solve puzzles. On the other hand this method of filtering is
more expensive in every measure I can think of except the freedom of
allowing anyone to email you anytime. You spend time thinking up rules,
writing rules and testing rules. The rules are applied after you have
accepted the bandwidth of the transfer. Running the rules takes CPU time
and possibly more bandwidth as you do RBL DNS or Razor and storing the
email takes disk space.

If you're sick of getting swamped (as a user or admin) wouldn't this setup
be usefull? An ISP could encourage users to use ***@isp.com for
email addresses that are going to be used on usenet or public mailing
lists. The new email address could just dump into the real address after
the mailing list rules were validated, or it could be it's own account and
mailbox.

Of course some will say "but I only have my ISP available and it doesn't
do that" and others will say "I don't like that idea because it isn't easy
or flexible enough. I want email from everybody as long as it isn't
UCE/UBE/A worm or virus". That's why there isn't just one way to do
things, we all have different ideas on what is best.

One major concern that I've lightly touched on and will bring up again is
“What if I want to have other people contact me off list?” You wouldn't
want to post your non-list-only email to the list, that would be
counter-productive. There's got to be a convenient way of providing a
source for people to look up your email address that is very resistant to
scripting it's harvest for the UCE/worms/etc. One idea that comes to mind
are images of pictures with your email address on your web site. I keep
thinking that PGP/GPG should be able to help in some way, either by adding
to the EHLO command set or something on the users web site. There have to
be better and still simple ways of doing this that make it cost much more
to find our email addresses than it costs us to filter the junk.

The sad part is that I've already squandered my username at this email
address by putting it where it can be harvested in mass by worm/virus and
UCE/UBE collection scripts, and I had already read an article cautioning
me against this. Oh well live and learn (someday I'll learn anyway.)

I'm going to look into setting up a new email address with mail server
rules for delivery driven by a user supplied whitelist after waiting a few
days for comments and flames on this idea. If you know of links to pages
already discussing how to do this with postfix, please share them.
--
Jacob
Trying out SquirrelMail
Jeronimo Pellegrini
2003-09-23 19:43:00 UTC
Permalink
Post by Jacob Anawalt
I've already mentioned the web authorization idea and the rotate your
email address on some schedule ideas in another thread. I've even seen a
web site go so far as to use a .js file function to put together the email
address from a bunch of fragments when you click the mailto link. That
would take more work to parse, but it is still possible by having an email
grabbing webbot that can run javascript.
That would also break for people who use non-Javascript enabled
browsers.
Post by Jacob Anawalt
Another though I've had on the mailing list issues (besides wondering why
I'm trying to make mail act like a news client with threads and looking
for a 'watch thread' capable client) is if I had an email address to use
on mailing lists that only accepted email from the list servers I was on
and reject all others I should only get the spam that relayed through the
list.
Interesting. But managing that would require some energy from you...
Post by Jacob Anawalt
The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.
If HELO does not match a reverse DNS lookup and doesn't match the domain
of RCPT TO: or to a user specified value then the mail is rejected.
Blocks big ISPs... I've found two already. One of them is movistar.com.
Can't remember the other
Also, probably breaks small businesses who use DSL and can't use their
ISPs smarthosts (see the recent thread, "OT: Martin Krafft - mail
bouncing".
Post by Jacob Anawalt
A looser match would be just on the HELO <name> where the name given is
some md5hash of the user's email address and some value noted on the
mailing list. People start getting spammed, the list admin changes the key
used to generate the name value and people go to the web to see what it
has been changed to.
If I use taht, I'll have to keep changing the key every now and then.
Spam is bad not only because it takes a lot of bandwidth, but also
because it's not convenient. Challenge-response solution can be as
inconvenient as spam itself, for example. And I think the same would
work for this solution...
Post by Jacob Anawalt
I'm sure there are other better ideas to be had along the lines of how to
quickly identify that the sending server is who they say they are and look
up a safe list to see if the user accepts email from that server.
Make the list server PGP-sign the messages, maybe? You install the list
server key once, and never worry about it again?
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new filter
rule that looks through the MIME data to decide if this is the latest worm
you don't want or the kissing picture that you do. Sure it's cool to be a
geek and figure out the rules. If you like doing this, do it. Maybe spam
isn't a cost to you but a benifit if you consider your enjoyment at
solving each filter puzzle. I think that's why I like finding bugs, to
help find and solve puzzles. On the other hand this method of filtering is
more expensive in every measure I can think of except the freedom of
allowing anyone to email you anytime. You spend time thinking up rules,
writing rules and testing rules. The rules are applied after you have
accepted the bandwidth of the transfer. Running the rules takes CPU time
and possibly more bandwidth as you do RBL DNS or Razor and storing the
email takes disk space.
I agree. But then I think any technical solution has the same problem.
The "real solution" would be making spammers not want to spam (so we
don't have to block them). You'd need to understand the intricacies of
their business, and so something that makes them give up. A very naïve
thing would be to start doing statistical research, asking people how
they feel when they get spam, and make that get to the clients of these
spammers. But as I said, this is naïve, and assumes that we know how
that business works. (I don't think I know that) But something along
those lines will have to work, someday -- I hope!

J.
Jacob Anawalt
2003-09-23 20:12:16 UTC
Permalink
[snip]
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.
If HELO does not match a reverse DNS lookup and doesn't match the domain
of RCPT TO: or to a user specified value then the mail is rejected.
Blocks big ISPs... I've found two already. One of them is movistar.com.
Can't remember the other
Also, probably breaks small businesses who use DSL and can't use their
ISPs smarthosts (see the recent thread, "OT: Martin Krafft - mail
bouncing".
But my goal was to reduce the spam I get that is harvested from mailing
lists. If someone wants to subscribe to a mailing list that doesn't do
reverse dns, then there needs to be authentication before DATA on some
other bit of information. I could still get posts from the guy in Brazil
or the guy using SMTP off of his cable modem DHCP'd address because they
would be mailing the list, not me. The list is mailing me.
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
A looser match would be just on the HELO <name> where the name given is
some md5hash of the user's email address and some value noted on the
mailing list. People start getting spammed, the list admin changes the key
used to generate the name value and people go to the web to see what it
has been changed to.
If I use taht, I'll have to keep changing the key every now and then.
Spam is bad not only because it takes a lot of bandwidth, but also
because it's not convenient. Challenge-response solution can be as
inconvenient as spam itself, for example. And I think the same would
work for this solution...
Well, that's the cost we pay for conveniance. I'm willing to give up that
freedom for less spam on the email address I use for mailing lists. My
first choice as a user will be to subscribe to lists that have proper
reverse dns. I understand that others don't want that hassel.
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
I'm sure there are other better ideas to be had along the lines of how to
quickly identify that the sending server is who they say they are and look
up a safe list to see if the user accepts email from that server.
Make the list server PGP-sign the messages, maybe? You install the list
server key once, and never worry about it again?
If some small PGP/GPG data could be sent as part of a new EHLO syntax
command then OK, otherwise I'm in the DATA section again. It would have to
be a standard before I'd use that.
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new filter
rule that looks through the MIME data to decide if this is the latest worm
you don't want or the kissing picture that you do. Sure it's cool to be a
geek and figure out the rules. If you like doing this, do it. Maybe spam
isn't a cost to you but a benifit if you consider your enjoyment at
solving each filter puzzle. I think that's why I like finding bugs, to
help find and solve puzzles. On the other hand this method of filtering is
more expensive in every measure I can think of except the freedom of
allowing anyone to email you anytime. You spend time thinking up rules,
writing rules and testing rules. The rules are applied after you have
accepted the bandwidth of the transfer. Running the rules takes CPU time
and possibly more bandwidth as you do RBL DNS or Razor and storing the
email takes disk space.
I agree. But then I think any technical solution has the same problem.
The "real solution" would be making spammers not want to spam (so we
don't have to block them). You'd need to understand the intricacies of
their business, and so something that makes them give up. A very naïve
thing would be to start doing statistical research, asking people how
they feel when they get spam, and make that get to the clients of these
spammers. But as I said, this is naïve, and assumes that we know how
that business works. (I don't think I know that) But something along
those lines will have to work, someday -- I hope!
The latest churn on debian-user about Spam hasn't been UCE spam. It's been
worm spam. I don't know anyone personally who likes to recieve WORM/Virus
code in their inbox but it persists. I don't see a near-term solution for
convincing the individuals who write this code.

As for UCE/UBE, well someone else can deal with the politics of it. I will
also be glad when they just decide to stop.

I just want some good ideas on keeping them from getting my address in the
first place or on minimizing the bandwidth, cpu and human time on my end
to block any that did get my address.
--
Jacob
Trying out SquirrelMail
Jeronimo Pellegrini
2003-09-23 20:23:50 UTC
Permalink
Post by Jacob Anawalt
But my goal was to reduce the spam I get that is harvested from mailing
lists. If someone wants to subscribe to a mailing list that doesn't do
reverse dns, then there needs to be authentication before DATA on some
other bit of information. I could still get posts from the guy in Brazil
or the guy using SMTP off of his cable modem DHCP'd address because they
would be mailing the list, not me. The list is mailing me.
Hm, that's right, indeed.
Post by Jacob Anawalt
Post by Jeronimo Pellegrini
Make the list server PGP-sign the messages, maybe? You install the list
server key once, and never worry about it again?
If some small PGP/GPG data could be sent as part of a new EHLO syntax
command then OK, otherwise I'm in the DATA section again. It would have to
be a standard before I'd use that.
You want to reject the mail before it's queued. I like the idea, but that's
more difficult to implement...

I wonder how many MTAs would let you do this:

- set up a mail for lists only
- set up terribly-aggressive blocking with DNSBLs and other things (like
requiring the reverse DNS), *only for that address*. Other addresses
would not go through such restrictive tests.
Post by Jacob Anawalt
The latest churn on debian-user about Spam hasn't been UCE spam. It's been
worm spam. I don't know anyone personally who likes to recieve WORM/Virus
code in their inbox but it persists. I don't see a near-term solution for
convincing the individuals who write this code.
Right, I forgot about that.

Anyway... Blocking servers wouldn't help in the case of viruses, I think.
Ordinary people get viruses, and the mail is sent through their (probably
correctly configured) smarthost. Maybe something like Postfix
header_checks? But that would also require some work :-(

J.
Rich Puhek
2003-09-23 21:17:44 UTC
Permalink
Post by Jeronimo Pellegrini
Right, I forgot about that.
Anyway... Blocking servers wouldn't help in the case of viruses, I think.
Ordinary people get viruses, and the mail is sent through their (probably
correctly configured) smarthost. Maybe something like Postfix
header_checks? But that would also require some work :-(
J.
Unfortunately (or fortunately, depending on how the blocking works),
some of the newer worms do not use the smarthost, but instead they use
their own little SMTP engine. IIRC, Sobig.F did this.

--Rich

_________________________________________________________

Rich Puhek
ETN Systems Inc.
2125 1st Ave East
Hibbing MN 55746

tel: 218.262.1130
email: ***@etnsystems.com
_________________________________________________________
Jacob Anawalt
2003-09-23 22:46:28 UTC
Permalink
Jeronimo Pellegrini said:
[snip]
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
Post by Jeronimo Pellegrini
Make the list server PGP-sign the messages, maybe? You install the
list
Post by Jeronimo Pellegrini
server key once, and never worry about it again?
If some small PGP/GPG data could be sent as part of a new EHLO syntax
command then OK, otherwise I'm in the DATA section again. It would have to
be a standard before I'd use that.
You want to reject the mail before it's queued. I like the idea, but that's
more difficult to implement...
- set up a mail for lists only
- set up terribly-aggressive blocking with DNSBLs and other things (like
requiring the reverse DNS), *only for that address*. Other addresses
would not go through such restrictive tests.
I hope postfix does. I'm pretty sure it will, since it supports external
mapping programs. I don't know how complicated it will be, but I'm hoping
it's like this:

RECPT TO: user
User has entries in ~/.safe-list-only?
Does the data from MAIL FROM or HELO match an entry in the list?
Does the reverse DNS and forward DNS for the HELO match the list?
250 OK
else
550 Error message.
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
The latest churn on debian-user about Spam hasn't been UCE spam. It's been
worm spam. I don't know anyone personally who likes to recieve WORM/Virus
code in their inbox but it persists. I don't see a near-term solution for
convincing the individuals who write this code.
Right, I forgot about that.
Anyway... Blocking servers wouldn't help in the case of viruses, I think.
Ordinary people get viruses, and the mail is sent through their (probably
correctly configured) smarthost. Maybe something like Postfix
header_checks? But that would also require some work :-(
My normal email address that was in my windoze using friend's outlook
express address book would still be vulnerable to email from the virus
running on his computer.

My list-only email address would be sitting pretty costing the mail server
very little by rejecting all email including ones generated by a friend or
some other mailing list subscriber. The only virus mail it should get is
the stuff that makes it through the mailing list server, and Debian's
servers do a very good job at filtering this. Since this address is the
one spread across usenet and many subscriber's address books, I think it
is the more important one to be restrictive with.
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:31:06 UTC
Permalink
Post by Jeronimo Pellegrini
Anyway... Blocking servers wouldn't help in the case of viruses, I think.
Ordinary people get viruses, and the mail is sent through their (probably
correctly configured) smarthost. Maybe something like Postfix
header_checks? But that would also require some work :-(
The latest worms have *not* been using smarthosts.
vbl.messagelabs.com becomes an interesting possibility.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Ray
2003-09-23 21:16:02 UTC
Permalink
Post by Jacob Anawalt
[snip]
The latest churn on debian-user about Spam hasn't been UCE spam.
It's been worm spam. I don't know anyone personally who likes to
recieve WORM/Virus code in their inbox but it persists. I don't see
a near-term solution for convincing the individuals who write this
code.
<rant>

it seems to me the easiest solution would be for ISPs to have a
policy and software that supported the policy of no .exe .com .src
.pif .bat (etc...) attachments. any email will either be dropped or
have the attachment dropped and replaced with a short explination of
it being against policy and how to make a zip/gz/tar/whatever file if
they really want to send a .exe

since most viruses now use bad mime headers for the attachment, we
won't be able to filter on that. i talked with my isp about it, but
for some reason one customer regularly sends a .exe and since they
don't want to make a policy change that would affect their customers
business we don't get to enable that feature on our email server.

the downside of course will be that virus writers will then attach
.zips and use the normal social hacking they do now to get people to
open the attachment anyway.

perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it
go through a little tutorial about why not to open unknow attachments
have message go something like "I was foolish enough to open the
attachment, and since you are at risk of getting a message from me
with a virus, this attachment has forwarded itsself to you"

[1] http://msn.bbspot.com/News/2002/01/open.html

</rant>
Jacob Anawalt
2003-09-23 23:01:52 UTC
Permalink
Post by Ray
Post by Jacob Anawalt
[snip]
The latest churn on debian-user about Spam hasn't been UCE spam.
It's been worm spam. I don't know anyone personally who likes to
recieve WORM/Virus code in their inbox but it persists. I don't see
a near-term solution for convincing the individuals who write this
code.
<rant>
it seems to me the easiest solution would be for ISPs to have a
policy and software that supported the policy of no .exe .com .src
.pif .bat (etc...) attachments. any email will either be dropped or
have the attachment dropped and replaced with a short explination of
it being against policy and how to make a zip/gz/tar/whatever file if
they really want to send a .exe
since most viruses now use bad mime headers for the attachment, we
won't be able to filter on that. i talked with my isp about it, but
for some reason one customer regularly sends a .exe and since they
don't want to make a policy change that would affect their customers
business we don't get to enable that feature on our email server.
the downside of course will be that virus writers will then attach
.zips and use the normal social hacking they do now to get people to
open the attachment anyway.
perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it
go through a little tutorial about why not to open unknow attachments
have message go something like "I was foolish enough to open the
attachment, and since you are at risk of getting a message from me
with a virus, this attachment has forwarded itsself to you"
[1] http://msn.bbspot.com/News/2002/01/open.html
</rant>
I am OK with that policy. The servers I maintain reject email with a
windows executable attachment fingerprint with a message suggesting the
sender zip the file. My workplace has had no issues with this policy.

If more ISP's did this and blocked outgoing smtp that didn't relay through
their servers that happened to scan inbound and outbound mail for viruses,
maybe we'd be better off in the virus/worm scene. Maybe we'd all be
happier, or maybe we'd have more frustration because what use to work
doesn't.

I think if you delete the attachment from the email you had better include
some verbose explination that shows up in the html and text versions or
change the subject. It's hard enough knowing if the other person forgot to
attach the file or not without adding a reason to suspect your own mail
server.

Others hate the policy and will tell you horror stories of getting zip
installed and talking people through zipping a file.

Later viruses may send zipped copies and we have the same problem again,
except that hopefully it's less data because it's zipped.

Also, restrictions like no outgoing SMTP can be bad for people who run
well managed SMTP services in an ISP's network.

While waiting for your simpler solution to be enacted across every
computer on the internet, I'll keep looking for some interim solution. :)
--
Jacob
Trying out SquirrelMail
Kirk Strauser
2003-09-23 22:30:38 UTC
Permalink
perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it go
through a little tutorial about why not to open unknow attachments have
message go something like "I was foolish enough to open the attachment,
and since you are at risk of getting a message from me with a virus, this
attachment has forwarded itsself to you"
Indeed. You know, we're going through a lot of effort and hypothesizing do
to exactly one problem: Outlook* makes it easy for uneducated users to do
stupidly dangerous things. That's it - the whole problem. You don't get
junk from Macs or Mozilla users, and those are nice, easy-to-use GUI
clients. We're having this entire conversation simply because Microsoft
refuses to make it more difficult to execute an attached file than clicking
on an attachment icon.

Out of curiosity, are there *any* legitimate reasons at all why you'd want
to mail an uncompressed executable to someone?
--
Kirk Strauser
In Googlis non est, ergo non est.
Jacob Anawalt
2003-09-26 00:52:37 UTC
Permalink
Post by Kirk Strauser
perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it go
through a little tutorial about why not to open unknow attachments have
message go something like "I was foolish enough to open the attachment,
and since you are at risk of getting a message from me with a virus, this
attachment has forwarded itsself to you"
Indeed. You know, we're going through a lot of effort and hypothesizing do
to exactly one problem: Outlook* makes it easy for uneducated users to do
stupidly dangerous things.
Outlook2002 will tell you "bla bla bla unsafe bla bla bla outlook users
might not be able to open this" because without being hooked to an
exchange server w/ a policy to allow unsafe attachments, outlook blocks
your access to those attachments.

OE will let you send it w/o a peep, but the default is to block access to
it on the recieving side. You just have to uncheck a little box to get the
attachment.
Post by Kirk Strauser
That's it - the whole problem. You don't get
junk from Macs or Mozilla users, and those are nice, easy-to-use GUI
clients. We're having this entire conversation simply because Microsoft
refuses to make it more difficult to execute an attached file than clicking
on an attachment icon.
As much as I agree to some degree or another to the spirit of what you're
saying, I started this thread because Swen was swamping me.

If thousands of people were personally emailing me virus laiden emails,
that's one thing, but that's not the case here. I'm getting thousands of
emails from copies of a virus that isn't opening O* to send it's mail. I
am getting those emails because 1) Win users were either not updated with
security patches or gullible and 2) I have posted to this list using my
valid email address.

Since I don't have much faith in fixing #1 any time soon beyond some pep
talks to friends, I am focusing on how to avoid the easy target #2 left me
open to be. Normally when I get viruses it's only from people I've sent
email to. This time it was from anyone who was infected/unprotected and
who's computer found my email from the mailing list.

I would also like to avoid UCE/UCB Spam that harvested my email from
usenet as well. That isn't a virus or email client specific issue.
Post by Kirk Strauser
Out of curiosity, are there *any* legitimate reasons at all why you'd want
to mail an uncompressed executable to someone?
I'm sure someone could pipe up about how it's hard to walk their
grandma/client through installing *zip, which unfortunatly is a valid
point. :(

Lets say all viruses start mailing zipped copies of themselves. They only
have to zip themselves once on the host machine then mail that copy. Now
we have to watch for a zip archive in mime data and unzip all mail to scan
it, or reject zipped files as well. :(

I'm all for p2p file sharing or some server based file store and only
sending p2p invite keys/urls in your email. If email were only text, load
could sure drop, but I don't think it will happen. Its too convenient. I
know I use it even when I don't _have_ to.

Right now, if my grandma tries to email me some christmas windows screen
saver (possibly a virus in disguise as something neat), she get's a '550
We do not accept executable attachments' and I can deal with any flack
telling her "I'm sorry, but I don't want to get a virus." If someone else
sends me the same file but claims to be her, they get the 550 unless an
open relay was involved. I don't post-delivery bounce.
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:40:27 UTC
Permalink
Post by Jacob Anawalt
OE will let you send it w/o a peep, but the default is to block access to
it on the recieving side. You just have to uncheck a little box to get the
attachment.
Wow, way too easy. It should require you to type something long and
case sensitive. You know, something like, "Yes, I fully understand
that what I am asking is roughly as brilliant as drinking bleach."
Post by Jacob Anawalt
I'm sure someone could pipe up about how it's hard to walk their
grandma/client through installing *zip, which unfortunatly is a valid
point. :(
Actually, not really. It's raising the aptitude bar. People lacking
the aptitude to do that probably don't know what they're doing to
begin with, so this would work for the very short period of time from
where it becomes widespread to the time virus authors adapt.
Post by Jacob Anawalt
Lets say all viruses start mailing zipped copies of themselves. They only
have to zip themselves once on the host machine then mail that copy. Now
we have to watch for a zip archive in mime data and unzip all mail to scan
it, or reject zipped files as well. :(
And there's this problem.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Pigeon
2003-09-26 15:05:39 UTC
Permalink
Post by Paul Johnson
Wow, way too easy. It should require you to type something long and
case sensitive. You know, something like, "Yes, I fully understand
that what I am asking is roughly as brilliant as drinking bleach."
...sulphuric acid, on the other hand, is really tasty.
--
Pigeon

Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Colin Watson
2003-09-26 20:18:51 UTC
Permalink
Post by Pigeon
Post by Paul Johnson
Wow, way too easy. It should require you to type something long and
case sensitive. You know, something like, "Yes, I fully understand
that what I am asking is roughly as brilliant as drinking bleach."
...sulphuric acid, on the other hand, is really tasty.
I guess it saves on toothpaste.
--
Colin Watson [***@flatline.org.uk]
t***@comcast.net
2003-09-27 06:12:05 UTC
Permalink
Post by Colin Watson
Post by Pigeon
Post by Paul Johnson
Wow, way too easy. It should require you to type something long and
case sensitive. You know, something like, "Yes, I fully understand
that what I am asking is roughly as brilliant as drinking bleach."
...sulphuric acid, on the other hand, is really tasty.
I guess it saves on toothpaste.
I used to *love* licking my fingers after handling low-concentration
sulfuric acid in Chemistry class.

It tastes exactly like salt -n- vinegar potato chips (salt in hands;
acid like acid).

That was highly DILUTE acid, no jokes necessary
Kirk Strauser
2003-09-26 14:36:10 UTC
Permalink
Post by Jacob Anawalt
If thousands of people were personally emailing me virus laiden emails,
that's one thing, but that's not the case here. I'm getting thousands of
emails from copies of a virus that isn't opening O* to send it's mail.
Same here, but they're from machines that were infected *by* an Outlook*
user opening their mail.
Post by Jacob Anawalt
I'm sure someone could pipe up about how it's hard to walk their
grandma/client through installing *zip, which unfortunatly is a valid
point. :(
I disagree. I can't think of any reason why I'd be mailing an executable to
someone instead of a URL to where they can download it themselves, with the
exception of development collaboration among people experienced enough to
use *zip.
Post by Jacob Anawalt
Lets say all viruses start mailing zipped copies of themselves. They only
have to zip themselves once on the host machine then mail that copy. Now
we have to watch for a zip archive in mime data and unzip all mail to scan
it, or reject zipped files as well. :(
I only think that'd be a problem *if* Microsoft built an
unzip-then-execute-er into Windows (which is admittedly not implausible).
Why? Because the first thing that gets permanently burned into your brain
when you work in a tech support position is "people are lazy". I can almost
guarantee that requiring an additional couple of clicks before a Trojan
installer can be run would drop infection rates by 90%.

I think a more solid long-term strategy would be to write mail clients that
make it impossible to automatically perform any action on an attachment more
advanced than displaying a picture. Want to play an attached MP3? Save it
to your drive then load it. Want to open a .zip archive? Save it to your
drive first. Refer back to "people are lazy". Removing the "One-Click (TM)
Infection" vector would dramatically reduce trojan distribution.
--
Kirk Strauser
In Googlis non est, ergo non est.
Pigeon
2003-09-27 17:03:22 UTC
Permalink
Post by Kirk Strauser
I disagree. I can't think of any reason why I'd be mailing an executable to
someone instead of a URL to where they can download it themselves, with the
exception of development collaboration among people experienced enough to
use *zip.
I can. I don't have a website.
Post by Kirk Strauser
I only think that'd be a problem *if* Microsoft built an
unzip-then-execute-er into Windows (which is admittedly not implausible).
I think some of the zip tools do this, or aren't far away from it, in
the name of trying to make the zipped-ness of the files as transparent
as possible.
Post by Kirk Strauser
Why? Because the first thing that gets permanently burned into your brain
when you work in a tech support position is "people are lazy". I can almost
guarantee that requiring an additional couple of clicks before a Trojan
installer can be run would drop infection rates by 90%.
I think a more solid long-term strategy would be to write mail clients that
make it impossible to automatically perform any action on an attachment more
advanced than displaying a picture. Want to play an attached MP3? Save it
to your drive then load it. Want to open a .zip archive? Save it to your
drive first. Refer back to "people are lazy". Removing the "One-Click (TM)
Infection" vector would dramatically reduce trojan distribution.
I do agree with this. But it's rather against the M$ philosophy, it
seems...
--
Pigeon

Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
cr
2003-09-26 20:36:01 UTC
Permalink
Post by Kirk Strauser
Out of curiosity, are there *any* legitimate reasons at all why you'd want
to mail an uncompressed executable to someone?
I can think of just one ... zip.exe (self-extracting), for someone who
doesn't have zip.

Well, you asked. :)

cr
Arnt Karlsen
2003-09-26 20:33:51 UTC
Permalink
On Sat, 27 Sep 2003 08:36:01 +1200,
Post by cr
Post by Kirk Strauser
Out of curiosity, are there *any* legitimate reasons at all why
you'd want to mail an uncompressed executable to someone?
I can think of just one ... zip.exe (self-extracting), for someone
who doesn't have zip.
Well, you asked. :)
..to swat that last one too: _Nobody_ needs binaries in email.
Those without "zip.exe", is best helped with an url, to it.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Monique Y. Herman
2003-09-26 23:06:50 UTC
Permalink
Post by Arnt Karlsen
..to swat that last one too: _Nobody_ needs binaries in email.
Those without "zip.exe", is best helped with an url, to it.
Nobody needs binary *executables*. My dad isn't going to ever produce
an executable -- he will have gotten it from *somewhere*, and can
probably send me a link.

On the other hand, my dad *does* produce pictures, and I find it
unlikely that he will learn how to upload them to a server. I'd like to
see pictures of my family, so I deem those binaries acceptable.
--
monique
Arnt Karlsen
2003-09-27 22:03:35 UTC
Permalink
On Fri, 26 Sep 2003 23:06:50 +0000 (UTC),
penned:>
Post by Arnt Karlsen
..to swat that last one too: _Nobody_ needs binaries in email.
Those without "zip.exe", is best helped with an url, to it.
Nobody needs binary *executables*. My dad isn't going to ever produce
an executable -- he will have gotten it from *somewhere*, and can
probably send me a link.
On the other hand, my dad *does* produce pictures, and I find it
unlikely that he will learn how to upload them to a server. I'd like
to see pictures of my family, so I deem those binaries acceptable.
..heh, in NBC class in boot school and onwards, I learned how to
protect myself and my troops against binary chemical agents. ;-)

..so, pop's pictures won't _ever_ cause binary execution? ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Paul Johnson
2003-09-26 08:35:56 UTC
Permalink
Post by Ray
it seems to me the easiest solution would be for ISPs to have a
policy and software that supported the policy of no .exe .com .src
.pif .bat (etc...) attachments. any email will either be dropped or
have the attachment dropped and replaced with a short explination of
it being against policy and how to make a zip/gz/tar/whatever file if
they really want to send a .exe
That's exactly what we want to do: force the user to open a tarball to
figure out what's up. 8:oP Worm writers *will* adapt to this.
Post by Ray
perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it
go through a little tutorial about why not to open unknow attachments
have message go something like "I was foolish enough to open the
attachment, and since you are at risk of getting a message from me
with a virus, this attachment has forwarded itsself to you"
Eh. The way I handled NIMDA and Code Red was to write a quick little
script with the help of an actually clueful MCSE that ran through the
apache error.log every hour and used wget to try and exploit the
offending machine and wipe the drive. After a week of that, there
were only four or five machines left that would go down for a few
days, then start trying again for a few minutes until the top of the
hour hit and got wiped again. Those morons had to have been
reinstalling windows two or three times a week.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Jacob Anawalt
2003-09-23 20:20:56 UTC
Permalink
Post by Jeronimo Pellegrini
Post by Jacob Anawalt
I've already mentioned the web authorization idea and the rotate your
email address on some schedule ideas in another thread. I've even seen a
web site go so far as to use a .js file function to put together the email
address from a bunch of fragments when you click the mailto link. That
would take more work to parse, but it is still possible by having an email
grabbing webbot that can run javascript.
That would also break for people who use non-Javascript enabled
browsers.
Post by Jacob Anawalt
Another though I've had on the mailing list issues (besides wondering why
I'm trying to make mail act like a news client with threads and looking
for a 'watch thread' capable client) is if I had an email address to use
on mailing lists that only accepted email from the list servers I was on
and reject all others I should only get the spam that relayed through the
list.
Interesting. But managing that would require some energy from you...
If it requires less energy than maintaining my filters, it seems like a
gain to me.

See, when I replied and sent to you and the list you would have only
gotten one email ;)

Sorry about that. I realized after I clicked send that I forgot to replace
your email w/ the list's and drop the CC to the list.
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:29:06 UTC
Permalink
Post by Jeronimo Pellegrini
Interesting. But managing that would require some energy from you...
And not to mention becoming a pain in the ass for people trying to
correspond with you legitimately. Avoid doing anything that hinders
legitimate traffic, minimize the collateral damage if you have to.
Post by Jeronimo Pellegrini
Make the list server PGP-sign the messages, maybe? You install the list
server key once, and never worry about it again?
That's self-defeating for PGP. All PGP does is encryption and
verification of identity. Last I checked, murphy can't make it to
keysigning parties.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Karsten M. Self
2003-10-06 12:40:41 UTC
Permalink
Post by Paul Johnson
Post by Jeronimo Pellegrini
Make the list server PGP-sign the messages, maybe? You install the
list server key once, and never worry about it again?
That's self-defeating for PGP. All PGP does is encryption and
verification of identity. Last I checked, murphy can't make it to
keysigning parties.
If the spam scanning on murphy is sufficiently good, and the
listmaster's keys are both well-signed and used to sign murphey, you
might have cause to allow mail from the list to be passed as reliably
scanned, and trusted on the basis of your own GPG WoT.

Not entirely useless. Useful in its own context.

Peace.
--
Karsten M. Self <***@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Reject EU Software Patents! http://swpat.ffii.org/
Rich Puhek
2003-09-23 20:36:55 UTC
Permalink
(my reply is a bit disjointed, since I put things inline, and jumped
around while crafting my response...sorry for the nonlinear thinking
pattern)
Post by Jacob Anawalt
To me the big question is how do I avoid the spam in the first place,
besides avoiding email all together? I want to participate on the web, I
just don't want so much junk email nor do I want to have my mailbox or ISP
suffering from gigabytes of worm attachments or advertising data.
Your ISP should be filtering worms. It's fairly easy to do. If they
don't want to bother with setting up a virus filter, hard drive space is
fairly cheap. In addition, it would be nice if more ISPs filtered
outgoing email as well. That's not always practical, and it won't stop
the latest worms which sprechen SMTP, but it could help.
Post by Jacob Anawalt
We've all done or seen people do this: jacob at cachevalley dot com,
Are we kidding ourselves thinking that if we can write a filter rule that
just catches SoBig.[A-Z], that someone else can't turn all of those 'safe'
addresses back into the real email address?
Spammers don't really care either way... look to the dictionary attack
type of spammers for an example...("well, I've seen a
***@some.company.com, so let's try "***@cachevalley.com" as well).
The problem with turning a "safe" email address into a real one isn't a
big deal, it just protects against the "dumb" harvesters. It's like
using The Club on the steering wheel of your car... it won't defeat an
experienced car thief, but it may convince him to skip your vehicle.

In the case of a mailing list, I fail to see any advantage in the
obfuscation of your email address, since it's present in the header. The
exception would be private versus post-only addresses, as you mention below.
Post by Jacob Anawalt
I've already mentioned the web authorization idea and the rotate your
email address on some schedule ideas in another thread. I've even seen a
web site go so far as to use a .js file function to put together the email
address from a bunch of fragments when you click the mailto link. That
would take more work to parse, but it is still possible by having an email
grabbing webbot that can run javascript.
So it's just a slightly more complicated version of "jacob at cache
valley dot com".

What's more fun is making a website that creates endless lists of bogus
email addresses (like http://www.all-yours.net/scripts/killspam.htm) to
get address harvesters to puke.
Post by Jacob Anawalt
Another though I've had on the mailing list issues (besides wondering why
I'm trying to make mail act like a news client with threads and looking
for a 'watch thread' capable client) is if I had an email address to use
on mailing lists that only accepted email from the list servers I was on
and reject all others I should only get the spam that relayed through the
list.
The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.
So in practice, the idea would work something like the following?

1) Create a "Debian-user only" address, which you'd use for posting to
debian-user.
2) Email to the debian-user only address must come from the debian
mailing list, or I'm going to SMTP-reject it, since it's probably from a
spammer.
Post by Jacob Anawalt
If HELO does not match a reverse DNS lookup and doesn't match the domain
of RCPT TO: or to a user specified value then the mail is rejected.
In general, this will reject legit mail. In particular, sites that host
for more than one domain will not have a reverse DNS matching what you
might expect.

If only applied to a particular mailing-list, it might work, though.
Perhaps even IP address would be fine (debian-user-jacob emails must
come from a server with reverse DNS of murphy.debian.org). Note that you
cannot trust reverse DNS, though, so a forward lookup would also have to
be done.
Post by Jacob Anawalt
A looser match would be just on the HELO <name> where the name given is
some md5hash of the user's email address and some value noted on the
mailing list. People start getting spammed, the list admin changes the key
used to generate the name value and people go to the web to see what it
has been changed to.
So the MTA on the Debian mail server, for instance, would have to be
modified to generate a custom HELO for every message? This would really
hurt for larger sites which have more than one recipient to a mailing
list message...
Post by Jacob Anawalt
A tighter setup might be to have the hash in the MAIL FROM: <value> and
have it be a hash of the subscriber's list password and their email
address. That way the subscriber can change their list password at any
time they see spam coming “from” the list.
But for most mailing lists, MAIL FROM: is the sender's email address. To
change that would require modifying the mailing list software to break
the header, or modifying everyone's mail client. Again, this could get
ugly for sites with multiple subscribers to popular mailing lists.
Post by Jacob Anawalt
I'm sure there are other better ideas to be had along the lines of how to
quickly identify that the sending server is who they say they are and look
up a safe list to see if the user accepts email from that server.
For a dead simple solution, set up a subdomain like
@lists.cachevalley.com, and run a MTA dedicated to list traffic. Using
existing SMTP access control, deny all access except for the IP
addresses of servers you communicate with, and internal servers.

You could even whitelist additional entries, perhaps by automatically
scanning the mailing lists and (temporarily?) adding IP addresses of
recent posters.
Post by Jacob Anawalt
A side benefit of using an email address that only accepts list traffic
for some would be that it would reject the second email if someone replies
to you and the list. People using this setup could have their .sig say
"This email address only accepts authorized list traffic, please reply to
the list."
A simpler way is just make up something like
"jacob-debian-***@cachevalley.com" as an email alias for yourself.
Then, have procmail dump messages ^TO: that address into a folder,
unless they do not come from murphy.debian.org, or something like that.

You probably don't want to automatically delete them. You also probably
don't want to tie it into the MTA, just in case something breaks down
the line.
Post by Jacob Anawalt
Since we have seen that a greater volume of worm mail is possible with
email addresses usenet and mailing lists, it seems a setup based on this
system could help cut down the cost of fighting spam generated from those
sources. The rules would be based on a simple lists, with each user
responsible for maintaining their list. Much less CPU power, bandwidth and
storage space would be required to match those rules because the matching
is done before delivery is accepted. Mailing lists could publish to their
subscribe page the values they use for HELO and MAIL FROM when sending the
messages to all subscribers.
I'd differentiate between worms and spam more clearly. Worms/viruses are
fairly easy to keep up with, in that daily updates of your anti-virus
program will result in capturing virtually all viruses/worms with
virtually no false positives. Plus, you'll catch direct client to client
mail, instead of just mail to addresses harvested from mailing lists.
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new filter
rule that looks through the MIME data to decide if this is the latest worm
you don't want or the kissing picture that you do. Sure it's cool to be a
geek and figure out the rules. If you like doing this, do it. Maybe spam
isn't a cost to you but a benifit if you consider your enjoyment at
solving each filter puzzle. I think that's why I like finding bugs, to
help find and solve puzzles. On the other hand this method of filtering is
more expensive in every measure I can think of except the freedom of
allowing anyone to email you anytime. You spend time thinking up rules,
writing rules and testing rules. The rules are applied after you have
accepted the bandwidth of the transfer. Running the rules takes CPU time
and possibly more bandwidth as you do RBL DNS or Razor and storing the
email takes disk space.
Again, there's a big difference between catching worms and catching
spam. clamav's auto update ensures that my Amavis will catch just about
everything worm related.
Post by Jacob Anawalt
If you're sick of getting swamped (as a user or admin) wouldn't this setup
email addresses that are going to be used on usenet or public mailing
lists. The new email address could just dump into the real address after
the mailing list rules were validated, or it could be it's own account and
mailbox.
Of course some will say "but I only have my ISP available and it doesn't
do that" and others will say "I don't like that idea because it isn't easy
or flexible enough. I want email from everybody as long as it isn't
UCE/UBE/A worm or virus". That's why there isn't just one way to do
things, we all have different ideas on what is best.
Good point. Important to keep the differing needs in mind when dealing
with end users.
Post by Jacob Anawalt
One major concern that I've lightly touched on and will bring up again is
“What if I want to have other people contact me off list?” You wouldn't
want to post your non-list-only email to the list, that would be
counter-productive. There's got to be a convenient way of providing a
source for people to look up your email address that is very resistant to
scripting it's harvest for the UCE/worms/etc. One idea that comes to mind
are images of pictures with your email address on your web site. I keep
thinking that PGP/GPG should be able to help in some way, either by adding
to the EHLO command set or something on the users web site. There have to
be better and still simple ways of doing this that make it cost much more
to find our email addresses than it costs us to filter the junk.
True. But you still don't solve the problem of having someone easily
contact you off list. In the case of this email, I've decided I have
something worthwhile to say on the topic at hand (or I'm bored, and want
to babble about email filters...) so I hit "reply to all". If I had to
break my train of thought to sift through your website to find your
email address, I'm probably not going to bother. Also consider the fact
that some people do have to read email offline, and rely on the
assumption that all necessary contact info is contained in the email itself.

Enhancing EHLO would probably not be realistic, given that virtually all
email clients would have to implement it. It's like saying "oh, just
turn on SMTP authentication, and we can be sure that the sender isn't a
spammer, or at least can track them down".

Images with pictures of your email address is fine, but again, it's just
a slightly more difficult form of "jacob at cachevalley dot com"...
eventually wouldn't the spammers just create OCR software that looks for
email addresses in images on websites linked from your website?
Post by Jacob Anawalt
The sad part is that I've already squandered my username at this email
address by putting it where it can be harvested in mass by worm/virus and
UCE/UBE collection scripts, and I had already read an article cautioning
me against this. Oh well live and learn (someday I'll learn anyway.)
I'm going to look into setting up a new email address with mail server
rules for delivery driven by a user supplied whitelist after waiting a few
days for comments and flames on this idea. If you know of links to pages
already discussing how to do this with postfix, please share them.
Look to SpamAssassin. That will make a huge dent in your spam problem.
Tack on Amavis for the latest in MS malware, and you're in business. I
believe both integrate fairly well with Postfix.

Amavis is also able to reject viruses during the SMTP transaction. This
I would agree with, if your configuration allows it.

Some good thoughts there... but I wonder just how many mailing lists
would need to apply such a solution to make an impact, and how difficult
it would be to apply. OTOH, you might find better results with simpler
methods...


--Rich

_________________________________________________________

Rich Puhek
ETN Systems Inc.
2125 1st Ave East
Hibbing MN 55746

tel: 218.262.1130
email: ***@etnsystems.com
_________________________________________________________
Jacob Anawalt
2003-09-23 22:32:12 UTC
Permalink
Post by Rich Puhek
(my reply is a bit disjointed, since I put things inline, and jumped
around while crafting my response...sorry for the nonlinear thinking
pattern)
'sOK. I thought you had some good points. Thanks for the input. Inline is
just right for me.
Post by Rich Puhek
Post by Jacob Anawalt
To me the big question is how do I avoid the spam in the first place,
besides avoiding email all together? I want to participate on the web, I
just don't want so much junk email nor do I want to have my mailbox or ISP
suffering from gigabytes of worm attachments or advertising data.
Your ISP should be filtering worms. It's fairly easy to do. If they
don't want to bother with setting up a virus filter, hard drive space is
fairly cheap. In addition, it would be nice if more ISPs filtered
outgoing email as well. That's not always practical, and it won't stop
the latest worms which sprechen SMTP, but it could help.
I don't want to spend CPU cycles, bandwidth or disk space scanning the
DATA section of an SMTP transfer or post-reciept scanning to determine if
it's mail I want in my inbox. (1)

How is the ISP filtering the mail if not by giving 250 OK to HELO, MAIL
FROM: and RCPT TO: and entering into the DATA section.
Post by Rich Puhek
Post by Jacob Anawalt
We've all done or seen people do this: jacob at cachevalley dot com,
Are we kidding ourselves thinking that if we can write a filter rule that
just catches SoBig.[A-Z], that someone else can't turn all of those 'safe'
addresses back into the real email address?
Spammers don't really care either way... look to the dictionary attack
type of spammers for an example...("well, I've seen a
The problem with turning a "safe" email address into a real one isn't a
big deal, it just protects against the "dumb" harvesters. It's like
using The Club on the steering wheel of your car... it won't defeat an
experienced car thief, but it may convince him to skip your vehicle.
In the case of a mailing list, I fail to see any advantage in the
obfuscation of your email address, since it's present in the header. The
exception would be private versus post-only addresses, as you mention below.
Yes, and ***@cachevalley.com would be as weak as
***@lists.cachevalley.com under your very valid point.
***@cachevalley.com would be much better for my usenet/mailing
list address. Of course my real email will get spam because jacob is
common enough to try while running the gauntlet of admin, postmaster and
webmaster for viagra adds, so I need to stop accepting email on that
account and get a new alias for normal email, but my personal mail spam
isn't the issue I'm focusing on. I'm looking for solutions to spam to
email that went out to usenet or mailing lists.

[snip]
Post by Rich Puhek
Post by Jacob Anawalt
Another though I've had on the mailing list issues (besides wondering why
I'm trying to make mail act like a news client with threads and looking
for a 'watch thread' capable client) is if I had an email address to use
on mailing lists that only accepted email from the list servers I was on
and reject all others I should only get the spam that relayed through the
list.
The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.
So in practice, the idea would work something like the following?
1) Create a "Debian-user only" address, which you'd use for posting to
debian-user.
2) Email to the debian-user only address must come from the debian
mailing list, or I'm going to SMTP-reject it, since it's probably from a
spammer.
Exactly. Mostly. I'd like a "mailing list only" address that accepts mail
only from the lists I select.
Post by Rich Puhek
Post by Jacob Anawalt
If HELO does not match a reverse DNS lookup and doesn't match the domain
of RCPT TO: or to a user specified value then the mail is rejected.
In general, this will reject legit mail. In particular, sites that host
for more than one domain will not have a reverse DNS matching what you
might expect.
If only applied to a particular mailing-list, it might work, though.
Perhaps even IP address would be fine (debian-user-jacob emails must
come from a server with reverse DNS of murphy.debian.org). Note that you
cannot trust reverse DNS, though, so a forward lookup would also have to
be done.
Forward and reverse. OK.

Under my definition of valid email as "Valid email for this address is
_only_ email from the debian-users list" would this drop valid email?
Post by Rich Puhek
Post by Jacob Anawalt
A looser match would be just on the HELO <name> where the name given is
some md5hash of the user's email address and some value noted on the
mailing list. People start getting spammed, the list admin changes the key
used to generate the name value and people go to the web to see what it
has been changed to.
So the MTA on the Debian mail server, for instance, would have to be
modified to generate a custom HELO for every message? This would really
hurt for larger sites which have more than one recipient to a mailing
list message...
Post by Jacob Anawalt
A tighter setup might be to have the hash in the MAIL FROM: <value> and
have it be a hash of the subscriber's list password and their email
address. That way the subscriber can change their list password at any
time they see spam coming “from” the list.
But for most mailing lists, MAIL FROM: is the sender's email address. To
change that would require modifying the mailing list software to break
the header, or modifying everyone's mail client. Again, this could get
ugly for sites with multiple subscribers to popular mailing lists.
Debian-user is auto-generating the MAIL FROM: to create the per-user
bounce path.

Return-Path: <bounce-debian-user=jacob=***@lists.debian.org>

I didn't think if that was possible it would be a stretch to do the same
for HELO/EHLO or to use some md5 hash instead of my email address.

So people don't take this out of context, I am not saying the deiban mail
server has to change. DNS works for Debian stuff so I think I'm set there.
I'm just pointing out possible ideas for other mailing lists that don't
have reverse dns or for better security against dns or ip spoofing.

I do believe the Debian list server could use more help. The more spam it
has to fight the slower it will be without donations to upgrade bandwidth
and CPU, unless we can find a better solution - but that's a topic for a
different thread.
Post by Rich Puhek
Post by Jacob Anawalt
I'm sure there are other better ideas to be had along the lines of how to
quickly identify that the sending server is who they say they are and look
up a safe list to see if the user accepts email from that server.
For a dead simple solution, set up a subdomain like
@lists.cachevalley.com, and run a MTA dedicated to list traffic. Using
existing SMTP access control, deny all access except for the IP
addresses of servers you communicate with, and internal servers.
Simple is good. That is where I may start. As mentioned above my email
Post by Rich Puhek
You could even whitelist additional entries, perhaps by automatically
scanning the mailing lists and (temporarily?) adding IP addresses of
recent posters.
I like the safe listing of some posters idea and had it in mind, but then
the thought of knowing they weren't spoofed by someone else or their ip is
dynamic came to mind. By the comments I've seen from some posters about
how they feel towards people who email them off-list, they may not want
individual poster safe listing.
Post by Rich Puhek
Post by Jacob Anawalt
A side benefit of using an email address that only accepts list traffic
for some would be that it would reject the second email if someone replies
to you and the list. People using this setup could have their .sig say
"This email address only accepts authorized list traffic, please reply to
the list."
A simpler way is just make up something like
Then, have procmail dump messages ^TO: that address into a folder,
unless they do not come from murphy.debian.org, or something like that.
You probably don't want to automatically delete them. You also probably
don't want to tie it into the MTA, just in case something breaks down
the line.
I'm happy with procmail and would use it to put X list into IMAP folder X.
It is a post-delivery mechanism though so not what I'm after for reducing
the spam in the first place.

I would be much happier with a SMTP message to the sender at the start of
the SMTP traffic. I'm not going to be deleting the email, I'm going to be
sending a reply that says "550 5.7.1 This email doesn't exist for anyone
but authorized mailing lists."

http://www.faqs.org/rfcs/rfc1893.html
Post by Rich Puhek
Post by Jacob Anawalt
Since we have seen that a greater volume of worm mail is possible with
email addresses usenet and mailing lists, it seems a setup based on this
system could help cut down the cost of fighting spam generated from those
sources. The rules would be based on a simple lists, with each user
responsible for maintaining their list. Much less CPU power, bandwidth and
storage space would be required to match those rules because the matching
is done before delivery is accepted. Mailing lists could publish to their
subscribe page the values they use for HELO and MAIL FROM when sending the
messages to all subscribers.
I'd differentiate between worms and spam more clearly. Worms/viruses are
fairly easy to keep up with, in that daily updates of your anti-virus
program will result in capturing virtually all viruses/worms with
virtually no false positives. Plus, you'll catch direct client to client
mail, instead of just mail to addresses harvested from mailing lists.
Same deal, this is post-DATA or post delivery 250 OK solution. Not what
I'd like.

If my email address on this list didn't accept email from anyone but this
list then all the direct worm spam that happened the past few days would
have had much less of an impact in terms of bandwidth and disk space for
me.

Throw in some teergrubing and I can assist the community by slowing the
spammer down. That wasn't my goal though.

We (people with email available via usenet) were getting swamped with worm
generated messages. I was getting the same email from thousands of
individual computers. Maybe this is a bad knee-jerk solution to this. I'll
happily entertain other solutions. This worm will eventually be patched
and go away, but others will come.
Post by Rich Puhek
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new filter
rule that looks through the MIME data to decide if this is the latest worm
you don't want or the kissing picture that you do. Sure it's cool to be a
geek and figure out the rules. If you like doing this, do it. Maybe spam
isn't a cost to you but a benifit if you consider your enjoyment at
solving each filter puzzle. I think that's why I like finding bugs, to
help find and solve puzzles. On the other hand this method of filtering is
more expensive in every measure I can think of except the freedom of
allowing anyone to email you anytime. You spend time thinking up rules,
writing rules and testing rules. The rules are applied after you have
accepted the bandwidth of the transfer. Running the rules takes CPU time
and possibly more bandwidth as you do RBL DNS or Razor and storing the
email takes disk space.
Again, there's a big difference between catching worms and catching
spam. clamav's auto update ensures that my Amavis will catch just about
everything worm related.
Ditto again on post DATA.


[snip]
Post by Rich Puhek
Post by Jacob Anawalt
One major concern that I've lightly touched on and will bring up again is
“What if I want to have other people contact me off list?” You wouldn't
want to post your non-list-only email to the list, that would be
counter-productive. There's got to be a convenient way of providing a
source for people to look up your email address that is very resistant to
scripting it's harvest for the UCE/worms/etc. One idea that comes to mind
are images of pictures with your email address on your web site. I keep
thinking that PGP/GPG should be able to help in some way, either by adding
to the EHLO command set or something on the users web site. There have to
be better and still simple ways of doing this that make it cost much more
to find our email addresses than it costs us to filter the junk.
True. But you still don't solve the problem of having someone easily
contact you off list. In the case of this email, I've decided I have
something worthwhile to say on the topic at hand (or I'm bored, and want
to babble about email filters...) so I hit "reply to all". If I had to
break my train of thought to sift through your website to find your
email address, I'm probably not going to bother. Also consider the fact
that some people do have to read email offline, and rely on the
assumption that all necessary contact info is contained in the email itself.
Enhancing EHLO would probably not be realistic, given that virtually all
email clients would have to implement it. It's like saying "oh, just
turn on SMTP authentication, and we can be sure that the sender isn't a
spammer, or at least can track them down".
Images with pictures of your email address is fine, but again, it's just
a slightly more difficult form of "jacob at cachevalley dot com"...
eventually wouldn't the spammers just create OCR software that looks for
email addresses in images on websites linked from your website?
You're right. You'll reply to all, and the message to me will bounce. I
miss out on the conversation. That's my loss, or your frustration because
things weren't easy for you if you really needed to talk to me off list.

Same argument goes for me not answering the phone when someone who hates
answering machines calls me. We're two Zaks waiting for the other to
yield. I say my phone is for my conveniance and you say it is for yours. I
don't want to answer my phone because 90% of the time it's a solicitor and
you want me to answer because you know you're not a solicitor.

http://www.eg.bucknell.edu/~cs315/subpages/inline/Zax.html

I agree that EHLO for keys may not be realistic. Maybe as IPsec grows in
usership oppertunistic ipsec may help out here.

Having spam harvesters doing OCR on a miriad of pictures (maybe mine is of
my car with my email at the top and yours is of your bike with the email
at the bottom) will cost them a lot more to process than it is now, and
may cost more than it costs you to filter spam.

Still you have a good point that it is still possible to get and that
people will probably hate me for requiring them to look my email up on the
web. I'm not saying images are the solution. I'm looking for one. One that
can be transfered via text in the email but is difficult (on the order of
doing OCR) to determine the address would be nice. As soon as everyone
starts doing it, people will find a way to crack it.
Post by Rich Puhek
Post by Jacob Anawalt
The sad part is that I've already squandered my username at this email
address by putting it where it can be harvested in mass by worm/virus and
UCE/UBE collection scripts, and I had already read an article cautioning
me against this. Oh well live and learn (someday I'll learn anyway.)
I'm going to look into setting up a new email address with mail server
rules for delivery driven by a user supplied whitelist after waiting a few
days for comments and flames on this idea. If you know of links to pages
already discussing how to do this with postfix, please share them.
Look to SpamAssassin. That will make a huge dent in your spam problem.
Tack on Amavis for the latest in MS malware, and you're in business. I
believe both integrate fairly well with Postfix.
Amavis is also able to reject viruses during the SMTP transaction. This
I would agree with, if your configuration allows it.
I currently reject dos/win executables during the SMTP DATA transaction
via postfix body_checks. For all valid email I'm scanning the whole
message every time so that I might catch the ones that are invalid
(postfix 1.0).
Post by Rich Puhek
Some good thoughts there... but I wonder just how many mailing lists
would need to apply such a solution to make an impact, and how difficult
it would be to apply. OTOH, you might find better results with simpler
methods...
Well for the Debian list, they don't have to do a thing for me to
implement my idea. It's all on my end since their DNS is right. For other
lists I see sending the hash of "youremail+listpasswd" @somelistserver.net
where they use a mailing list that has a password already as not that big
a deal, as long as the list process does outgoing smtp itself.

If I change my email, only subscribe to debian-user and use this system,
then wouldn't there be an immediate impact on my experiance? It's all
about me afterall ;). If others wanted to do the same thing to avoid
usenet/list collected email attacks then they can benefit (and miss out)
as well.

I think that an important problem to solve is comming up with a good way
of getting people your email if they want it (and if you want them to have
it) without making it easily accessable by a simple text parsing script. I
want them to have to have GnuPG, guile, perl, and OCR in their harvesting
program. ;)
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:43:49 UTC
Permalink
Post by Rich Puhek
1) Create a "Debian-user only" address, which you'd use for posting to
debian-user.
2) Email to the debian-user only address must come from the debian
mailing list, or I'm going to SMTP-reject it, since it's probably from a
spammer.
3) Spammer sends to debian-***@lists.debian.org and defeats your effort.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Arnt Karlsen
2003-09-24 00:41:27 UTC
Permalink
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this is the
latest worm you don't want or the kissing picture that you do. Sure
it's cool to be a geek and figure out the rules. If you like doing
this, do it.
..another option is "blow up the road": http://www.ordb.org/submit/
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Jacob Anawalt
2003-09-24 04:06:19 UTC
Permalink
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this is the
latest worm you don't want or the kissing picture that you do. Sure
it's cool to be a geek and figure out the rules. If you like doing
this, do it.
..another option is "blow up the road": http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about as dumb
an idea as blowing up the road to your house", but then after seeing the
link was to their open relay form, I was stumped.

Do you mind shedding some more light on this for me if you were not
trying to be light hearted? Thanks.

--
Jacob
Arnt Karlsen
2003-09-24 11:52:30 UTC
Permalink
On Tue, 23 Sep 2003 22:06:19 -0600,
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this is
the latest worm you don't want or the kissing picture that you do.
Sure it's cool to be a geek and figure out the rules. If you like
doing this, do it.
..another option is "blow up the road": http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about as
dumb an idea as blowing up the road to your house", but then after
seeing the link was to their open relay form, I was stumped.
Do you mind shedding some more light on this for me if you were not
trying to be light hearted? Thanks.
..why spoil the fun? ;-) Spam etc needs relaying "roads" to travel
to your box. ORDB also accepts email reports rather than this, uh,
"massive" web form, and I would think mailfilter or fetchmail or
somesuch can be a workable source for a mailto pipe.

..a third idea is a to "first check if the same spam relay has been
reported by someone else", ORDB has a 200 host report cap, and
reporting the same box half a bazillion times a day would just DOS
ORDB, which is not quite what we wanna do. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Mark Maas
2003-09-24 14:01:43 UTC
Permalink
----- Original Message -----
From: "Arnt Karlsen" <***@c2i.net>
To: <debian-***@lists.debian.org>
Sent: Wednesday, September 24, 2003 1:52 PM
Subject: Re: Anti-Spam ideas for usenet/list harvested email addresses
Post by Arnt Karlsen
On Tue, 23 Sep 2003 22:06:19 -0600,
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this is
the latest worm you don't want or the kissing picture that you do.
Sure it's cool to be a geek and figure out the rules. If you like
doing this, do it.
..another option is "blow up the road": http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about as
dumb an idea as blowing up the road to your house", but then after
seeing the link was to their open relay form, I was stumped.
Do you mind shedding some more light on this for me if you were not
trying to be light hearted? Thanks.
..why spoil the fun? ;-) Spam etc needs relaying "roads" to travel
to your box. ORDB also accepts email reports rather than this, uh,
"massive" web form, and I would think mailfilter or fetchmail or
somesuch can be a workable source for a mailto pipe.
..a third idea is a to "first check if the same spam relay has been
reported by someone else", ORDB has a 200 host report cap, and
reporting the same box half a bazillion times a day would just DOS
ORDB, which is not quite what we wanna do. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
best case, worst case, and just in case.
May I also point out the following idea:
http://lists.debian.org/debian-user/2002/debian-user-200201/msg03119.html

I think that would make things easier to report spam...

Just a FYI.
Mark
Arnt Karlsen
2003-09-24 20:27:35 UTC
Permalink
On Wed, 24 Sep 2003 16:01:43 +0200,
Post by Mark Maas
----- Original Message -----
Sent: Wednesday, September 24, 2003 1:52 PM
Subject: Re: Anti-Spam ideas for usenet/list harvested email addresses
Post by Arnt Karlsen
On Tue, 23 Sep 2003 22:06:19 -0600,
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this
is the latest worm you don't want or the kissing picture that
you do. Sure it's cool to be a geek and figure out the rules. If
you like doing this, do it.
http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about
as dumb an idea as blowing up the road to your house", but then
after seeing the link was to their open relay form, I was stumped.
Do you mind shedding some more light on this for me if you were
not trying to be light hearted? Thanks.
..why spoil the fun? ;-) Spam etc needs relaying "roads" to travel
to your box. ORDB also accepts email reports rather than this, uh,
"massive" web form, and I would think mailfilter or fetchmail or
somesuch can be a workable source for a mailto pipe.
..a third idea is a to "first check if the same spam relay has been
reported by someone else", ORDB has a 200 host report cap, and
reporting the same box half a bazillion times a day would just DOS
ORDB, which is not quite what we wanna do. ;-)
http://lists.debian.org/debian-user/2002/debian-user-200201/msg03119.html
I think that would make things easier to report spam...
..you either lost me here or you're the dog chasing cars:
I propose automating the reporting of spam _relays_. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Jacob Anawalt
2003-09-24 21:20:09 UTC
Permalink
Post by Arnt Karlsen
On Tue, 23 Sep 2003 22:06:19 -0600,
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a new
filter rule that looks through the MIME data to decide if this is
the latest worm you don't want or the kissing picture that you do.
Sure it's cool to be a geek and figure out the rules. If you like
doing this, do it.
..another option is "blow up the road": http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about as
dumb an idea as blowing up the road to your house", but then after
seeing the link was to their open relay form, I was stumped.
Do you mind shedding some more light on this for me if you were not
trying to be light hearted? Thanks.
..why spoil the fun? ;-) Spam etc needs relaying "roads" to travel
to your box. ORDB also accepts email reports rather than this, uh,
"massive" web form, and I would think mailfilter or fetchmail or
somesuch can be a workable source for a mailto pipe.
Doesn't some spam come directly from an individual running SMTP from their
box to yours? I'm pretty sure this is the case for the W32/***@MM's email
spreading methods.
Post by Arnt Karlsen
..a third idea is a to "first check if the same spam relay has been
reported by someone else", ORDB has a 200 host report cap, and
reporting the same box half a bazillion times a day would just DOS
ORDB, which is not quite what we wanna do. ;-)
A bitter irony is that we aren't using anything like ORDB to stop email
because others users don't trust it to not block email they want to get.
They heard stories about occasional blockings of places like AOL, and they
have friends set on using those ISP's.

I'm going to try the suggestions I've seen on the list by running S/A on
one domain. Maybe I can show the other users that it will be OK to use RBL
filtering of email. I like the ideas I've read on having S/A trigger
firewall rules for obvious spam.

Still I'd like to find some better way of sharing my email address without
feeling obligated to process all email sent to me in full. If there is a
good way of doing this, it would help not just my situation but also users
who like to post to lists and usenet but have no control over how their
ISP handles email and who have limited bandwidth or quotas on their
traffic. If many of these users were all on the same mail system, that
mail server would benefit by not processing the DATA of list/usenet
trolled spam/worm SMTP traffic.

Maybe rotating email addresses is the only way. That puts almost all of
the burden of spam prevention on my end without any special hoops for
others to jump through and once I close an account the SMTP server gets to
reject at the RCPT TO: stage.

Someone looking at an old message and trying to use the old email to
contact me would get a bounce. Hopefully I could minimize even this
inconveniance by having an overlap of some reasonable time frame between
opening the new account and closing the old one, and I forward all email
from the old to the new until the old is closed.

Maybe I could even coordinate OpenPGP sub keys used to sign my
coorispondance to expire on some interval, and my .sig could say "If the
public subkey for this digital signature is revoked or expired, I've
changed email addresses."

Any rants on how inconveniant those methods would be if they wanted to be
nice enough email me? :)

Next month's news: "A new email worm that attacks only users of OpenPGP
key servers by pulling down their public keys and emailing all their
identities." *sigh*

I'll keep trying things and if I get some more mail server side wild
(possibly bad) ideas, I'll post it to the debian-isp list.
--
Jacob
Trying out SquirrelMail
Daniel L. Miller
2003-09-24 22:57:37 UTC
Permalink
Post by Jacob Anawalt
Doesn't some spam come directly from an individual running SMTP from
their box to yours? I'm pretty sure this is the case for the
I have exactly this configuration. Our e-mail is hosted off-site on
another server, but I have configured an Postfix server to send all our
outgoing mail. Is there a "proper" way I should configure our internal
server and/or domain registration so we don't appear to be a spammer -
since a reverse lookup would fail and my internal SMTP server does not
accept mail at this time?

Daniel
Jacob Anawalt
2003-09-25 00:13:04 UTC
Permalink
Post by Daniel L. Miller
Post by Jacob Anawalt
Doesn't some spam come directly from an individual running SMTP from
their box to yours? I'm pretty sure this is the case for the
I have exactly this configuration. Our e-mail is hosted off-site on
another server, but I have configured an Postfix server to send all our
outgoing mail. Is there a "proper" way I should configure our internal
server and/or domain registration so we don't appear to be a spammer -
since a reverse lookup would fail and my internal SMTP server does not
accept mail at this time?
While I can wish all I want that outgoing and incomming SMTP will map to
vaild MX records, as far as I know it isn't required to have outgoing
traffic map have a MX DNS record. It sounds like the off-site server is
your MX server.

I'm going to guess that this is for amfes.com.

MX 5=smtpav.wpdbiz.com = 66.238.186.13.
MX 10 = smtp.amfes.com = 66.238.186.115.

You could relay all your mail through them if they have a good smarthost,
but it isn't required. I did notice that on this email, your mail server
identifies itself with the local network instead of afes.com:

mail.amfeslan.local -> 67.106.235.126.ptr.us.xo.net [67.106.235.126]

There is a reverse DNS IP, it just isn't owned by amfes or named to
amfes.com and XO Communications doesn't want to or wasn't asked to have
that reverse dns record say gw.amfes.com. The system I'm mailing from
doesn't have the domain name's reverse dns on it. It did for a few months,
but then our ISP changed some policies or something and changed them all
again because it was easier on them.

It's not necessary to send email to have reverse DNS of afes.com for your
IP. Lots of systems dont have 'perfect' reverse dns. The name your gateway
mailserver is using doesn't resolve to anything useful by people outside
of your lan. If you control your DNS you could at least have the forward
dns point to gw.afes.com or some afes.com name and then have postfix on
mail.amfeslan.local put that <name>.afes.com value for $hostname.

The best way to avoid being called a spammer is to make sure spam doesn't
leave your system by not relaying for other networks, and watching
outgoing email for spam - especialy from viruses. Since you only accept
outgoing mail, your rules can be even stricter. You can reject all
incoming mail except postmaster and abuse. Maybe you can even reject them
since technically you have a valid MX record to recieve mail on a
different machine.

You may want to subscribe to or search the web on debian-isp to keep
informed of other issues. I only started this thread here because the
affects of Swen on people who posted to debian-user.
--
Jacob
SquirrelMail - Webmail for Nuts
Arnt Karlsen
2003-09-25 00:50:21 UTC
Permalink
On Wed, 24 Sep 2003 15:20:09 -0600 (MDT),
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 22:06:19 -0600,
Post by Jacob Anawalt
Post by Arnt Karlsen
On Tue, 23 Sep 2003 13:16:38 -0600 (MDT),
Post by Jacob Anawalt
Compare this to the "dog chasing cars" method of inventing a
new filter rule that looks through the MIME data to decide if
this is the latest worm you don't want or the kissing picture
that you do. Sure it's cool to be a geek and figure out the
rules. If you like doing this, do it.
http://www.ordb.org/submit/
I laughed at this at first, taking it as a "Jacob, this is about
as dumb an idea as blowing up the road to your house", but then
after seeing the link was to their open relay form, I was stumped.
Do you mind shedding some more light on this for me if you were
not trying to be light hearted? Thanks.
..why spoil the fun? ;-) Spam etc needs relaying "roads" to travel
to your box. ORDB also accepts email reports rather than this, uh,
"massive" web form, and I would think mailfilter or fetchmail or
somesuch can be a workable source for a mailto pipe.
Doesn't some spam come directly from an individual running SMTP from
their box to yours? I'm pretty sure this is the case for the
..dunno, it's all in /dev/null ;-) , but most of the other spam comes
directly to my pop3 service provider, but there is some that has more
hops. These hops is IMNTHO ORDB fodder, and these relays deserve it.

..the "direct smtp'ers" uses someones "cracked wintendo on fat pipe"
which needs to be stomped flat, and the fat-piper isp's needs to know
where to stomp.
Post by Jacob Anawalt
Post by Arnt Karlsen
..a third idea is a to "first check if the same spam relay has been
reported by someone else", ORDB has a 200 host report cap, and
reporting the same box half a bazillion times a day would just DOS
ORDB, which is not quite what we wanna do. ;-)
A bitter irony is that we aren't using anything like ORDB to stop
email because others users don't trust it to not block email they want
to get. They heard stories about occasional blockings of places like
AOL, and they have friends set on using those ISP's.
...with sloppy mail host admins that could use some flogging around.
Post by Jacob Anawalt
I'm going to try the suggestions I've seen on the list by running S/A
on one domain. Maybe I can show the other users that it will be OK to
use RBL filtering of email. I like the ideas I've read on having S/A
trigger firewall rules for obvious spam.
Still I'd like to find some better way of sharing my email address
without feeling obligated to process all email sent to me in full. If
there is a good way of doing this, it would help not just my situation
but also users who like to post to lists and usenet but have no
control over how their ISP handles email and who have limited
bandwidth or quotas on their traffic. If many of these users were all
on the same mail system, that mail server would benefit by not
processing the DATA of list/usenet trolled spam/worm SMTP traffic.
.._take_ that control: Reporting open relays "blows up the road",
by _making_ sloppy isp's do some work to get their boxes outta that
baaad isp list.

..my scheme can also be extended to report "slow stompers", if
their _paying_ clientele is denied access, these will take that
internet business they pay for, _elsewhere_.
Post by Jacob Anawalt
Maybe rotating email addresses is the only way. That puts almost all
of the burden of spam prevention on my end without any special hoops
for others to jump through and once I close an account the SMTP server
gets to reject at the RCPT TO: stage.
Someone looking at an old message and trying to use the old email to
contact me would get a bounce. Hopefully I could minimize even this
inconveniance by having an overlap of some reasonable time frame
between opening the new account and closing the old one, and I forward
all email from the old to the new until the old is closed.
Maybe I could even coordinate OpenPGP sub keys used to sign my
coorispondance to expire on some interval, and my .sig could say "If
the public subkey for this digital signature is revoked or expired,
I've changed email addresses."
Any rants on how inconveniant those methods would be if they wanted to
be nice enough email me? :)
..strikes me as "you wanna duck", and it will not harm the spammers,
nor their sloppy or co-operating isp's. We need the "dogs chasing
the cars" for that number one new spam/worm etc, (O)(P)GP(G) is all
nice and could become a part of a C-R scheme, but it does not stop
the "dog chased cars" DDOS'ing you off the net. That stop bit still
needs the pipe stomp.
Post by Jacob Anawalt
Next month's news: "A new email worm that attacks only users of
OpenPGP key servers by pulling down their public keys and emailing all
their identities." *sigh*
..those worms still needs relays or cracked-wintendo-on-fat-pipe-hosts.
Post by Jacob Anawalt
I'll keep trying things and if I get some more mail server side wild
(possibly bad) ideas, I'll post it to the debian-isp list.
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
daniel
2003-09-25 01:30:29 UTC
Permalink
I found a nice web page which can give postfix mail admins some nice
tips to block most incoming spam/mail bombs.

I added most of the checking described in this url plus a 100Kb mail
limit since nobody sends me more than that.

Before I could be receiving 10 spam and/or mail bombs per 5 min.. now
per 5 min. I am receiving none.. Im anxious to check how many do I
receive tomorrow...

This is the link - http://www.wsrcc.com/spam/
--
-daniel
http://www.debian-gnu.com
Jacob Anawalt
2003-09-25 17:15:09 UTC
Permalink
Post by daniel
I found a nice web page which can give postfix mail admins some nice
tips to block most incoming spam/mail bombs.
I added most of the checking described in this url plus a 100Kb mail
limit since nobody sends me more than that.
Before I could be receiving 10 spam and/or mail bombs per 5 min.. now
per 5 min. I am receiving none.. Im anxious to check how many do I
receive tomorrow...
This is the link - http://www.wsrcc.com/spam/
Thanks for the link, looks pretty sensible in their setup. I don't think
this rule is a good idea:

http://www.wsrcc.com/spam/bounce.html
[quote]
550 Client host rejected: cannot find your hostname, [168.126.3.59];

Here the sending site's DNS administrator forgot to put the name of the
host into the DNS system at all. Our system has no way to tell the name of
your host. This is probably the most common mistake.

There are two places the DNS administrator has to enter the information
for each host. One, the so called "forward mapping" maps the hostname to
IP address. Two, the "reverse mapping" maps the IP address to the
hostname. Both of these mappings have to agree for our host to believe the
information it gets.
[/quote]

This will reject email from many vaild and well managed mail servers who
aren't able to buy their own ip block or get an ISP who will do
reverse-dns for their mail servers.
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:47:55 UTC
Permalink
Post by Arnt Karlsen
..another option is "blow up the road": http://www.ordb.org/submit/
bl.spamcop.net is a bit more up to date with less collateral damage.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Jacob Anawalt
2003-09-26 03:13:57 UTC
Permalink
Jacob Anawalt said:
[snip]
Post by Jacob Anawalt
One major concern that I've lightly touched on and will bring up again is
“What if I want to have other people contact me off list?” You wouldn't
want to post your non-list-only email to the list, that would be
counter-productive. There's got to be a convenient way of providing a
source for people to look up your email address that is very resistant to
scripting it's harvest for the UCE/worms/etc. One idea that comes to mind
are images of pictures with your email address on your web site. I keep
thinking that PGP/GPG should be able to help in some way, either by adding
to the EHLO command set or something on the users web site. There have to
be better and still simple ways of doing this that make it cost much more
to find our email addresses than it costs us to filter the junk.
[snip]

I'm still thinking that an email address that only recieves email from the
list is a possible solution for those who have control over mailserver
settings, or rotating email addresses when the spam hits the fan for those
who dont.


My current wild though is this, I find my old gpg private key (or make a
new one if I can't find it or it has this email address) and start signing
stuff. I have the list only address that I use to reply to the list and
recieve from the list, but if gpg savy people really want to talk to me,
they look up my email in my public key. I could even hint in my .sig that
if you need to talk to me, look at my public key.

Either it will be too hard for people to do, or it catches on and viruses
ship with gpg embeded. :)
--
Jacob
Trying out SquirrelMail
Paul Johnson
2003-09-26 08:26:14 UTC
Permalink
Post by Jacob Anawalt
To me the big question is how do I avoid the spam in the first place,
besides avoiding email all together?
Become an extremely hostile target. Report all mail and news abuse
ASAP. http://spamcop.net/ and http://www.abuse.net/ are both
excellent resources for getting ahold of admins.

If you run your own mail server, exim has excellent controls for
curbing spam. exim4 and sa-exim work beautifully together. I'd love
to know how to get clamav to work, maybe this would be a good feature
for sa-exim.
Post by Jacob Anawalt
We've all done or seen people do this: jacob at cachevalley dot com,
Munging considered harmful.
http://www.interhack.net/pubs/munging-harmful
Post by Jacob Anawalt
I've already mentioned the web authorization idea and the rotate your
email address on some schedule ideas in another thread.
Challenge-response considered harmful, read the archives. Rotating
your email address is another great way to lose legitimate email
without affecting the problem itself.
Post by Jacob Anawalt
I've even seen a web site go so far as to use a .js file function to
put together the email address from a bunch of fragments when you
click the mailto link. That would take more work to parse, but it is
still possible by having an email grabbing webbot that can run
javascript.
Not to mention break the functionality for people who do not have JS
capable browsers.
Post by Jacob Anawalt
The mail server would need to have access to my personal list of
acceptable email addresses so it could give a 550 with the appropriate
extended SMTP code for unauthorized/security and an appropriate error
message after the HELO and MAIL FROM and RCPT TO: have been given. It
should only do this for mail accounts that have entries in the safe list.
If your list is empty, all email is valid. If you have one or more
entries, only those ones can send you email.
spamassassin does something similar with sa-exim.
Post by Jacob Anawalt
If you're sick of getting swamped (as a user or admin) wouldn't this setup
email addresses that are going to be used on usenet or public mailing
lists. The new email address could just dump into the real address after
the mailing list rules were validated, or it could be it's own account and
mailbox.
Variation on munging...
Post by Jacob Anawalt
The sad part is that I've already squandered my username at this email
address by putting it where it can be harvested in mass by worm/virus and
UCE/UBE collection scripts, and I had already read an article cautioning
me against this. Oh well live and learn (someday I'll learn anyway.)
I've had this email address for about a year, and before that, I had
***@ursine.dyndns.org for about 6 years before a buddy bought me a
Canadian domain name for me. Don't hide, *TAKE ACTION*.

- --
.''`. Paul Johnson <***@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
Pigeon
2003-09-26 15:19:09 UTC
Permalink
Post by Paul Johnson
Post by Jacob Anawalt
To me the big question is how do I avoid the spam in the first place,
besides avoiding email all together?
Become an extremely hostile target. Report all mail and news abuse
ASAP. http://spamcop.net/ and http://www.abuse.net/ are both
excellent resources for getting ahold of admins.
I do wonder a bit about spamcop... I don't know if this is
coincidental, but after I started using it I began to get less spam,
then the spam rates started creeping up again - with a different
distribution; more Nigerian scams, and more spams from .cn and .pk
domains of which spamcop says "these lot won't listen to us". I wonder
if spammers whose ISPs and/or countries' legal systems don't give a
rat's ass about spamming simply use spamcop reports as confirmation of
a valid email address...
--
Pigeon

Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Michael C.
2003-09-26 22:12:39 UTC
Permalink
In linux.debian.user,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Ray
it seems to me the easiest solution would be for ISPs to have a
policy and software that supported the policy of no .exe .com .src
.pif .bat (etc...) attachments. any email will either be dropped or
have the attachment dropped and replaced with a short explination of
it being against policy and how to make a zip/gz/tar/whatever file if
they really want to send a .exe
That's exactly what we want to do: force the user to open a tarball to
figure out what's up. 8:oP Worm writers *will* adapt to this.
The problem is that the preview pane runs them automatically, If the
file has to be handled at any point such as unzipping a file (Many
windows users have no clue what a tar file is, and there's no reason
they should.) it usually breaks the chain. I believe MS started
defaulting to no executable by default a few viruses ago, with the
option to turn it back on, they need to turn it off and leave it off.
And stop hiding extensions.
Post by Ray
perhaps if someone wrote the "don't f*&$ open me"[1] virus and had it
go through a little tutorial about why not to open unknow attachments
have message go something like "I was foolish enough to open the
attachment, and since you are at risk of getting a message from me
with a virus, this attachment has forwarded itsself to you"
They just had an anti-virus virus, which was at least as bad as the
original. Pass thanks.
Eh. The way I handled NIMDA and Code Red was to write a quick little
script with the help of an actually clueful MCSE that ran through the
apache error.log every hour and used wget to try and exploit the
offending machine and wipe the drive. After a week of that, there
were only four or five machines left that would go down for a few
days, then start trying again for a few minutes until the top of the
hour hit and got wiped again. Those morons had to have been
reinstalling windows two or three times a week.
Ehh, you might have given the morons time to back up essential work,
and seperated all the machines, verified they were clean, patched them.
And educated the users, before putting them back on line. It would have
eliminated the need to reinstall multiple times on the same machine, and
it needed to be done anyhow.

I hope your boss authorized it, preferably in writing, or they have a
sense of humor. Otherwise I'd start looking for a job outside the IT
industry.

Michael C.
--
***@usol.com http://mcsuper5.freeshell.org/
Registered Linux User #303915 http://counter.li.org/
Continue reading on narkive:
Loading...