Michael Scheidell wrote:
One thing I would like to see (and this is a different subject:
Marc: take note: Id like to NOT BOUNCE an email back to the victim of
backscatter if they bothered to publish SPF or SENDER ID records that
don't match the incoming.
It's the other way around. you should only bounce if you can be sure the
sender was not forged. So, if there is no SPF record, or if the SPD
record allows the whole universe (or a significant part of it:), then
you must not bounce.
anyway, SPF penetration is too low to change anything to the problem
here. same for DKIM for now.
(and, yes, this would NOT work behind a proxy)
I would like the proxy to at LEAST have a copy of the valid userlist,
This would be a good start.
NOT muck with the headers.
MAYBE do its load balancing via bridging rather than store forward.
this is not easy to do:
- most IP stacks do not allow you to bind to an external IP. so you
would need adding dynamic NAT routes (and even this is not that simple,
because you need different NAT rules for different connections, so you
the proxy needs to bind to a port before adding the NAT rule and before
doing a connect()).
- in any case, the proxy needs to be modified (in a modified stack, it
would just bind to the client IP. in a standard stack, it should do the
above).
- the final server must route back packets through the proxy machine,
probably with a default route. but then you must ensure no host that is
not routed this way will not connect to the proxy (there's no
"conference" in TCP).
- any intermediary routers/gateways/... should keep this traffic going
between the proxy and the final server.
it would certainly be easier to modify the proxy to fix the real problem
than try to convert it into a "bridging proxy" (I don't like
"transparent proxy" term: there are many levels of transparency).
That might fix a lot. But then again, it would be easier to replace the
proxy than fix it.
yes. fixing problems introduced by legacy applications is often harder
than solving the real problems (and getting rid of the legacy apps)...
Unfortunately, there's much "feeling" and "confidence" issues when
trying to convince the customer to take another road (and sometimes, the
customer representative will resist the change because he did not
suggest it, or because he can no more justify a lost budget).
