X-Mail-Filters-Spam : Spam [ID=-1] Precedence: bulk Sender: [EMAIL PROTECTED] Reply-To: [email protected]
Hi Martin: Don't get your hopes up. IMail is a great "application" (e.g., their back-end), but on the systems end (dealing with the SMTP protocol), they've never been able to catch up with real-life demands. It's possible that they just don't have any strong talent in that area. Most of their anti-spam implementation is of little value, because it forces us to first ACCEPT a mail and THEN (if we were to follow RFCs) notify apparent senders of our non-delivery. That was fine 10 or 15 years ago, when this was once conceived. But given the realities of 2007 (and the several prior years), 99% of the apparent senders are non-existing accounts or joe-jobs who would end up being spammed by us. If we simply "delete" messages, then you run the risk of deleting or blocking legitimate messages WITHOUT giving the sender (and the recipient) the required (and absolutely necessary) notification that "something's wrong with your message". The obvious solution has always been to REFUSE the acceptance of mail as early as possible - meaning, during the actual SMTP connection. If one chooses to block mail based on failed SPF, missing RevDNS (whether you agree with that or not), faked HELO strings or even certain internal or public IP or domain black-lists, then this should be done during the connection - not after the "ship has sailed". This way, the sending mail server would receive a proper error-return and IT will be responsible of notifying its OWN users (if indeed there was a legitimate user involved). The same holds true of the ability to "fortify" certain accounts (such as abuse@, postmaster@,...). We should be able to set up "policies" where any mail directed to these accounts is not permitted to have more than xxx other recipients (possibly as little as 1). Moving on to SURBL and other content checking (even virus checking). Some could be performed before confirming the receipt of the DATA command and still refused at that time. While connection dropping at that point is not an option offered by the RFC, it is now a very common and thus justifiable practice. All of these things are trivial to implement - yet, they never get accomplished. Consequently, I can't imagine them having the necessary expertise to implement more sophisticated schemes, such as grey-listing. Your solution is to use Imail as the great back-end "application software" that it is, but to front-end it with more current technology by more capable "systems" vendors. For small users, Imail might work out of the box, but for more "exposed" mail domains, Imail is not a serious contender for spam control and appears to have no ambitions in that direction. Best Regards, Andy ----- Original Message ----- From: "Martin Schaible" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, May 16, 2007 8:44 PM Subject: AW: [IMail Forum] Grey Listing Hi, I expected a short statement from ipswitch. So, is a native greylisting somewhere on the horizon, or do we have to wait another year? Mit freundlichen Grüssen To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
