Le 31/01/2011 01:17, Daniel Bromberg a écrit : > Brilliant, reject_sender_login_mismatch is the perfect level of > flexibility and is working now. I can add whatever authorizations I > need to my virtual user table in the DB, in a separate column if need > be. (right now I'm using the trivial match of <authorized names> = <the > login name>) > > Importantly, if it's not a SASL-based session no such authorization > check is done, rather the usual "you're a stranger, for local delivery > only" rules apply there.
you need to read what reject_sender_login_mismatch does. - it won't prevent internal users from using an external sender address (unless you return some invalid login for external addresses, but then that also applies to external users!). - it also applies to non authenticated mail. reject_authenticated_sender_login_mismatch is the variant that only applies to authenticated mail. > So, I don't need to have a separate ruleset, as > this rule already has the proper granularity. > > Conceivably, someone could hack a non-standard e-mail client to use the > SASL name in the MAIL FROM, but tweak the 'From: ' line to anything they > like (although the MAIL FROM would appear in the Return-Path / Sender > fields), and this is harder to stop, correct? But we are in rare corner > cases now, not ordinary users I would think. depends on which mail clients they use. some mail clients make that hard (they derive the envelope sender from the From: header). others make it easy. but motivated users can ask for help on the Internet... > >[snip]
