Re: [Declude.JunkMail] Gateways and CMDSPACE conundrum

[Matt]

Sandy et al., Regarding how peering is handled, that sucks!  It was a bit of a kludge anyway, more than most at least. I just got mail bombed on both servers by three different ISP relays.  The recipient address was invalid (sent to and from itself), and if I had MS SMTP/ORF configured on both machines to blacklist invalid addresses (instead of just the domain on the backup as is done currently), this would have stopped that attack cold without me lifting a finger.  Instead I was stuck scanning as many as 15 incoming messages per second, or at least trying to do so, but not succeeding.  Worse yet, the destination server was bouncing NDR's back through our server and each of those were being virus scanned despite the original being in plain text. I've also noticed that there are a couple hundred E-mails a day in the backup's BadMail directory for locally hosted domains with non-existant accounts.  I'm only hosting about 300 accounts in total, and this is all to just those addresses and not the gatewayed domains.  Address validation would stop these needless bounces to forged addresses from my servers and help to clean up the Internet. I have a feeling that the need for CMDSPACE detection falls far short of the need for address validation for gatewayed domains.  ORF seems to be a great tool for this because I can do things like configure a local RBL for instance to block virus sending machines on the gateway by maintaining a single zone, along with sender and recipient blacklisting.  ORF of course is a very limited spam blocking tool at the moment and not appropriate for such needs. I'm still thinking about approaching IMail for a solution to recipient blacklisting on gatewayed domains using an 'everything but' methodology.  How unrealistic do you think that would be???  It might just be easier to ask VAMSoft for CMDSPACE header logging and dealing with the two separate pieces of technology. Matt Sanford Whiteman wrote: With a recent IMail release, you can now set up peering to use RCPT TO to test incoming messages for valid senders. Right, but the resulting envelope behavior is not different from the old VRFY scenario, AFAIK. As long as IMail does envelope rejection for peered domains that fail validation, this setup should work. There's never been real-time validation and rejection with peering. With just IMail servers, the idea is that a message can enter a "farm" of peers and will only be bounced (not rejected) after the message has been spooled and delivery attempted at every peer. Once you add an MS SMTP server into the mix, you only have one-way peering. Maybe I'm not clear on what you're suggesting, but I don't see it shedding any light on your issue. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/ --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================