Good catch! Len, is the reject_unverified_recipient a snapshot feature? Are you saying that you can configure Postfix to hold an inbound message while checking the IMail server to see if the recipient address is valid or not before accepting delivery of the message by implementing the reject_unverified_recipient feature?
So if IMail responds 550 user does not exist, Postfix will send a 550 user does not exist to the sending mail server, and if IMail responds that the users does exist, then Postfix will receive and relay the message to IMail? If this is correct, does Postfix query IMail every time it receives a message for the same user on the IMail server or does it store the result of the first query in a local database that has some expiration rule applied to it? If this is all correct, that's very cool. How has this feature been working for you? Sorry for all of the questions and thanks for any feedback you can provide. Or, if you can point me to some online documentation, that would be fine, as well. Thanks, Bill ----- Original Message ----- From: "Len Conrad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 07, 2003 1:21 PM Subject: [IMGate] bug in Imail for peer http://support.ipswitch.com/kb/IM-20000901-DM01.htm This a really bad bug in IMail. If an Imail domain has the registry key for peer created, but the key is empty (in the registry and as shown "correctly" empty by GUI), the Imail will still accept all mail for any user in the domain and then bounce the mail. rcpt to:<[EMAIL PROTECTED]> 250 ok accepted for peer <[EMAIL PROTECTED]> !!!!!!!!!!!!!!!! But, peering is not really turned on for mydomain.com. Horrible vulnerability for dictionary attacks. I discovered this when setting up reject_unverified_recipient on IMGate. Imail was telling IMGate's recipient probe that every user for mydomain.com was ok, and then Imail accepted the real msgs, and then bouncing them as unknown user. 15K msgs in Imail's queue. Len
