John Peacock wrote: > Yes it does. I can only speak for myself, but I don't have anything in > the locals file except for the machine name (since I run vpopmail for > all domains). I suspect most people are running virtual domains, so I > don't /think/ there is much call for splitting locals from rcpthosts. > YMMV...
Yes, I actually keep local mail on my own (small) server. It was an idea, but since the plugins split, I will just do an equivalent 'rcpt_ok' that goes against 'locals' instead. It fits in well; any mail that is local can be DENYed authoritatively, and it will decline otherwise. In the meantime, I'll just use my old version of the code that works. > However, I have dealt with the non-local addresses in a slightly > different way. Our inbound MX boxes don't have any local accounts and > simply relay the accepted mail on the to the actual server(s). I > validate all e-mail addresses through a custom plugin that has undergone > several iterations: <SNIP> Unfortunately, the majority of the machines I'm performing secondary MX service for are Exchange boxes. I just wanted to make sure I didn't incorrectly bounce any of their mail. If I/they really wanted, I could simply do LDAP searches against their servers for their domains as I do for my own, but I don't think the effort would be worth it, especially opening up a windows server that is live on the net. LDAP has become quite handy though, especially since microsoft thought they would come up with a version of their own. I could use the same plugin for exchange that authenticates against my sun directory. Another method (and a very scalable one) would be to store user data in DNS. If you've got your user data in some sort of store (DB/LDAP/whatever), it would be fairly easily to export it to a zone (bind/tinydns) file. You could then create a subdomain for the domain (users.example.com) with valid users as further subdomains (jdoe.users.example.com, with a TXT record storing their mail server?) You could use hesiod for that matter. It could take advantage of the caching architecture that DNS has, and you would simply need to restrict access by IP. It'd probably be the fastest/most scalable way to do it, I think. > Additionally, it should be possible to rewrite queue/smtp-forward to use > the smtproutes to directly relay mail to any server you are secondary > for (ala a proxy). This would allow you to authoritatively refuse any > mail that doesn't correspond to a valid user (as long as the remote > server is up and active) and only queue (and possibly later bounce) > messages where you aren't sure are valid. Right now, you may be > bouncing more messages than you strictly need to... If you're referring to DSNs, I've effectively curbed them by storing my users in LDAP. If you're referring to bounces being false positives of "no such user" on non-local domains, I'm only bouncing mail that is actually local to my machine, which is why I broke the plugins apart, as I'm processing 'locals' independently from 'rcpthosts' addresses. The queue/smtp-forward is a really good idea, but if I'm recieving the message, that means the primary MX (their server) is down. The domains aren't very large, so spammers haven't (so far) taken much notice of them (and haven't spammed me because I'm secondary.) If you're speaking from an infrastructure perspective, this is a pretty good idea, especially if you're doing routing for a heterogeneos pool of mail servers with no unified/consistent user information store.
