Eric Wilkison: > Thank you for the input. > > Our virtual alias files are script generated and updated periodically. > I had considered adding a map for each user for each of the domains. > However, we have about 80 domains. That times our 30k users and > we'd have almost 2.5 million aliases. Seems like a very large list > that could cause performance issues under load. Would you agree?
That depends on how one does it. But, in order to accept mail for valid recipients, the perimeter Postfix MTA needs to know what is valid, or have a way to discover what is valid, such as reject_unverified_recipient. > I had also considered using validation, but one of the mail systems > we are delivering to is behind yet another relay that does not > reject unknown users. We could potentially set up a validation > transport to work around it, but internal political concerns would > make that solution difficult. Too bad, I can't help you with the non-technical issues. > Doing more research yesterday I came up with another possible > solution I'd like to get your opinion of. What do you think of > using smtpd_command_filter to dynamically update the recipients. > Something like: > > /^RCPT\s+TO:\s*(.*)@example\.\b(in|cn|us)\b(>*)/ RCPT TO:[email protected]$3 Assuming that this will block all invalid addresses, a minor downside I see is that any delivery errors will report the modified recipient address. One cannot simply append an ORCPT=whatever parameter to the RCPT TO command, because RFC 3461 requires that the ORCPT value be properly encoded, and I cannot recommend doing that with regular expressions. > This seems to work form my initial testing. Would there be any > issues that I'm not seeing using this solution? Any corner cases > that the regex would not handle well? If every valid [email protected] is also valid as [email protected], then that would work. Wietse
