Re: [reSIProcate] handling all IPs/breaks virtual hosting
On 02/08/12 03:49, Scott Godin wrote:
> I like the idea of only calling that code if you bind to INADDR_ANY
> (0.0.0.0). I suppose the condition would need to be that if any transport
> is bound to INADDR_ANY then run that code, otherwise just add all the
> specific IP addresses bound to each transport.
>
I don't mind making such a change, do you have any feedback about the
rest of that method?
I'm a bit suspicious of the way it adds `localhost' and `127.0.0.1' as
domains - probably not good in a pure-TLS environment either. There are
situations where localhost may appear in a SIP address from some
unrelated app (e.g. a Nagios probe testing if the proxy is alive) or
even some badly configured external host that has sent repro a packet
with localhost in the From header
It always adds the actual hostname of the machine where repro is running
I can imagine environments where these defaults might be useful, some
mail servers set themselves up in a similar way by default too. I'm
also not sure of the impact on existing users if this is changed heavily.
Do you think the test for INADDR_ANY is the only threshold for skipping
this code?
A more elaborate solution:
- we remove the localhost/127.0.0.1 stuff and add them to `Domains' in
the default repro.config, so that the sysadmin can see this explicitly.
postfix works that way, localhost must be listed in main.cf. Existing
users would have to update their repro.config
- if all transports are TLS, then
- it doesn't add the machine hostname (it only uses the TLSDomainName
value(s))
- it doesn't scan the IP addresses
- if there are non-TLS transports, but no transport binds to INADDR_ANY,
it doesn't scan IP addresses, it just adds the bound addresses
and at the risk of being slightly disruptive, a more aggressive change,
making it more like postfix:
- ONLY the TLSDomainName values will be served by default
- sysadmin MUST add all desired values to `Domains' in repro.config -
install scripts (e.g. on Debian) can try to guess the values and
generate repro.config, but at least it will be explicit what values are
being served
We could also do this change in stages: the less aggressive approach on
the 1.8 branch, the more aggressive approach in trunk and eventually 1.9