Is that your own webmail server (run by you, or run by a service you use/trust/contract-with/etc.)? Because, a webmail transaction shouldn't go to the generic internet anymore than a desktop client should, IMO ... so they're in the same boat as everyone else.
That host should go to their local MTA, and then to you (if they aren't YOUR webmail servers). If they are a combined Webmail and MTA host ... then they're just as badly named as any other MTA with an IP address in the name. Plus, HTTP transactions are no more nor less subject to manipulation than SMTP transactions. If they ARE your webmail servers, then you should use existing options about trusted networks, Botnet's exceptions for skipping or exempting certain IP's, etc. It's the same as if they were your own desktop clients with dhcp based hostnames. So, it would seem to me that the current tools already handle it, and the specific nature of the request isn't any different from other cases. Does anyone think that's way off base? The only thing I can think of is that (trying to remember what I wrote many years ago), Botnet has an exemption for authenticated submissions. But, Botnet doesn't detect that natively, IIRC, it trusts Spam Assassin to determine that. That feature in Botnet just honors that Spam Assassin said "it was authenticated". So, if what you're saying is "HTTP relays should be treated like SMTP-AUTH relays", then I would say "I think that's a Spam Assassin issue, not a Botnet limitation". If SA is properly recognizing it, but Botnet isn't honoring it, then let me know, and I'll see how I can add it to the Botnet authentication exemption (assuming there's a way to tell the difference between "Webmail" and "some cgi/php script", as I don't want to automatically exempt the latter, I think). On Wed, Jan 28, 2009 at 05:14, Andy Dorman <ador...@ironicdesign.com> wrote: > We have found Botnet to be very helpful in trapping spam generated by > misbehaving home computers and office workstations. So we want to avoid > making changes that could reduce it's effectiveness. > > However, we are having a problem with it also catching legitimate email sent > from webmail hosts. The "untrusted" relay that is triggering the test looks > like this example. > > Received: from rbn1s-216-180-93-118.adsl.hiwaay.net > (rbn1s-216-180-93-118.adsl.hiwaay.net [216.180.93.118]) by > mail.homefreemail.com (Horde Framework) with HTTP; Fri, 23 Jan 2009 > 16:03:43 -0600 > > And we can see what happens when we run in debug mode. > ... > [538] dbg: Botnet: starting > [538] dbg: Botnet: no trusted relays > [538] dbg: Botnet: Skipped ip 192.168.0.5 > [538] dbg: Botnet: get_relay good RDNS > [538] dbg: Botnet: IP is '216.180.93.118' > [538] dbg: Botnet: RDNS is 'rbn1s-216-180-93-118.adsl.hiwaay.net' > [538] dbg: Botnet: HELO is 'rbn1s-216-180-93-118.adsl.hiwaay.net' > [538] dbg: Botnet: sender 'andydor...@comehome.net' > [538] dbg: Botnet: hit (client,ipinhostname,clientwords) > [538] dbg: rules: ran eval rule BOTNET ======> got hit (1) > > What we would like Botnet to do is recognize that this is an HTTP > transaction, not smtp, and hence not hit on it. > > We were first wondering if anyone else has encountered this issue and > possibly there is a fix we are not aware of? > > Otherwise, we would be willing to give a shot at a patch to handle this > issue. > > Just did not want to re-invent the wheel. > > Thanks, > > -- > Andy Dorman > Ironic Design, Inc. >
