Resurrecting an old thread here. We're finally migrating to Exchange 2013, and I have a script that will extract email addresses from ldap, but when looking at the virtualuser table it seems that it's used to map one address to another. The script puts out addresses in the following format: [email protected] OK [email protected] OK [email protected] OK
Easy enough to strip the "OK" out in a bash scritp to create the virtualuser table, but what does the virtualuser table actually look like? The preamble in the file in /etc/mail shows: # Examples: # #[email protected] foo-info #[email protected] bar-info #[email protected] error:nouser No such user here #[email protected] error:D.S.N:unavailable Address invalid #@baz.org [email protected] That's clear enough, but I'm not mapping one address to another - I'm just wanting to validate the entries that are in there. Do I just create a single column file with the output from my ldap query script and hash it? And after that sendmail will reject anything not in there? Do I have to tweak sendmail.mc beyond FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl to achieve the desired behavior of rejecting unknown inbound emails? I'm unclear on what "and combine them with a fixed file" means in Ted's comments below. Pearls of wisdom greatly appreciated... ...Kevin -- Kevin Miller Network/email Administrator, CBJ MIS Dept. 155 South Seward Street Juneau, Alaska 99801 Phone: (907) 586-0242, Fax: (907) 586-4500 Registered Linux User No: 307357 -----Original Message----- From: Ted Mittelstaedt [mailto:[email protected]] Sent: Wednesday, October 16, 2013 9:52 AM To: [email protected] Subject: Re: Exchange 2013 and rejection of invalid RCPTs (was Re: one word spam (continued)) Just be aware that Microsoft's "standard" is to use LDAP queries to the AD. Every major commercial antispam product does this and you will save yourself a lot of work later when MS changes the next version of Exchange to not support the 2525 hack. (which they could easily do) if you do it that way. This issue has been discussed to the death elsewhere but I guess for me I can't understand why I would have to -pay- for a milter like milter-ahead when on my prefilter Sendmail server I can simply once a day issue an ldapsearch to the domain controller the exchange server is in, then strip the results down to just the email addresses and combine them with a fixed file then replace the virtusertable. I can run clamav, and spamassassin on the prefilter and I don't have to fool with the ldap routing in sendmail or worry about uncontrolled access to the AD server. But I realize that's a "large company" approach to the problem and many people still want a single-server solution. Well wake up folks, Exchange is a "large company" product nowadays. We still have a few customers on honeymoons with exchange 2010 all-in-ones but they have all been given notice that Microsoft has provided no future roadmap for this approach. Go big or go elsewhere. Ted On 10/16/2013 10:27 AM, David F. Skoll wrote: > On Wed, 16 Oct 2013 09:21:46 -0800 > Kevin Miller <[email protected]> wrote: > >> So if I'm reading this right, milters such as smf-sav or milter-ahead >> will no longer be of any use? > > You are reading it correctly. On our anti-spam service, we require > some sort of recipient validation so we don't go insane scanning > messages destined to nonexistent addresses. SMTP call-ahead was the > easiest way to do this, but now our customers either have to let us > hook into their Active Directory or explicitly provide a list of valid > recipients. > > Someone did send me a hack for doing recipient verification on > Exchange 2013 which I include here for archiving purposes. Please > note that I have not tested this. I'm also not familiar with > Exchange, so some of the terminology means nothing to me... > > Regards, > > David. > > ====================================================================== > ==== > From: Leon Black > To: "[email protected]" <[email protected]> > Subject: Recipient Verification correction > Date: Sat, 7 Sep 2013 03:59:27 +0000 > > Hey Guys, > > Just saw your info on this page > http://www.roaringpenguin.com/recipient-verification re Exchange 2013 > recipient verification. > > I have found the workable solution with exchange 2013 to get recipient > verification working correctly with an antispam product. > > The problem is when it is a single server with CAS and Mailbox roles. > To use correct verification you need to talk to the hub transport > receive connector (mailbox role) and this rejects the address as per > normal. > > This is by default on port 2525, all you need to do is enable > anonymous access on the connector and open port 2525 to the antispam > IP. Set your product to do recipient verification on port 2525 and > deliver to port 25 and it works perfectly. > > Hopefully this information can help you guys out :) We do this with a > number of our exchange 2013 single server clients and it rejects > emails correctly. > > Oh! Just make sure they do not create another hub transport connector. > If there is an additional one it will cause exchange transport to stop > receiving emails after a few hours. >
