Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote: Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ The situation is that domain.fr is relaying mail through their provider, which has a number of smtp servers named smtpNN.orange.fr. If I were to stick to the current whitelist_from_rcvd, I'd only be able to do: whitelist_from_rcvd [EMAIL PROTECTED] orange.fr But that opens to emails from domain.fr also being accepted when sent from e.g. ADSL and dial-up lines on orange.fr. I think actually it would be wanadoo.fr in this case, Indeed. they use .abo.wandoo.fr (abo stands for abonné, french for subscriber). even if they switch to orange.fr, I guess they would use .abo.orange.fr or something like that (but this would not be a small change, so I don't se it coming in the short/medium term). BTW. Since few years, Orange.fr have started blocking port 25. not yet complete though. (the few I've seen lately are listen on zen and sorbs). but you get the idea. yes. Has anyone already looked at this?
Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote: Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ One problem.. That involves a regex, but whitelist_from is a regular user config option. In general, regular expressions are intentionally not used in regular user options due to the potential for a to possibly exploit the system. (this is why user_prefs can't contain rules unless you define allow_user_rules). So, SA actually went out of its way to prevent that from being allowed.
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 02:38:22PM +0100, Per Jessen wrote: Henrik K wrote: On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. I prefer to use that only for our own networks. That I whitelist one domain from a certain server(s) doesn't mean I want to whitelist everything. Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 Perhaps it could even work with hostnames as long as they stay inside trusted_networks. And perhaps it could support basic wildcards instead of regexps.
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: On Fri, Nov 07, 2008 at 02:38:22PM +0100, Per Jessen wrote: Henrik K wrote: On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. I prefer to use that only for our own networks. That I whitelist one domain from a certain server(s) doesn't mean I want to whitelist everything. Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 why? I wouldn't put 30 IPs there... if user trusts his MTA, then rdns can be trusted, and there is no point to go the IP way (note that if user doesn't trust MTA, then the IP can't be trusted...). Perhaps it could even work with hostnames as long as they stay inside trusted_networks. why link that to trusted_networks? And perhaps it could support basic wildcards instead of regexps. That's probably the best option. That said, it is not very satisfactory. mixing perl regexps and globbing comes as a surprise to pcre users...
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 Should this be read to mean whitelist from foobar if it came via 1.2.3.4 AND 2.3.4.5? That's an interesting option, but I can't see much immediate use. Maybe when I've thought about it for a bit. Perhaps it could even work with hostnames as long as they stay inside trusted_networks. I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? And perhaps it could support basic wildcards instead of regexps. I appreciate Matts explanation about whitelist_from_rcvd being a regular user option, so maybe the right way would be a whitelist_from_rcvdregex ? /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 03:07:59PM +0100, mouss wrote: Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 why? I wouldn't put 30 IPs there... if user trusts his MTA, then rdns can be trusted, and there is no point to go the IP way (note that if user doesn't trust MTA, then the IP can't be trusted...). Perhaps it could even work with hostnames as long as they stay inside trusted_networks. why link that to trusted_networks? Obviously the whole IP path must be trusted (excluding the last one). You can use hostnames as well. But then you have to have trust path right, to trust later hostnames. And perhaps it could support basic wildcards instead of regexps. That's probably the best option. That said, it is not very satisfactory. mixing perl regexps and globbing comes as a surprise to pcre users... Isn't the sender part globbed already? ;)
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: Henrik K wrote: Then instead of asking for a lacking addition to a poor whitelisting method (in this case), we should enhance whitelist_from_rcvd to process received paths: whitelist_from_rcvd [EMAIL PROTECTED] 1.2.3.4 2.3.4.5 Should this be read to mean whitelist from foobar if it came via 1.2.3.4 AND 2.3.4.5? That's an interesting option, but I can't see much immediate use. Maybe when I've thought about it for a bit. Yes. Perhaps it could even work with hostnames as long as they stay inside trusted_networks. I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust would go from hostname to hostname, so it's ok. :) Too little time to think. And perhaps it could support basic wildcards instead of regexps. I appreciate Matts explanation about whitelist_from_rcvd being a regular user option, so maybe the right way would be a whitelist_from_rcvdregex ? IMO the right option is wildcards. You might as well ask then, why can't the sender part be regexed for convienence..
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 04:20:17PM +0200, Henrik K wrote: On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust would go from hostname to hostname, so it's ok. :) Too little time to think. IMO the right option is wildcards. You might as well ask then, why can't the sender part be regexed for convienence.. One thing I still have to add. IPs are a pretty foolproof way to whitelist. With hostnames there is a bigger change of failure (by just using a domain instead of exact hostname, letting f.e. dialup users from the domain forge the path).
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. I prefer to use that only for our own networks. That I whitelist one domain from a certain server(s) doesn't mean I want to whitelist everything. Nothing prevents zombies sending through smarthosts anyway, Exactly. that's much more secure in the long run. And you should be dropping dialups at MTA anyway. That's surely up to me. /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
Per Jessen wrote: Matt Kettler wrote: Per Jessen wrote: Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ One problem.. That involves a regex, but whitelist_from is a regular user config option. In general, regular expressions are intentionally not used in regular user options due to the potential for a to possibly exploit the system. (this is why user_prefs can't contain rules unless you define allow_user_rules). So, SA actually went out of its way to prevent that from being allowed. Yes, I saw that in the code I've been reading some more and it looks like it is actually possible to use regex syntax in the domain part of whitelist_from_rcvd. The address part is sanitized, but the domain part isn't. /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: why link that to trusted_networks? Obviously the whole IP path must be trusted (excluding the last one). You can use hostnames as well. But then you have to have trust path right, to trust later hostnames. maybe I misunderstood your could even work And perhaps it could support basic wildcards instead of regexps. That's probably the best option. That said, it is not very satisfactory. mixing perl regexps and globbing comes as a surprise to pcre users... Isn't the sender part globbed already? ;) yes it is. I was about that!
Re: enchanced whitelist_from_rcvd ?
Henrik K wrote: On Fri, Nov 07, 2008 at 04:20:17PM +0200, Henrik K wrote: On Fri, Nov 07, 2008 at 03:09:29PM +0100, Per Jessen wrote: I'm not sure I like the ideas of whitelisting based on IP-addresses, it's too inflexible. Why would you not use hostnames? Hmm.. ok I think you both (mouss) are right. Ignore my last post. The trust would go from hostname to hostname, so it's ok. :) Too little time to think. IMO the right option is wildcards. You might as well ask then, why can't the sender part be regexed for convienence.. One thing I still have to add. IPs are a pretty foolproof way to whitelist. sure, IPs don't suffer dns temp failures, but when I intend to trust *.gandi.net, I really want to trust *.gandi.net, not resolve that one day, then have gandi add new relays that I don't trust, or even worst, having the IP assigned to another organization. and if you mean forged PTRs, then any software that trusts the PTR without actually resolving it back to the IP is bogus. Those of us running real MTAs don't have to suffer from such descrepancies. of course, it is theortically possible to forge the name and attack DNS so that it fully resolves, but in that case, a lot of other stuff would break anyway (for good or for bad, we rely on dns too much). With hostnames there is a bigger change of failure (by just using a domain instead of exact hostname, letting f.e. dialup users from the domain forge the path). not sure I understand. people can't easily forge their rdns (in the sense: FcrDNS. PTR alone is useless), and if they can, then they can do other dns attacks making all dns based checks useless. if you mean forging Received headers, well, that's not a problem as long as the relay path is correctly parsed (don't trust infos beyond last trusted received header).
Re: enchanced whitelist_from_rcvd ?
Matt Kettler wrote: Per Jessen wrote: Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ One problem.. That involves a regex, but whitelist_from is a regular user config option. In general, regular expressions are intentionally not used in regular user options due to the potential for a to possibly exploit the system. (this is why user_prefs can't contain rules unless you define allow_user_rules). So, SA actually went out of its way to prevent that from being allowed. Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. /Per Jessen, Zürich
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 04:45:57PM +0100, mouss wrote: With hostnames there is a bigger change of failure (by just using a domain instead of exact hostname, letting f.e. dialup users from the domain forge the path). not sure I understand. people can't easily forge their rdns (in the What I meant was more of a configuration error from admin. ;) I.e. whitelist_from_rcvd [EMAIL PROTECTED] orange.fr domain.wl We already know this is a bad way (maybe dynamic orange users) even currently. I don't know if there is much chance of second+ level failure, it could be overlooked more easily: whitelist_from_rcvd [EMAIL PROTECTED] smtp*.orange.fr domain.wl Maybe domain.wl has dynamic users or some other bad servers? Who knows. I agree it's a bit far fetched and easily corrected when spotted. Maybe there could be even an failsafe option to detect bad received hosts. I probably would start using this if implemented. Hostname support also in trusted_networks would be especially handy. Good ideas, too little time to code..
Re: enchanced whitelist_from_rcvd ?
On Fri, Nov 07, 2008 at 02:22:08PM +0100, Per Jessen wrote: Matt Kettler wrote: Per Jessen wrote: Occasionally I'd like to do something like this: whitelist_from_rcvd [EMAIL PROTECTED] /^smtp[0-9]+\.orange\.fr$/ One problem.. That involves a regex, but whitelist_from is a regular user config option. In general, regular expressions are intentionally not used in regular user options due to the potential for a to possibly exploit the system. (this is why user_prefs can't contain rules unless you define allow_user_rules). So, SA actually went out of its way to prevent that from being allowed. Yes, I saw that in the code - still, having a whitelist_from_rcvdregex would be very useful, people relay via their providers quite a lot. I guess I'll have to write something up. If the originator is static IP, add whole path to trusted_networks and use ALL_TRUSTED. Nothing prevents zombies sending through smarthosts anyway, that's much more secure in the long run. And you should be dropping dialups at MTA anyway.
