Re: [Exim] Opinions sought: Most effective spam reduction te…

Top Page
Delete this message
Reply to this message
Author: Exim User's Mailing List
Date:  
To: Richard Clayton
CC: Exim User's Mailing List
Subject: Re: [Exim] Opinions sought: Most effective spam reduction techniques
[ On Monday, August 23, 2004 at 10:25:28 (+0100), Richard Clayton wrote: ]
> Subject: Re: [Exim] Opinions sought: Most effective spam reduction techniques
>
> so from this evidence the router clearly looked up the MX record for
> highwayman.com and then proceeded to
>
>     HELO        highwayman.com
>     MAIL FROM   richard@???
>     RCPT TO     richard@???

>
> which is of course "broken" and could be relatively easily fixed by the
> firmware writer, but prior to that ever occurring, of course I would
> still view it as a "false positive" since I rather wanted the email


Since that device is undoutably connected to some local "trusted"
network then you should probably consider handling it's connection
attempts with a different set of policy rules than you would use for
foreign non-trusted smtp clients.

I.e. what you see isn't really a "false positive", but rather a result
of a configuration "deficiency". No doubt you'd be getting similar
"false positives" from any of the many similarly broken MSAs in junky PC
software, if you also used such software on your local network(s). :-)

Note too that for this kind of policy mechanism there is no such thing
as a "false positive" since the policy implementation has worked exactly
as specified. The responsibilty to identify one's self correctly and
completely is _entirely_ the client's (at least so long as that client
is not trusted because of some other more basic mechanism). A true
"false positive" would only occur if the client had correctly identifed
itself but the verification of its identification failed (i.e. if there
was a case of mistaken identity). Of course then we have to ask if it
is better to "fail safely" or not, and what exactly "safe" means in this
kind of scenario. The answers will depend entirely on who benefits more
from the transaction completing successfully. ;-)


> I think there's quite of lot of this manufacturer's kit out there :(


As you say it's still quite broken of course, but at least this kind of
junk is likely only used in scenarios where you can moderate the amount
of trust you give it, and as Alan said it also gives the rest of us a
chance to ignore it and its ilk without even the slightest hesitation. :-)

I.e. I think we all agree there's lots of buggy MSA software around that
can't do SMTP even half-right, but we only have to tolerate our own
buggy software instances, and not any of that same software running on
anyone else's network.

-- 
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>