John Peacock wrote: > Elliot F wrote: > >> Another method (and a very scalable one) would be to store user data >> in DNS. > > > Ooh, don't suggest that sort of thing on a DNS admin list unless you > really like having a cheese grater rubbed on all your private parts. > That is a gross violation of the design of DNS (but of course I can > think of an elegant way to do it with a tinydns instance ;-).
Exactly why I said tinydns. DNS would have a much lower overhead than LDAP, and much cleaner caching methods (than LDAP.) How is it a gross violation of DNS? It would depend entirely on the implementation. It could be done very cleanly, assuming you don't try to get too fancy with it (storing AUTH information, for example.) >> 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. > > > Actually, once the spammers take notice of the domains, you will find > that they will preferentially target the secondary MX records, on the > (in this case correct) theory that they will be less strictly configured > in terms of user validation. And you'll wind up being the source of > spam blowback, since you will accept the message and be unable to relay > it to the primary, hence you will have to bounce it. Exactly why I said that the spammers haven't taken much notice so far (see above.) It is, however, a good way for small-ish domain to create a smamtrap, assuming the primary/secondary MXes are reliable.
