Joshua Megerman wrote:
I just tested and that's not what actually happens - it takes the best
match. So there is one potential problem with this (though I consider it
minimal) - if you have a rule that doesn't include the 'RELAYCLINET=""'
and/or 'RBLSMTPD=""', you may end up getting denied if you're depending on
pop-before-smtp. However, IMHO SMTP-AUTH should be used instead as it's
both more reliable and more secure, but not everyone pushes that. So
there may be unintended consequences with this patch...
I think the consequences are - If you explicitly deny access, or
relaying to an address or address range, a pop connection will no longer
allow the connection to relay. It is probably very rare, and might
even be considered a good thing.
I'm not sure how to best address it, but I see 3 choices: 1) exclude the
patch from the main tree but publish it as an add-on (not great); 2)
include the patch and document the changes in how the CDB is built and
works (better, but may cause breakage for some people); or 3) put the code
inside an #ifdef and make it a configure option (I'd enable it by default,
but it could go either way).
I'm partial to 2, but hope to hear what others think. I'd rather not
add any more configure options, [1] so if it is considered too dangerous
to have enabled full time I'd rather leave it as a patch, and maybe add
it to the contrib directory. On the other hand, how many people are
depending on pop before smtp from otherwise blacklisted addresses, that
couldn't switch to smtp auth? How many are still using pop before smtp
at all? I haven't supported it for a couple of years.
Do you want to write the README text for this patch?
Rick
[1] I hope no one is under the delusion that all permutations of the
existing ./configure switches are tested before a new release!
