You should be able to view and change APN settings from the 'Settings' app: Settings --> General --> Network --> Cellular Data Network Paul -----Original Message----- From: users-bounces+bitfolk=pjlewis.org(a)lists.bitfolk.com [mailto:users-bounces+bitfolk=pjlewis.org@lists.bitfolk.com] On Behalf Of Joseph Heenan Sent: 27 October 2011 14:53 To: Kevin Whelan Cc: users(a)lists.bitfolk.com Subject: Re: [bitfolk] does bitfolk block smtp from t-mobile ip addresses? Hi Kevin, On 27/10/2011 14:39, Kevin Whelan wrote: It's an iPhone 4S, so I can't view or change the APN settings :-( I know it's their end; they just won't admit it and are blaming everything on the email providers. Joseph _______________________________________________ users mailing list users(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users

I'm on a locked O2 phone... I seem to have it, must just be T-Mobile! Daniel

I'm on an un-jailbroken iPhone 4S with the Cellular Data Network option there - and I'm certain it was there on my iPhone 4 before (also not jailbroken). I'm on O2 though - I know settings can vary from carrier to carrier, so maybe they're blocking you changing the APN settings... Paul -----Original Message----- From: users-bounces+bitfolk=pjlewis.org(a)lists.bitfolk.com [mailto:users-bounces+bitfolk=pjlewis.org@lists.bitfolk.com] On Behalf Of Joseph Heenan Sent: 27 October 2011 15:26 To: users(a)lists.bitfolk.com Subject: Re: [bitfolk] does bitfolk block smtp from t-mobile ip addresses? On 27/10/2011 15:20, Bitfolk wrote: Thanks for your help guys, but there really isn't a setting there! In that menu, I have "Cellular Data ON/OFF", "Data roaming ON/OFF", "Personal hotspot =>", VPN & WIFI. No Cellular Data Network. I'm pretty certain the only time I've seen the Cellular Data Network option is on jailbroken phones - the carrier settings are locked down on all supported carriers as far as I know. Joseph _______________________________________________ users mailing list users(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users

On 27/10/2011 15:38, Mike Zanker wrote: Ah - interesting to know, thanks. Joseph

On 27/10/2011 21:16, Andy Smith wrote: Correct - though it doesn't work in a very particular way: The SMTP connect opens fine, client says EHLO, server responds, client says STARTTLS, server responds successful - then the server receives a TCP RST. Switch over to wifi and everything is fine. Yes, I've not found any other form of non-smtp connectivity that's broken. ssh to the same host is fine, for example. But smtps on port 465 also seems not to work. On another provider (fastmail) I was able to workaround the problem as they run an smtps server you can connect to on port 443, which does seem to have fixed the problem there. Joseph

Which got me thinking that t-mobile must be *monitoring* or even *proxying* the connection and chopping it off once it threatens to become encrypted and unmonitorable. With that in mind a bit of googling led to: http://support.t-mobile.co.uk/help-and-support/index?page=support&cat=M… _BROADBAND_HELP&tab=0&id=FA1256 which I think explains it. _______________________________________________ users mailing list users(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users Hi Dom, That article states " From 1st May 2010, we are blocking unauthenticated SMTP sessions on our network for mobile broadband and handset data users." I am not sure that this will be the cause as its an encrypted session not unauthenticated but yes, they will be proxying the connection (all major carriers in the UK and Europe do) for speed and bandwidth reasons. Generally this works well but it does drive some people a little potty when the images are re-compressed to a lower quality and/or plays about with the HTML as is delivered to the device. This was the reason I originally asked which APN Joseph was using as we could have tested this on a 'bypass' APN that does not proxy the connection and prove that this is the reason. Ta K

Do they proxy connections other than HTTP? How does that work if you are using HTTPS? _______________________________________________ users mailing list users(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/users Hi Dom, That very much depends on the carrier and how the system is configured. Most of the time they tend to ignore encrypted traffic and just bypass it. They tend to actively proxy SMTP, POP, IMAP, HTTP on selected ports however I am aware of at least 1 carrier that proxies all ports. Most of the time this should be totally invisible but *can* break some things in weird and wonderful ways ;) My advice, if your doing things across mobile networks and you don't want your traffic intercepted, SSH to your VPS and tunnel your traffic down there as Andy doesn't filter or monitor ;) Ta K

On 28/10/2011 10:03, Kevin Whelan wrote: Nice find Kevin, thanks - I bet that does explain it. :-( Blocking secure connections because they can't spy and see if you're authenticating seems like a very poor compromise. Let's see what I get back from my escalated support request... Joseph

On 2011 October 28 Friday, Duane wrote: I don't think that's true. The starttls command could indeed be mitm-attacked, but to exactly the same extent so could the initial TCP negotiation to SSMTP port 465. Think of STARTTLS as being equivalent to the TCP SYN packet and you can see it makes no difference at all how the initial unencrypted contact is made. The SSL/TLS negotiation includes a certificate phase for exactly this reason. There's no more wrong with STARTTLS protocols than there is with running a service on a different port to mark it as encrypted. The only potential problem is allowing clients that aren't encrypted: you can either say "that's their problem", or require that the server deny all client commands _except_ STARTTLS on an unencrypted connection. To be honest, I have no idea why we have this constant dual-allocation of ports for single services. It's a waste of well-known port numbers; http/https included. See http://rfc.net/rfc2817.html for STARTTLS on HTTP. Andy -- Dr Andy Parkins andyparkins(a)gmail.com

So encryption is doing it's job, blocking a third party from intercepting the data. I don't see that the fault is the tech involved here. As the computational overhead of encryption, and the cost of the certs, is really worth it for every 'my cat is awesome' blog...

On 28/10/11 22:41, Duane wrote: That should have been everything except webbrowsers followed the SSH model, why do you think FTPS was never highly used, because it was a rip off for certificates. As for every "my cat is awesome" blog, the same could be said for junk mail, why should we care about getting email over encryption? Because some times there are just some things that should remain private, and I'm not talking about smut although I highly doubt "if you have nothing to hide" crowd would appreciate putting a web cam in their bedrooms, we all have something to hide from some one and the more encrypted things get the more privacy you can retain. Although the ideals of privacy seem to be a lost cause with most people using social networks...

Hi Joseph, On Fri, Oct 28, 2011 at 02:01:57PM +0100, Joseph Heenan wrote: If you need an extra IP address because of this, then you need one, it's a fair enough justification. Cheers, Andy

On 28/10/11 23:35, Andy Parkins wrote: I'd say it'd be worst, simply because there is a major difference between rejecting a connection and having an app silently fall back to non-encrypted which could be the case here if the software was coded only slightly differently. At least with an encrypted connection it'd be all or nothing. So why is it the ISP/celco is doing deep packet inspection here if simple port blocking is the obvious solution? I could be facetious here and argue the difference between encryption and ssl/tls, you don't need ssl/tls to do encryption, firefox could have a plugin to handle some other exchange with your embedded server. And this is why we end up with insulin pumps able to dish out lethal doses and pacemakers or similar devices able to give a lethal shock or be turned off, because security on embedded devices wasn't considered critical. http://go.theregister.com/feed/www.theregister.co.uk/2011/10/27/fatal_insul… People need to learn that encryption is VERY important, especially on embedded devices.

Hi, This is absolutely not the case and is a very dangerous simplification of what is actually happening. In a connection that is encrypted from the start the client is expecting to see a correctly signed certificate. If you get the wrong certificate or something that is not correctly signed then you find out and the connection fails. In a connection that starts unencrypted and switches to an encrypted mode later there is usually some kind of capabilities detection phase where the client and server negotiate the kinds of things they will do without encryption and the kinds of encryption that they support. This is a much easier situation to hijack with a man-in-the-middle attack. The attacker impersonates the server and replies with capabilities that allow plain text authorization without encryption and does not advertise support for encryption at all. Lots of clients will then authenticate against the man-in-the-middle and reveal their credentials. Lots of (mail) clients have to be carefully configured to ensure that they always insist on TLS on unencrypted-by-default ports and that they never use a plain text equivalent password protocol. There is far less margin for user error or misconfiguration on encrypted-only ports. You can only check a certificate if you know for sure that you're expecting one. You only know for sure that you're expecting one if you're using an encrypted-by-default port. See above. Well maybe now you do. ;-) It's a much, much deeper issue than you realise. PS: That comment is meant in a light-hearted way: it's amazing the amount of people who I correspond with on a daily basis who don't actually know what the smiley is for any more. :-) This is a very easy mistake to make and it's a misunderstanding that I myself had for some time. Having the server deny everything but STARTTLS is all well and good if the client knows to expect it, but it's far from the default behaviour and it's often quite fiddly to actually configure in most user agents. Whilst your server may deny everything but STARTTLS, a man-in-the-middle doesn't have to and may be able to take advantage of your client's naiveté. It's only been relatively recently that the majority of people have really understood the importance or relevance of encrypting *everything* as opposed to just the password protocol (see Google vs China, for example). Supporting 100% encrypted connections as opposed to mostly unencrypted connections is an ongoing area of research for service providers as server resources become significantly more difficult to manage: CPU, memory footprint, TLS caches, load balancing multiple connections from the same client, etc. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF

On 28/10/11 17:08, Andy Bennett wrote: Exactly. Policy set from on high by people who have no contact with the techie level, and enforced by people who have no wish to go back to their superiors with anything but a report that the policy has been duly implemented. Do not blame the implementors: they probably hate it every bit as much as you do. I have the same hypothesis as to why the "enter-card-number-without-spaces" stupidity is so endemic. Board-level security policy is that all numerical fields in forms must only accept digits. Which sounds entirely reasonable until it comes to accurately transcribing a 16 digit number.

On 28/10/2011 12:38, Andy Smith wrote: Thanks Andy. I was sure that was the case, but t-mobile were being so insistent I felt the need to ask (and it has revealed some useful feedback). In theory this has now been escalated within t-mobile; I'll let the list know if we get a more sensible response back. Thanks Joseph