Fritz, Thanks for the advice but it's still pretty much the same behavior. Looks like the best way to keep them from figuring out your address space is not to use LDAP or any other form of recipient validation.
I wanted to do recipient validation because it could be used to assess penalty scoring against senders who scan for email addresses but it's not worth the risk. Not a big deal... I'm uncertain as to how much of an actual benefit could be realized anyway since spammers are spreading out attacks over such a wide range of IP addresses. - Phil ______________________________________________ Re: [Assp-user] Unknown Addresses cache not being used as spamtrapaddresses de From: Fritz Borgstedt <fb@iw...> - 2011-05-09 17:30 If you want correct handling of the SMTP-protocoll disable SpamTrap2NULL. If you do not want to be polite, make TrapReply empty. _____________________________________________ From: Phil Quesinberry Sent: Monday, May 09, 2011 12:06 PM To: '[email protected]'; '[email protected]' Subject: RE: Unknown Addresses cache not being used as spamtrapaddresses despite DoPenaltyMakeTraps setting Ok, I did some additional digging and this isn't handled correctly for addresses in spamtrapaddresses, either. What ends up happening: ASSP will reply to the originating MTA with "250 - Sender ok", but then never replies to the originating MTA's "RCPT TO" command. When sending a test message to one of these addresses, I eventually receive a "Delivery Notification: Delivery has been delayed" msg. after a day or so. Fritz, I can send you a Wireshark capture showing the relevant SMTP communications if desired, including where ASSP correctly handles known recipients as well as the incorrectly handled cases. Regards, - Phil _____________________________________________ From: Phil Quesinberry Sent: Friday, May 06, 2011 12:46 PM To: '[email protected]' Subject: Unknown Addresses cache not being used as spamtrapaddresses despite DoPenaltyMakeTraps setting Fritz, et al, FYI, When invoking Cache Unknown Addresses (DoPenaltyMakeTraps, default=use for spamaddresses) <javascript:void(0);> , for addresses collected via LDAP lookup failures, along with Move Connection with Trap Addresses to NULL (SpamTrap2NULL) <javascript:void(0);> , the collected trapaddresses are not handled the same way as trapaddresses manually populated via the Trap Addresses* (spamtrapaddresses) <javascript:void(0);> , even though DoPenaltyMakeTraps is set to "use for spamtrapaddresses". I can get around this problem by copying all of the collected addresses and stripping off the time/date stamp info, then copying them to the spamtrapaddresses list. Even though SpamTrap2NULL is checked, those addresses are given the error message contained within Trap Reply (TrapReply, default=550 5.1.1 User unknown: EMAILADDRESS) <javascript:void(0);> and not sent to NULL. Because of this, trying to work around the problem by changing TrapReply to 250 OK does not work properly. This allows spammers to search the domain's email address space for valid addresses. Phil Quesinberry Q Systems Engineering, Inc. Electronic Controls and Embedded Systems Development (410) 969-8002 http://www.qsystemsengineering.com ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
