> On May 9, 2:42pm, Wolfgang Rupprecht wrote:
> }
> } Actually, much of the spam that homeworld.cygnus.com forwards could be
> } stopped with the current sendmail 8.9.0 run as a front-end filter for
> } qmail doing the final delivery. (Phony "from" filtering and
> } spam-software-only header filtering does a surprisingly thorough job.)
How hard would it be to add this to qmail? I can't imagine it is that
hard, and I also can't imagine that filtering on "From " or "From:" can
really catch spam... people will just list la...@aol.com or
even...@msn.com there.
> Having one MTA feed another is not only silly, but grossly
> wasteful of resources. However, it would be nice if homeworld didn't
> run qmail, since it is grossly wasteful of bandwidth.
But, for mailing lists, that helps a lot. Having the list manage itself
is much nicer than having some list maintainer have to kick in all the
time.
--Michael
Michael Graff writes:
> How hard would it be to add this to qmail? I can't imagine it is that
> hard,
I'm told that there is an unofficial patch to run procmail over each
incoming msg. This procmail is run during the SMTP phase, so SMTP can
blow off the sending site it there is something in the header it
doesn't like.
Seeing how none of the unofficial patches are ever incorporated into
qmail (NIH ???), its highly unlikely that something that execs another
program and adds quite a bit of code will make it into the mainstream,
audited and secure core of the qmail distribution.
> and I also can't imagine that filtering on "From " or "From:" can
> really catch spam... people will just list la...@aol.com or
> even...@msn.com there.
The phoney "from" or "from: " detection is a cheap kill. So is the
detection of the "X-UIDL", "X-PMDL", "Comments: autenticated sender is
<ha-ha>" etc. I'm not sure why spammers are stupid enough to tag
their spam as spam, they just are. I'm willing to make use of it to
rid myself of it.
The best part of doing header checking is that it allows one to not
worry about open SMTP relays as much. One can still detect much of
the spam coming from them.
John Nemeth <jne...@cue.bc.ca> writes:
> > Having one MTA feed another is not only silly, but grossly
> > wasteful of resources. However, it would be nice if homeworld didn't
> > run qmail, since it is grossly wasteful of bandwidth.
It also only adds the equivalent of one delivery load. Lets say we
have a 1000-reader mailing list. Having sendmail prescreen the
headers will only add one more MTA hand-off to the equation of 1000
MTA handoffs per message. Not much of a CPU load.
It is someone grotty to have to maintain both a sendmail and qmail
setup.
-wolfgang
--
Wolfgang Rupprecht <wolf...@wsrcc.com> http://www.wsrcc.com/wolfgang/
Never trust a program you don't have sources for.
Perhaps the fact that the original sender is not in the mail gateway's
domain or even close to it (as in the case of almost all the spam I've
received through this list and other NetBSD lists) can be used as a sign.
Then, a more thorough check can be performed. This way a cursory glance is
all that is needed at first, with only a very small percentage of the
mails which are passed through going through the detailed (procmail?)
check.
Oop.. here comes another. Oh boy.. a dental plan. Just what I wanted.
Marc Tooley
too...@douglas.bc.ca
This is a rather gross concept. It's also extremely wasteful of
resources, since it means spawning a second process to handle all
incoming SMTP transaction. If you want to do something like this,
then the right was to do it would be to put a stripped down procmail
engine into qmail's smtpd. It should be just enough to say yay or nay
to the incoming mail. All the stuff to do with forwarding mail,
calling external programs, etc. should be stripped.
} Seeing how none of the unofficial patches are ever incorporated into
} qmail (NIH ???), its highly unlikely that something that execs another
} program and adds quite a bit of code will make it into the mainstream,
} audited and secure core of the qmail distribution.
Although NIH in general is bad, I would have to agree in this
particular case. Audited by whom? (The author doesn't count.) I
wouldn't classify it as secure, but that's a different rant for
another day.
} John Nemeth <jne...@cue.bc.ca> writes:
} > > Having one MTA feed another is not only silly, but grossly
} > > wasteful of resources. However, it would be nice if homeworld didn't
} > > run qmail, since it is grossly wasteful of bandwidth.
}
} It also only adds the equivalent of one delivery load. Lets say we
} have a 1000-reader mailing list. Having sendmail prescreen the
} headers will only add one more MTA hand-off to the equation of 1000
} MTA handoffs per message. Not much of a CPU load.
It's a gross waste of resources (both people and machine). If
you're going to have sendmail prescreen the mail, then have it do the
delivery as well. It would be redundant to have sendmail pass the
item onto another MTA just to do all the work that it just did.
} It is someone grotty to have to maintain both a sendmail and qmail
} setup.
That's an understatement.
}-- End of excerpt from Wolfgang Rupprecht
Not easy. It would require changes to the source code. qmail
isn't very flexible. It doesn't have a built-in macro/configuration
language like sendmail does.
} hard, and I also can't imagine that filtering on "From " or "From:" can
Checking for invalid envelope return addresses cuts out about
half of the spam.
} really catch spam... people will just list la...@aol.com or
} even...@msn.com there.
This sort of thing would catch a significant per centage of the
remaining spam.
Of course spammers will get smarter. This is another example of
the classic arms race.
} > Having one MTA feed another is not only silly, but grossly
} > wasteful of resources. However, it would be nice if homeworld didn't
} > run qmail, since it is grossly wasteful of bandwidth.
}
} But, for mailing lists, that helps a lot. Having the list manage itself
} is much nicer than having some list maintainer have to kick in all the
} time.
qmail doesn't manage mailing lists, it's an MTA. The NetBSD
Foundation uses majordomo to manage its mailing lists. qmail is a
very bad mta to use for handling mailing lists since it sends
everybody a seperate message instead of sending a single message with
multiple recipients specified. This is a gross waste of bandwidth.
There's no way that you can convince me that sending multiple copies
of a message uses less bandwidth then sending a single copy to
multiple people. That's an absurd notion. Also, qmail will open
multiple simultaneous connections to a remote site. This is a gross
abuse of resources at the remote site. It also won't get the mail
through any faster, since the pipe is only so big.
I was rather disappointed when I noticed that the The NetBSD
Foundation had changed to qmail on it's mail server.
}-- End of excerpt from Michael Graff