The method behind the madness
in [Postfix]
|
From: /dev/rob0 on 18 Jan 2010 13:27 On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote: > But my primary issue is sender validation. I don't see how, > currently, to implement this as a policy daemon without re-writing > sender validation into the policy daemon. Right, IIUC what you're doing, you would have the policy daemon do this. > I don't see any way, for example, to call another policy daemon > after permit_sasl_authenticated returns "OK". Right, you would not use permit_sasl_authenticated, just have the check_policy_service in place of this. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
From: Victor Duchovni on 18 Jan 2010 13:37 On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote: > But my primary issue is sender validation. I don't see how, currently, to > implement this as a policy daemon without re-writing sender validation into > the policy daemon. I don't see any way, for example, to call another > policy daemon after permit_sasl_authenticated returns "OK". This thread is NOT about address validation, it is about automatic whitelisting of addresses (as senders) that are observed in outgoing mail as recipients. No validation is required. A robust solution is a content filter or milter that inspects the outgoing message, and ignores out-off-office messages and other auto-replies, whitelisting only "real" email. I also think that such whitelists should be for a given pair of correspondents, rather than all mail from the sender in question. You could also consider a sync of internal users' contact databases into the whitelist, at which point, you can do away with any observation of traffic, and just whitelist senders who appear in recipients' contact lists. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: <mailto:majordomo(a)postfix.org?body=unsubscribe%20postfix-users> If my response solves your problem, the best way to thank me is to not send an "it worked, thanks" follow-up. If you must respond, please put "It worked, thanks" in the "Subject" so I can delete these quickly.
From: "Daniel L. Miller" on 18 Jan 2010 13:44 /dev/rob0 wrote: > On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote: > >> But my primary issue is sender validation. I don't see how, >> currently, to implement this as a policy daemon without re-writing >> sender validation into the policy daemon. >> > > Right, IIUC what you're doing, you would have the policy daemon do > this. > > >> I don't see any way, for example, to call another policy daemon >> after permit_sasl_authenticated returns "OK". >> > > Right, you would not use permit_sasl_authenticated, just have the > check_policy_service in place of this. > Which is something I DON'T want to do - why re-invent the wheel, duplicate the effort, increase processing time - and presume my security check code comes close to the integrity of core Postfix? -- Daniel
From: "Daniel L. Miller" on 18 Jan 2010 13:51 Victor Duchovni wrote: > On Mon, Jan 18, 2010 at 10:14:34AM -0800, Daniel L. Miller wrote: > > >> But my primary issue is sender validation. I don't see how, currently, to >> implement this as a policy daemon without re-writing sender validation into >> the policy daemon. I don't see any way, for example, to call another >> policy daemon after permit_sasl_authenticated returns "OK". >> > > This thread is NOT about address validation, it is about automatic > whitelisting of addresses (as senders) that are observed in outgoing > mail as recipients. No validation is required. > Correct - however my question is how do I determine what is "valid outgoing mail" using built-in Postfix processes & methods? > A robust solution is a content filter or milter that inspects the outgoing > message, and ignores out-off-office messages and other auto-replies, > whitelisting only "real" email. I also think that such whitelists should > be for a given pair of correspondents, rather than all mail from the > sender in question. > Great points, and as we delve deeper into this I'm sure there are other items we'll either want to consider or at least have the option for. But the key to the whole thing is getting that recipient/sender information to the whitelist writing daemon in a manner that works WITH Postfix - and so far the methods I've looked at work around or against Postfix. > You could also consider a sync of internal users' contact databases into > the whitelist, at which point, you can do away with any observation of > traffic, and just whitelist senders who appear in recipients' contact > lists. > A point - and a good one for initialization of the whitelist. However, this does not address the need to add new addresses to the list automatically. Example - our company changes insurance brokers, and needs to receive forms from the new broker. Such communications should not be reliant on the IT department "unlocking" the mail server - just the act of the office manager's sending an e-mail to the broker should be sufficient. -- Daniel
From: Stan Hoeppner on 18 Jan 2010 14:27
Daniel L. Miller put forth on 1/18/2010 12:51 PM: > A point - and a good one for initialization of the whitelist. However, > this does not address the need to add new addresses to the list > automatically. Example - our company changes insurance brokers, and > needs to receive forms from the new broker. Such communications should > not be reliant on the IT department "unlocking" the mail server - just > the act of the office manager's sending an e-mail to the broker should > be sufficient. Daniel, it seems you're looking for feature perfection in rev. 0.1.1 of an as yet created home brew software solution. Do you think you might be setting your sights a bit high? Is this because you already have a solution that does all these things perfectly, and you're _expecting_ your new home brew solution to do the same right from the start? If you _need_ a home brew solution _now_, start small and inelegant, getting most of the functionality you want/need. This can be done with simple scripts and cron. After it's working relatively well, _then_ spend time creating the "elegant" solution. JMHO. -- Stan |