[ILUG] Spam and more spam
jm at jmason.org
Wed Mar 3 01:07:42 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Rick Moen writes:
>Quoting Justin Mason (jm at jmason.org):
>> Installing SA-Exim4 may be too invasive, though. :(
>I'm honestly not sure the above means. (Please don't take that as my
>not being receptive to what you're saying. A bit thick, perhaps.
"invasive" in terms of sysadmin work required ;)
>Some significant advantages of MTA-level detection and handling:
>o Your 55x rejects are guaranteed to be passed to the MTA that's
> actually trying to deliver mail to you. This is a major gain
> compared with generating bounce messages, given the prevalence of
> forged headers in incoming SMTP. (In generating bounces to
> forgemail, you yourself as an MTA operator are a source of
> additional spam, not to mention wasting tremendous amounts
> of bandwidth and processing power.)
>o You can perform intelligent testing of the alleged sender _prior_
> to accepting the mail. E.g:
> o You can verify that sender domain has postmaster@ and abuse@
> addresses, and accepts mail from a null reverse path
> ("MAIL FROM:<>"), as required by RFCs.
> o You can verify that alleged sender exists by initiating and
> then cancelling a reply mail.
> o You can make sure sender or sender domain or sender IP are
> not in various DNSBLs or site-specific blacklists.
> o You can optionally test the mail with SpamAssassin for
> spamicity level.
>o Based on such checks, you can for various cases, as the sender
> or delivering MTA deserves, either accept the mail and deliver
> it, or pretend to accept the mail and drop it on the floor, or
> 55x reject it, or teergrube (tarpit) the delivering MTA using
> 45x SMTP messages.
That's true -- a very big plus for most people.
(Not me though, sadly. in my case I have an interest in *receiving* spam
so I can record it for SpamAssassin development. that's life I guess ;)
Hmm -- Rick -- can SA-exim divert possible spam to a side mbox?
>> - - use MailMan 2.1.x (MUCH better).
>As you'll note on
>http://linuxmafia.com/cgi-bin/mailman/listinfo/conspire , I _likewise_
>use Mailman 2.1.3. While I appreciate its additional flexibility, I
>would not call it "much better" in the respects relevant to the problem:
>If the MTA accepts the junkmail, then Mailman still bothers the
>listadmin about it.
>Yes, you can indeed check "Discard all future mail from this sender",
>but that's not a lot of good, given that the junkmail's alleged sender
>was either random or effectively so.
yes. But you can also check "allow all future mail" too, for the
genuine mail. And the horrific web interface is avoided.
>> - - the nagmails for non-subscriber posts will arrive at the moderator
>> list. Have SEVERAL people on this list.
>Colm has explained why this is a poor outcome. I agree. So should you.
>The only solution is to ensure that the junkmail (in a very high
>percentage of cases) doesn't reach Mailman at all. Thus my suggestion.
Hmm. Given the volume Colm's talking about -- I would tend to agree.
>> FWIW, making sure that members can post freely helps a lot; the members
>> (the day to day community) are not impeded at all.
>But that is _not_ moderation, then. Colm was speaking of list moderation,
>something else entirely.
Sure, agreed. I think Mailman may use the term "moderation" in
this situation though -- "moderated posting for non-members" or similar.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
-----END PGP SIGNATURE-----
More information about the ILUG