In message <20140821215806.gx23...@harrier.slackbuilds.org>, /dev/rob0 <r...@gmx.co.uk> wrote:
>I wouldn't recommend this, because many spam zombies access the >sender/victim's MUA settings, and they spew to addresses in the >address book, AS the sender/victim. But I'm sure you know this. I do, and I do not think that the phenomenon you have described renders the general idea of automated whitelist maintenance entirely un-useful. Certainly if the evil spammers manage to get into the address books of any of my personal correspondants, then (with automated whitelisting) they could then spoof those people in order to spam me. But I do think that this would be more the exception than the rule, and also, in case it was not already apparent, a "good" automated whitelist system should include some sort of "revocation" feature, in order to allow for exactly such unfortunate (but rare) possibilities (and others). >To me, this sounds more like a policy service feature (or that it >should be, I mean.) Check the SASL username and sender address, to >whitelist the recipient's reply. That sounds about right to me. >I don't know if any of the existing projects (such as cbpolicyd or >postfwd) can do this easily, but it shouldn't be hard to add. So, nothing already exists along these lines? Regards, rfg P.S. There are certainly sites... mine included... that eschew the complexity of SASL and find in utterly unnecessary and superfluous in the limited local context. (Trust, including the capability to send outbound, is, in my local context, limited to 127.0.0.1 and the RFC 1918 addresses.) I only mention this to emphasize that an optimal solution... should anyone be motivated to venture forth and create one... would not and should not assume that local senders/recipients will be "logging in" to the local mail server (e.g. via SASL).
