Re: Marc: use SPF to prevent backscatter? Was RE: [AMaViS-user] Q about mail proxy servers and setups

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). Received on Mon Sep 24 08:42:40 2007

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related spamassassin.apache.org Links users Request more information about Pantek