IPv6 is very unlikely to be a problem since I doubt that all handsets that support MMS support ipv6, but thought I should point it out!

in your example, what if the mmsc is 192.168.1.1?
What if it clashes with a local wlan address? what if the mmsc has the same IP address as wlan0?
what if the ppp interface obtains an IP address that matches a local wlan IP or host?
Overlaps are very bad.. I think this idea might solve many overlap problems..

I'll try to explain my thinking behind using netfilter.

wlan0 192.168.1.10/24 default gw 192.168.1.1

Now we connect to the MMS APN..

pppX 192.168.1.200 <=> 192.168.1.50
MMSC: 195.92.248.7

It *could* happen..
first problem. If the device is currently talking to 192.168.1.200 or 192.168.1.50 via WLAN, those two IP addresses are now present on two interfaces..
If the device is talking to www.orange.co.uk (which happens to have the same IP as the MMSC) which route does it use?

If we use the ipt_ROUTE module, we can direct traffic out of specific interface based on ipt matching.. which is fairly good..

With the suggesting I posted we've essentially given a partial split..
the phone is able to connect to 192.168.1.200, even though the ppp interface has this IP address. the phone is able to connect to the MMSC IP address via wlan0. I think with the additional rule, the phone could even talk to 192.168.1.50 via wlan0 EVEN though it is at the other end of pppX..

Now, for the MMS service (running as user mms-service) when it tries to connect to the MMSC, it is directed out of ppp0.. infact it is the only way to reach the mmsc via ppp0..

this is like a namespace solution, but hacky..

The overhead is low and it is using modules that can be added to Maemo with out changing the kernel!

Essentially, this technique might be a good basis for ensuring that specific processes are able to route and reach the mmsc via ppp0 whilst ALL other traffic, especially traffic that overlaps in IP address space routes via the default device (wlan0 or another ppp interface)

The vital thing here is to avoid clashes and since home networks use rfc1918 and operators use rfc1918 the chances are real.

Using namespaces would solve the problem. A new instance of pppd could be started in its own space then the sms service could attach to that pppd's namespace thereby inheriting its access (ip routes everything) whilst loosing any existing network access.. completely isolated.. but unless the maemo kernel is bumped to 2.6.29, that seems out of scope.. fingers crossed for maemo 5.1?

What I'd like to see is process A(all) can access all IP addresses via the internet connection.. process b) can access the MMSC via the MMS APN and even if the same ip address is used in both realms, it still works..

I think my idea is heading in that direction.. So far I have some vmware machines talking.. was quite nifty though.. in one window I could connect to 1.2.3.4 and it would leave via one interface and in the other window connecting to 1.2.3.4 left via a different interface.. what was even "cooler" was that if 1.2.3.4 was actually defined as an interface (lo:1, eth2 whatever) the first window would still connect out bound via the fake MMS APN interface where as all other windows would connect to localhost!! That is pretty close to what I think is needed..

I can mock something up, maybe some JeOS vmware images..

I think the long term I think the solution is namespacing, it is very neat and allows the MMS service to be completely isolated from all other networks. It would be neat to potentially improve icd2 to support starting an interface in its own namespace..