Gavin Carr wrote: > But it's very hard to give particular examples that make sense. This is > a particularly bad example, for two reasons: > > - most people will NOT want to whitelist senders for relaying because > it's way too easy to forge - that's why it's not there in relay_ok. > You understand the tradeoffs now and are willing to accept the risk, > so that's fine - but telling people to do it in general is bad. > > - what you return only makes in the context of a particular hook, and > most of the time for whitelisting you'll be returning DECLINED. > rcpt_ok is a very special case, which is why it returns OK. But you > return OK in the wrong place in a random plugin and you'll break > things or open up security holes. > > So when to whitelist is a policy decision, and how to do it requires > a bit of knowledge about where you're doing it in the plugin and the > SMTP conversation. > > I'm not just trying to be difficult - I'd rather people ask on the > mailing list than just cut and paste examples and get themselves into > trouble.
OK. here are my next questions. * We want to whitelist in such a way that we don't have to modify every plugin. If a message is whitelisted then the module that is calling the rest of the plugins should skip calling them. (Two reasons: performance and forking plugins is not good). I know some people are going to have objections to this and I'm sure it has been discussed to death. A small synopsis of the pros and cons of this approach would be nice. Perhaps there is a page on the wiki? Since none of the plugins know about whitelist anyway there seems to be little point in running them after whitelisting an message. In addition, this is a temporary solution until I can get the systems and users migrated to other ports and authenticated relay. Modifying all other plugins temporarily is a waste of time. * What is the point of using whitelist_soft if it doesn't do anything but flag messages? This is from the pod: "This is a more conservative approach e.g. whitelisting an IP will not automatically allow relaying from that IP." Then what does it mean to whitelist an IP? If the only thing the whitelist plugin does is set a flag for other plugins to use then it shouldn't be called whitelist. A better name would be set_flag, custom_flag, or something like that. * Can I have the whitelist_soft plugin return OK at each stage? Will that allow the process to work as I want. Right now whitelist_soft is returning OK at mail and DECLINED at rcpt. Thank you, -- JT Moree