-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ed wrote:
> Well actually there is an easy way. Have your sending
MTA write a
> custom header into the email if possible. If the
receiving MTA gets a
> bounce without that header OR being able to recognize
the original
> sending MTA then the bounce is /rejected/.
Yes, I've seen variations of this, such as using
organization-specific
subject prefixes (e.g. "Subject: [Companyname] This is
my subject"),
which can be used as a means of readily identifying non-spam
and
crediting it with a negative score boost that's equivalent
to
soft-whitelisting (e.g. -100.0). A custom header could be
used the same
way (e.g. "X-Companyname: This is my custom
header").
Of course you're talking about rejection at the MTA level,
rather than
solving the problem further downstream with SpamAssassin, so
I gather
that your tests are being applied by the MTA itself. You
don't use
Postfix as I recall, but presumably something like this
could be
configured as part of a header check module.
> Mail admins should understand email.
> Unfortunately that's not the case many times.
Sadly true. It's much the same as the situation discussed
here recently
regarding database admins not being properly
educated/trained--the
widespread availability of free (or inexpensive) server
software has put
powerful tools in the hands of the masses, a lot of whom
really don't
understand what they're getting into. It's a vexing and
unanticipated
side-effect of the free and open source software
movement--tools that
used to cost thousands of dollars were at one time the
exclusive
province of professionally-trained administrators, but now
untrained
individuals have access to these same sophisticated tools,
and
unfortunately their learning pains are inflicted on the
Internet at large.
<rant>I do wonder from time to time how long it's
going to be before
running Internet-connected servers will require some sort of
license and
registration. We require training and licensing before we
let motorists
endanger others on public streets, and we do the same for
the pilots of
marine vessels and aircraft. Mandated periodic inspections
for the
airworthiness, seaworthiness, and roadworthiness are common
in most
countries to ensure that the vehicles themselves are safe to
operate.
Even the use of restricted radio frequencies requires an
operator's
permit in most countries, so that amateurs won't
inadvertently disrupt
emergency services or air traffic control. As the Internet
becomes a
more vital "public space", I wonder at what point
national authorities
will begin treating traffic on the networks in their
jurisdictions like
other protected commons and require registration of servers
and
licensing of administrators.</rant>
> You don't want this stuff to get past the gateway if
possible. The
> rules in SA should be a last resort. This prevents
bayes poisoning.
It's not Bayes poisoning if you /want/ all of these DSNs to
be flagged
as spam; i.e. if your definition of "spam" has
been expanded to include
these nuisance DSNs, then those tokens are very desirable as
spam signs.
That said, I agree with you that if you can block this crud
upstream at
the MTA that's even better. Anyone have a Postfix header
ruleset to
recommend for this sort of thing? 
- --
Robert LeBlanc <rjl renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGyjBwGmqOER2NHewRAji5AKCKbIesKeAaudkcRXxzFsRAnGKssACg
mpEt
YOVOsJVUC+FWfULicnavSUU=
=lxxo
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users
|
