SRS implementation
in [Postfix]
|
From: Wietse Venema on 21 May 2010 16:13 Tomoyuki Murakami: > Hi, all > > I'm just playing with implement SRS(Sender Rewriting Scheme)-like > function into Postfix. > *SRS - http://www.openspf.org/SRS > A trivial patch, attached this message would do the following. > * rewrite sender when the message will forward to other site/domain. > * Nope when the VERP setting is active. > * rewriting format: > Message sender: orig_sender(a)domain.com (sender) > Forwarder: forwarder(a)my.dom (orig_addr) > -> MAIL From: forwarder+orig_sender=domain.com(a)my.dom > * target transport is smtp only. > > ToDo. > configurable options to activate the function, target transports, > target domains, etc. > > Any comments would be appreciated. First, this would accept mail for forwarder+ANYUSER=ANYDOMAIN(a)my.dom, meaning that it would be an open relay. A more secure implementation would compute a hash of (orig_sender(a)domain.com, local secret) and include that hash in the return address. Second, Postfix has a plugin interface that supports implementations SRS, SPF, DKIM, SenderID, etc. I currently have no plans to build these into Postfix. Wietse
From: Tomoyuki Murakami on 21 May 2010 23:44 Hi, Wieste, Thanks for reply. From: Wietse Venema <wietse(a)porcupine.org> Subject: Re: SRS implementation Date: Fri, 21 May 2010 16:13:45 -0400 (EDT) > First, this would accept mail for forwarder+ANYUSER=ANYDOMAIN(a)my.dom, > meaning that it would be an open relay. A more secure implementation > would compute a hash of (orig_sender(a)domain.com, local secret) and > include that hash in the return address. I guess, with my patch alone, could not cause open relay, but ... when someone implement the functions for bounce or DSN to the ANYUSER(a)ANYDOMAIN address derived from that SRS'ed sender unconditionally, this would be the case, isn't it ? Or, something else I could missed here (as usual ;-p). > Second, Postfix has a plugin interface that supports implementations > SRS, SPF, DKIM, SenderID, etc. I currently have no plans to build > these into Postfix. OK, I'd like to consider these lines too. Thanks, --- Tomo.
From: Wietse Venema on 22 May 2010 09:35 Tomoyuki Murakami: > > First, this would accept mail for forwarder+ANYUSER=ANYDOMAIN(a)my.dom, > > meaning that it would be an open relay. A more secure implementation > > would compute a hash of (orig_sender(a)domain.com, local secret) and > > include that hash in the return address. > > I guess, with my patch alone, could not cause open relay, but ... It is an open relay. To exploit: send mail to postmaster+ANYUSER=ANYDOMAIN(a)my.dom where my.dom is your domain, and Postfix will deliver it to ANYUSER(a)ANYDOMAIN. > > Second, Postfix has a plugin interface that supports implementations > > SRS, SPF, DKIM, SenderID, etc. I currently have no plans to build > > these into Postfix. > > OK, I'd like to consider these lines too. There is a famous book called the "mythical man-month" by Fred Brooks. In figure 1.1, it shows four categories of software. - The simplest is an "in-house" program that solves a specific problem. This is like hard-coding DKIM or SRS into Postfix. There is nothing wrong with building something into a program, but each time you do this, it will be a little harder. - Three times as expensive is a programming product that is documented, testable, and maintainable. About half of the Postfix source tree is documentation and test programs/data, but especially the tests are incomplete. - Also three times as expensive is a programming system that has interfaces that work with other systems. This is like Postfix's Milter and Filter interfaces, Postfix table lookup based on files, LDAP, *SQL, NIS, the ability to use "postconf -e" to update configurations mechanically, etc. - Postfix is in the nine times as expensive category: it is mostly a programming system product. Wietse
From: Tomoyuki Murakami on 24 May 2010 00:22 From: Wietse Venema <wietse(a)porcupine.org> Subject: Re: SRS implementation Date: Sat, 22 May 2010 09:35:29 -0400 (EDT) > Tomoyuki Murakami: >> > First, this would accept mail for forwarder+ANYUSER=ANYDOMAIN(a)my.dom, >> > meaning that it would be an open relay. A more secure implementation >> > would compute a hash of (orig_sender(a)domain.com, local secret) and >> > include that hash in the return address. >> >> I guess, with my patch alone, could not cause open relay, but ... > > It is an open relay. > > To exploit: send mail to postmaster+ANYUSER=ANYDOMAIN(a)my.dom where > my.dom is your domain, and Postfix will deliver it to ANYUSER(a)ANYDOMAIN. oops! I could't find such a decoding mechanism, i.e. postmaster+ANYUSER=ANYDOMAIN(a)my.dom to ANYUSER(a)ANYDOMAIN in the Postfix souce. Is this realized in bare Postfix with specific configuration or cooperation with its plug-ins ? For my previous patch, just rewriting sender one-way and it may be `in-complete' in the meaning of implementing SRS. If there exists extracting function from SRS-ish (VERP ?) to original sender address in the current Postfix code, I'd like to learn about that for, either choosing any existing plug-ins or home-brewing yet-another-SRS plug-in, mainly looking into security sufficiency of its required hash mechanisms. --- Tomo.
From: Wietse Venema on 24 May 2010 06:54 Tomoyuki Murakami: > > Tomoyuki Murakami: > >> > First, this would accept mail for forwarder+ANYUSER=ANYDOMAIN(a)my.dom, > >> > meaning that it would be an open relay. A more secure implementation > >> > would compute a hash of (orig_sender(a)domain.com, local secret) and > >> > include that hash in the return address. > >> > >> I guess, with my patch alone, could not cause open relay, but ... > > > > It is an open relay. > > > > To exploit: send mail to postmaster+ANYUSER=ANYDOMAIN(a)my.dom where > > my.dom is your domain, and Postfix will deliver it to ANYUSER(a)ANYDOMAIN. > > oops! I could't find such a decoding mechanism, i.e. > postmaster+ANYUSER=ANYDOMAIN(a)my.dom to ANYUSER(a)ANYDOMAIN > in the Postfix souce. Is this realized in bare Postfix with > specific configuration or cooperation with its plug-ins ? > > For my previous patch, just rewriting sender one-way and it may > be `in-complete' in the meaning of implementing SRS. Indeed. A complete SRS implementation forwards mail in both directions. To avoid being an open relay, it must use some secret to "sign" the SRS-transformed address. This is one reason why SRS should not be implemented with VERP. Wietse
|
Pages: 1 Prev: which port to use for SSL/TLS? Next: 451 4.3.5 Server configuration problem |