You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2011/08/11 21:51:49 UTC
[Bug 6648] New: "MTX" solution to identify authorized mail servers.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
Bug #: 6648
Summary: "MTX" solution to identify authorized mail servers.
Product: Spamassassin
Version: unspecified
Platform: All
URL: http://www.chaosreigns.com/mtx/
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P4
Component: Plugins
AssignedTo: dev@spamassassin.apache.org
ReportedBy: software+spamassassin@kd6lvw.ampr.org
CC: Darxus@ChaosReigns.com
Classification: Unclassified
cf. http://www.chaosreigns.com/mtx/ - a Solution by "Darxus."
I've looked at this. I like it. Therefore, I'd like to suggest that perhaps
we include Darxus' plugin (MTX.pm) to perform the check he proposes. As this
concept is certainly not mainstream, I also propose that it be disabled in the
"*.pre" files by default. SA users who want to perform the check should enable
it in their local files. I don't see how including an extra plugin and a
"20_mtx.cf" file would hurt.
I'm not saying that we should add every possible plugin that exists. However,
Darxus appears to be a regular SA contributor, and the module and configuration
example appears mature and ready for implementation. Although he's proposed
his idea on the appropriate IETF mailing list, etc...., I haven't seen it
proposed here, so at least the "SA gods that be" can consider it.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
D. Stussy <so...@kd6lvw.ampr.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |software+spamassassin@kd6lv
| |w.ampr.org
--- Comment #8 from D. Stussy <so...@kd6lvw.ampr.org> 2011-08-12 05:44:16 UTC ---
Oops! Maybe that should be file "25_mtx.cf" since all the other DNS-based
tests seem to be in group 25.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #6 from Darxus <Da...@ChaosReigns.com> 2011-08-12 04:21:02 UTC ---
Please forgive my over-enthusiasm. Increasing the default threshold, and
penalizing people for not using MTX while it's not more widely implemented, are
both bad ideas.
So how about this:
score MTX_PASS -1 # Conservative bonus for Pass.
score MTX_FAIL 0.001 # Using NONE/NEUTRAL/SOFTFAIL/HARDFAIL instead.
score MTX_NONE 0.001 # No penalty for not using MTX, until it's
# more widely used.
score MTX_NEUTRAL 0.001 # Same lack of penalty for people using MTX preferring
# minimum penalty for IPs without an MTX record.
score MTX_SOFTFAIL 1 # More penalty for those who want it.
score MTX_HARDFAIL 100 # Major penalty for those who want it.
Enable MTX in SA by default. Don't penalize anybody. Give a conservative
bonus where MTX records are used. Pound on HardFail because there's no reason
not to.
Then wait for more people to create their MTX records to get that -1 score.
Creating blacklist entries by domain wherever spammers show up using MTX.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #20 from Darxus <Da...@ChaosReigns.com> 2011-08-13 16:56:14 UTC ---
(In reply to comment #17)
> I'm officially voting -1 even for sandbox, since it might require additional
> Also I wouldn't even consider the module until it used async lookups.
So you won't possibly approve it in any way.
*And* you want me to change the way DNS lookups are done?
I hate you guys.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #7 from D. Stussy <so...@kd6lvw.ampr.org> 2011-08-12 05:10:22 UTC ---
Created attachment 4951
--> https://issues.apache.org/SpamAssassin/attachment.cgi?id=4951
My "20_mtx.cf" file
This is what I've decided to use in the meantime as configuration for this
plugin.
I thought that 100 was too harsh for a hard failure. 10 is sufficient,
especially with a default threshold of 5 overall.
I didn't want to give too much credit for passing, as this method does not
actually assess content. (I also give SPF=pass the same score and penalize the
SPF=NONE case). I expect that the SA community may wish to deviate from that
in the final version that gets committed.
In the descriptions of states, I felt that "pass" and "neutral" didn't need the
URL reference - because they will only occur in cases where people have
followed the rules in creating the record. However, the other cases do deserve
the reference to spread the word or if DNS data yields an unexpected failure.
I changed the "example" blacklist to a case which should occur rarely.
"localhost", when properly used should only appear for the loopback addresses,
which are part of SA's trusted_network variable thus skipping MTX checks.
However, some jerks are using "localhost" as their PTR record RHS for unicast
addresses, so this live example will actually catch them.
I also tab-aligned the fields. All that is needed is the usual SA comment
header.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
Henrik Krohns <he...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hege@hege.li
--- Comment #9 from Henrik Krohns <he...@hege.li> 2011-08-12 06:16:57 UTC ---
I'm sorry but this was beaten to death long time ago on the users list. But as
long as it never will be on by default I don't care either way. It's ridiculous
to assume people would adopt this just because SA uses it.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by Benny Pedersen <me...@junc.org>.
On Thu, 11 Aug 2011 20:09:08 +0000,
bugzilla-daemon@bugzilla.spamassassin.org wrote:
> a half ago, and it has changed very little since then. The change
> history is
> here: http://www.chaosreigns.com/mtx/#plugin
another exsample on loadplugin in cf files :(
should be pre file that holds it
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #2 from Darxus <Da...@ChaosReigns.com> 2011-08-11 20:09:08 UTC ---
(In reply to comment #1)
> Certainly looks interesting. Is MTX on a standards track?
Thanks, I think it's great. No, I haven't begun the RFC process.
And I do agree that it's mature. I created it and started using it a year and
a half ago, and it has changed very little since then. The change history is
here: http://www.chaosreigns.com/mtx/#plugin
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #18 from D. Stussy <so...@kd6lvw.ampr.org> 2011-08-13 07:44:22 UTC ---
If the plugin module is not loaded, there are no rules nor DNS checks
performed. Why do you think the proposed configuration file is wrapped with
"ifplugin ... endif"? As noted, the "loadplugin" statement does not belong in
a "*.cf" file.
In the majority of cases, this adds only two additional DNS lookups. The
initial PTR lookup is not counted as that's done by existing code (especially
for the FCrDNS check that the MTAs usually do themselves) and therefore already
cached by the local DNS resolver. The additional lookups done are precisely:
1) <reverse_address>.mtx.<PTR-hostname>
2) policy.mtx.<PTR-domain-name>
If implemented and lookup #1 indicates a pass, lookup #2 does not occur. If
lookup #1 indicates a failure (or is not present), lookup #2 occurs, and
additional fetches occur only when lookup #2 indicates delegation.
I would also like Darxus to comment here about what happens when
"mtx_blacklist" is used with a negative score. It seems to be a general score
alterer based on the domain pattern matching the PTR record.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.3.3 |Undefined
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #11 from AXB <ax...@gmail.com> 2011-08-12 10:23:45 UTC ---
(In reply to comment #0)
> cf. http://www.chaosreigns.com/mtx/ - a Solution by "Darxus."
>
> I've looked at this. I like it. Therefore, I'd like to suggest that perhaps
> we include Darxus' plugin (MTX.pm) to perform the check he proposes. As this
> concept is certainly not mainstream, I also propose that it be disabled in the
> "*.pre" files by default. SA users who want to perform the check should enable
> it in their local files. I don't see how including an extra plugin and a
> "20_mtx.cf" file would hurt.
>
> I'm not saying that we should add every possible plugin that exists. However,
> Darxus appears to be a regular SA contributor, and the module and configuration
> example appears mature and ready for implementation. Although he's proposed
> his idea on the appropriate IETF mailing list, etc...., I haven't seen it
> proposed here, so at least the "SA gods that be" can consider it.
Plugins don't get added coz we like them or they've been written by friends.
They get added because they prove themselves efficient and do something worth
while.
First, it should be added to
http://wiki.apache.org/spamassassin/CustomPlugins and allow potential users to
test and comment.
It can be also placed in a samnbox and allow masschecks to use it and if the
results are convincing , it will be reviewed, discusses, tested, taken apart
and maybe it gets added to mainstream code.
This has been the regular process and there is no reason to change that now.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #10 from D. Stussy <so...@kd6lvw.ampr.org> 2011-08-12 07:25:10 UTC ---
Point taken, but under the belief of "if you build it, they will come," well,
Darxus built it, so maybe they will come if there's support, and maybe support
for it is the motivation they need.
SPF was originally designed and deployed in 2004. Seven years later and it's
penetrated only about 10% of domains sampled (per
http://spf-all.com/stats.html), yet SA support that. DomainKeys, harder to
implement, has come into usage less. Both of them have RFC's that have been
out for 5 years.
In comparison, Micro$oft's "sender ID" failed - for two reasons: 1) Microsoft
was behind it and alot of people simply hate them, and 2) They attempted to
co-opt someone else's idea by calling sender ID "spf2." I also recently found
a proposal (which reached draft RFC status but was never submitted) regarding
".mxout." That proposal also tried to identify systems that could send mail
and those which shouldn't.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #13 from Michael Parker <pa...@pobox.com> 2011-08-12 16:16:24 UTC ---
-1 for adding to current code base.
Get some soak time on the CustomPlugins page, or setup a channel and get lots
of good feedback and then come back with a proposal and a patch.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #4 from Darxus <Da...@ChaosReigns.com> 2011-08-12 02:50:39 UTC ---
(Oops.)
Test harness output:
http://www.chaosreigns.com/mtx/testmtx.txt
Tests 12 different combinations of MTX records, MTX Policy records, and MTX
blacklist values, through SpamAssassin, reading the results from the SA tests
hit. (Uses DNS values configured in my local DNS server.) IPv6 is not tested
with this harness, but I've tested it manually for just a couple of the
possibilities. So I'm confident this thing works. Harness script hasn't been
modified since February 2010.
MTX wizard:
http://www.chaosreigns.com/mtx/wizard/
Given an IP address (IPv4 or v6), generates BIND DNS syntax MTX records, and
tests existing records. New, and not particularly pretty, but works, and
should ease adoption some.
Anybody know what false positive rate would be caused by adding 0.1 to all
email scores, or, the equivalent, setting the threshold to 4.9? Because I
think including MTX in SpamAssassin, enabled, with MTX_NONE set to 0.1 would be
really freaking cool. I would expect the false positive rate it would cause to
be very low, while giving people a slight incentive to create their MTX
records.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #14 from AXB <ax...@gmail.com> 2011-08-12 16:39:50 UTC ---
(In reply to comment #12)
> What percentage of legit emails were passing SPF and DKIM when rules for them
> were added?
quite alot. There were milters and filters and it was a standard quite a while
before SA adopted it.
> (In reply to comment #9)
> > I'm sorry but this was beaten to death long time ago on the users list. But as
> > long as it never will be on by default I don't care either way. It's ridiculous
> > to assume people would adopt this just because SA uses it.
>
> Why is it ridiculous to assume people would adopt this just because SA uses it?
> That's not quite exactly what I'm suggesting. What's wrong with adding it to
> SA to see if it increases adoption and ends up very useful?
90% of the SA setups are on auto-pilot (Think Cpanel/Plesk and all the other
millions of shared hosting shps using SA)
Having it installed doesn't automatically mean anybody will understand it,
mantain it locally or even notice the value.
>
> (In reply to comment #11)
> > Plugins don't get added coz we like them or they've been written by friends.
> > They get added because they prove themselves efficient and do something worth
> > while.
>
> And what if the best chance something has to prove itself efficient and worth
> while is to add it to SA?
>
> > First, it should be added to
> > http://wiki.apache.org/spamassassin/CustomPlugins and allow potential users to
> > test and comment.
>
> Done.
>
> > It can be also placed in a samnbox and allow masschecks to use it and if the
> > results are convincing , it will be reviewed, discusses, tested, taken apart
> > and maybe it gets added to mainstream code.
>
> So I should create a patch to create a rulesrc/sandbox/darxus directory in
> trunk containing MTX.pm, a .pre to load the module and a .cf to set the scores?
IIrc, put the MTX plugin as sandbox-darxus.pm plugin in
rulesrc/sandbox/darxus as other sandbox have their test plugins
(hstern/felicity, etc) create the rules and set the rules to "tflags nopublish"
and wait for results.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #15 from Darxus <Da...@ChaosReigns.com> 2011-08-12 17:12:28 UTC ---
Created attachment 4952
--> https://issues.apache.org/SpamAssassin/attachment.cgi?id=4952
Add MTX.pm as sandbox-darxus.pm in rulesrc/sandbox/darxus/
I went with putting the loadplugin in the .cf because there isn't an example of
a .pre working in the sandbox and I don't know of anything wrong with it.
I think the scores are plenty conservative, and they have tflags net nopublish.
I need somebody else to commit this since I don't have access.
> > What percentage of legit emails were passing SPF and DKIM when rules for them
> > were added?
>
> quite alot. There were milters and filters and it was a standard quite a while
> before SA adopted it.
So why did SA take so long to create the SPF and DKIM rules?
> 90% of the SA setups are on auto-pilot (Think Cpanel/Plesk and all the other
> millions of shared hosting shps using SA)
>
> Having it installed doesn't automatically mean anybody will understand it,
> mantain it locally or even notice the value.
Having it installed on more servers means there's more benefit to creating the
records - more servers that will acknowledge your whitelisting.
It's as much of a chicken and egg problem as SPF and DKIM and probably many
other things. There's no point in creating the records until a bunch of people
are using them. And there's no point in using the records until a bunch of
people have created them. We can take a chunk out of that problem by enabling
use of the records by a bunch of people (in SA), I believe without significant
disadvantage.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #17 from Henrik Krohns <he...@hege.li> 2011-08-13 07:19:40 UTC ---
(In reply to comment #9)
> But as long as it never will be on by default I don't care either way.
Actually I take this back.
I'm officially voting -1 even for sandbox, since it might require additional
DNS lookups for mass checkers. Mass checks would be pointless anyway since no
one is using MTX. Seeing all the "internal adopters" would tell us nothing.
Also I wouldn't even consider the module until it used async lookups.
Please put it in CustomPlugins, good luck etc. Some parts are ideologically
sound, but there are lots of reasons for the real world to not care about it. I
certainly would be happy blocking zombies with "MTX policy" etc, but talking
about that stuff here makes no difference. Let's review this again when even a
few top-100 (spamming) ISPs implement this.. until then you are free to
implement it the custom way.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #1 from Kevin A. McGrail <km...@pccc.com> 2011-08-11 19:55:43 UTC ---
(In reply to comment #0)
> cf. http://www.chaosreigns.com/mtx/ - a Solution by "Darxus."
>
> I've looked at this. I like it. Therefore, I'd like to suggest that perhaps
> we include Darxus' plugin (MTX.pm) to perform the check he proposes. As this
> concept is certainly not mainstream, I also propose that it be disabled in the
> "*.pre" files by default. SA users who want to perform the check should enable
> it in their local files. I don't see how including an extra plugin and a
> "20_mtx.cf" file would hurt.
>
> I'm not saying that we should add every possible plugin that exists. However,
> Darxus appears to be a regular SA contributor, and the module and configuration
> example appears mature and ready for implementation. Although he's proposed
> his idea on the appropriate IETF mailing list, etc...., I haven't seen it
> proposed here, so at least the "SA gods that be" can consider it.
Certainly looks interesting. Is MTX on a standards track?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #12 from Darxus <Da...@ChaosReigns.com> 2011-08-12 16:12:20 UTC ---
What percentage of legit emails were passing SPF and DKIM when rules for them
were added?
(In reply to comment #9)
> I'm sorry but this was beaten to death long time ago on the users list. But as
> long as it never will be on by default I don't care either way. It's ridiculous
> to assume people would adopt this just because SA uses it.
Why is it ridiculous to assume people would adopt this just because SA uses it?
That's not quite exactly what I'm suggesting. What's wrong with adding it to
SA to see if it increases adoption and ends up very useful?
(In reply to comment #11)
> Plugins don't get added coz we like them or they've been written by friends.
> They get added because they prove themselves efficient and do something worth
> while.
And what if the best chance something has to prove itself efficient and worth
while is to add it to SA?
> First, it should be added to
> http://wiki.apache.org/spamassassin/CustomPlugins and allow potential users to
> test and comment.
Done.
> It can be also placed in a samnbox and allow masschecks to use it and if the
> results are convincing , it will be reviewed, discusses, tested, taken apart
> and maybe it gets added to mainstream code.
So I should create a patch to create a rulesrc/sandbox/darxus directory in
trunk containing MTX.pm, a .pre to load the module and a .cf to set the scores?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #16 from D. Stussy <so...@kd6lvw.ampr.org> 2011-08-12 17:59:01 UTC ---
Sandbox: Not a problem (but I don't have access to commit it there either).
My purpose in opening this thread was to get the process started, and if the
process says put it in the sandbox first, so be it.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
Darxus <Da...@ChaosReigns.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|"MTX" solution to identify |[review] "MTX" solution to
|authorized mail servers. |identify authorized mail
| |servers.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #5 from Darxus <Da...@ChaosReigns.com> 2011-08-12 03:13:57 UTC ---
Ooh, more fun idea:
Continue generating test scores with a threshold of 5, but set SA default
threshold to 5.1, then include MTX with MTX_NONE set to 0.1. Then you cause no
additional false positives. And false negatives only occur where spammers use
MTX, which I remain convinced should be easy to handle with the included MTX
blacklisting functionality.
Of course, I'd be all for doing this with higher numbers, like a threshold of
5.5 and MTX_NONE set to 0.5. Or 6.0 and 1.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] [review] "MTX" solution to identify authorized mail
servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #19 from Henrik Krohns <he...@hege.li> 2011-08-13 09:18:06 UTC ---
(In reply to comment #18)
> If the plugin module is not loaded, there are no rules nor DNS checks
> performed.
And as such there is no need to be it in SA sandbox. The only purpose there
would be for mass checks which would be pointless.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6648] "MTX" solution to identify authorized mail servers.
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6648
--- Comment #3 from Darxus <Da...@ChaosReigns.com> 2011-08-12 02:39:31 UTC ---
A couple new things to maybe encourage you to include this in SpamAssassin:
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.