email won't send over wifi

Question

Level 1

8 points

email won't send over wifi

i can send email fine over wifi, but when i send an email i have to turn wifi off before it will send. i dont get an error message or anything, it just says sending at the bottom of the screen with the little circle. the same thing is happening with my ipad. any ideas? ive done everything ive found on the internet but nothing has worked. it is my college's wifi and it worked fine in the spring if that's any help.

iPhone 4, iOS 5.1.1

Posted on Aug 27, 2012 4:33 PM

Reply

Answer 1

Aug 27, 2012 6:53 PM in response to bearface

If you used the Yahoo email to set up email... I would delete it. I would go to Other to set up email manually by setting up your own POP and SMTP setting... when you enter in password I wouldn't enter full password to where it will let you set up the POP setting manually.

Yahoo! Mail Settings

Yahoo Mail offers standard POP3 access for receiving emails incoming through your Yahoo mailbox, by using your favorite email client software. To setup your email client for working with your Yahoo account, you need to select the POP3 protocol and use the following mail server settings:

Yahoo Incoming Mail Server (POP3) - pop.mail.yahoo.com (SSL enabled, port 465)

Yahoo Outgoing Mail Server (SMTP) - smtp.mail.yahoo.com (SSL enabled, port 995) POP Yahoo! Mail Plus email server settings

Yahoo Plus Incoming Mail Server (POP3) - plus.pop.mail.yahoo.com (SSL enabled, port 995)
Yahoo Plus Outgoing Mail Server (SMTP) - plus.smtp.mail.yahoo.com (SSL enabled, port 465, use

Reply

Answer 2

Nov 30, 2013 2:11 PM in response to Shiny McShine

When WiFi is off the phone can use your cellular carrier's SMTP server, which does not require login.

Reply

Answer 3

Nov 30, 2013 1:04 PM in response to Lawrence Finch

I'm having the same problem. However, the original post was not concise. Here's what I think they meant--

When using WiFi, receiving email works fine; however sending email does not. The outgoing item seems to hang in the Outbox and never goes. It's happened consistently to me on my new phone (5s). I can cause it to send by disabling WiFi for a moment. This is getting tedious.

I went into my mail configuration and checked my settings. They appear fine. The free version of Yahoo! doesn't not include the use of standard POP3 protocol and they've wired some sort of back door into the iPhone's mail client. You'd have to pay Yahoo! to get an SMTP server address and use normal POP3 protocols. I'm OK with this as it's obviously Yahoo's attempt to lure iPhone customers.

Meanwhile, I've deleted my Yahoo account configuration on my phone and set it up from scratch. That didn't work and I still have the same problem.

As a prediction, I'm thinking this is some sort of problem with the mail program's proprietary access to Yahoo's promotional mail service and not a configuration problem. This is not the user's fault, it's something else IMHO. I'm finding it odd that turning off my WiFi allows the mail to finally get sent. This last time, I had to turn off and turn back on Airport mode also.

Very weird.

Reply

Answer 4

Sep 22, 2016 8:44 AM in response to Shiny McShine

This exact problem has been plaguing my brand new Macbook Pro all summer long, but I might know what's going on. Like others, mail in my outbox finally is sent immediately when I turn take down the WiFi interface and bring it back up. Furthermore, I get mailbox connectivity errors/warnings in mail sometimes that prevent me from syncing new mail. I'm using IMAP and SMTP -- imap.gmail.com and smtp.gmail.com, specifically.

I do have some further information to contribute though. It only occurs when I am at home connected to a single particular WiFi access point -- an AT&T furnished access point and router. What's even more interesting is that the problem *does not* occur if I am fully VPNed into my place of business (all traffic; not just business subnet). What this tells me is that the problem is circumvented by tunneling mail traffic through my AP and router to some other place where the rest of the world/Internet thinks I'm located. The only difference as far as my AT&T router is concerned is that the mail traffic is now disguised within the VPN tunnel and the router is no longer able to (if it wished) filter any specific type of traffic, since its all in an opaque tunnel. Another difference to note is that the full VPN forces my Mac to circumnavigate all of AT&T's network services and use my business ISP's instead, DNS servers in particular.

Now, what type of traffic is generated when we try to send or receive mail? The first thing that will happen is the local machine will ARP for its gateway (assuming IPv4), since the mail server is obviously outside the local network. This isn't the issue, since all other applications besides mail seem to work okay and I can ping any public IP w/o an issue. Next, we need to consider how the mail server is addressed. It's configured as a domain name, so we must use DNS to resolve it to an IP address if our local machine doesn't have it cached already. After the mail server's IP has been identified, a TCP connection is established to the mail server, in my case to port 993 (IMAP). After that, it's all IMAP stuff and the network should be in a steady state while the message is uploaded from my outbox.

Here's what we see:

11:34:53.799973 IP (tos 0x0, ttl 52, id 1628, offset 0, flags [none], proto UDP (17), length 130)

64.6.64.6.53 > 172.16.1.250.53999: [udp sum ok] 50209 q: A? smtp.gmail.com. 3/0/0 smtp.gmail.com. [1m42s] CNAME gmail-smtp-msa.l.google.com., gmail-smtp-msa.l.google.com. [5m] A 173.194.219.108, gmail-smtp-msa.l.google.com. [5m] A 173.194.219.109 (102)

As shown above, while the problem is occurring (a message sitting idle in my outbox), DNS works fine to resolve the IMAP server, which we now know is at 173.194.219.108 and 109.

Meanwhile, if we watch carefully, we'll notice repeating spurts of traffic that look like:

11:35:42.077022 IP (tos 0x0, ttl 64, id 64178, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49827 > 173.194.219.108.143: Flags [S], cksum 0xfe6d (correct), seq 2044303645, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153494022 ecr 0,sackOK,eol], length 0

11:35:42.077023 IP (tos 0x0, ttl 64, id 41773, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49828 > 173.194.219.108.143: Flags [S], cksum 0xf93f (correct), seq 306382305, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153494022 ecr 0,sackOK,eol], length 0

11:35:42.178455 IP (tos 0x0, ttl 64, id 15012, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49829 > 173.194.219.109.143: Flags [S], cksum 0xd254 (correct), seq 1241445545, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153494123 ecr 0,sackOK,eol], length 0

11:35:42.178456 IP (tos 0x0, ttl 64, id 52252, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49830 > 173.194.219.109.143: Flags [S], cksum 0x61d5 (correct), seq 1084059273, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153494123 ecr 0,sackOK,eol], length 0

11:35:43.079545 IP (tos 0x0, ttl 64, id 49577, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49828 > 173.194.219.108.143: Flags [S], cksum 0xf556 (correct), seq 306382305, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153495023 ecr 0,sackOK,eol], length 0

11:35:43.079546 IP (tos 0x0, ttl 64, id 7338, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49827 > 173.194.219.108.143: Flags [S], cksum 0xfa84 (correct), seq 2044303645, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153495023 ecr 0,sackOK,eol], length 0

11:35:43.180575 IP (tos 0x0, ttl 64, id 25105, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49830 > 173.194.219.109.143: Flags [S], cksum 0x5dec (correct), seq 1084059273, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153495124 ecr 0,sackOK,eol], length 0

11:35:43.180577 IP (tos 0x0, ttl 64, id 54131, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49829 > 173.194.219.109.143: Flags [S], cksum 0xce6b (correct), seq 1241445545, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153495124 ecr 0,sackOK,eol], length 0

11:35:44.080625 IP (tos 0x0, ttl 64, id 49089, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49828 > 173.194.219.108.143: Flags [S], cksum 0xf16d (correct), seq 306382305, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153496024 ecr 0,sackOK,eol], length 0

11:35:44.080626 IP (tos 0x0, ttl 64, id 20634, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49827 > 173.194.219.108.143: Flags [S], cksum 0xf69b (correct), seq 2044303645, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153496024 ecr 0,sackOK,eol], length 0

11:35:44.181764 IP (tos 0x0, ttl 64, id 23242, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49830 > 173.194.219.109.143: Flags [S], cksum 0x5a03 (correct), seq 1084059273, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153496125 ecr 0,sackOK,eol], length 0

11:35:44.181765 IP (tos 0x0, ttl 64, id 39779, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49829 > 173.194.219.109.143: Flags [S], cksum 0xca82 (correct), seq 1241445545, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153496125 ecr 0,sackOK,eol], length 0

11:35:45.086878 IP (tos 0x0, ttl 64, id 56038, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49828 > 173.194.219.108.143: Flags [S], cksum 0xed85 (correct), seq 306382305, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153497024 ecr 0,sackOK,eol], length 0

11:35:45.086880 IP (tos 0x0, ttl 64, id 34988, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49827 > 173.194.219.108.143: Flags [S], cksum 0xf2b3 (correct), seq 2044303645, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153497024 ecr 0,sackOK,eol], length 0

11:35:45.189034 IP (tos 0x0, ttl 64, id 29023, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49830 > 173.194.219.109.143: Flags [S], cksum 0x561b (correct), seq 1084059273, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153497125 ecr 0,sackOK,eol], length 0

11:35:45.189035 IP (tos 0x0, ttl 64, id 35715, offset 0, flags [DF], proto TCP (6), length 64)

172.16.1.250.49829 > 173.194.219.109.143: Flags [S], cksum 0xc69a (correct), seq 1241445545, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 153497125 ecr 0,sackOK,eol], length 0

What this shows is the Mac Mail client is trying to open a socket to the IMAP servers

Reply

Answer 5

Sep 22, 2016 9:23 AM in response to bearface

Apologies for the first incomplete post (can't seem to find how to delete it...). This is the completed analysis.

This exact problem has been plaguing my brand new Macbook Pro all summer long, but I might have an idea about what's going on, at least for me. Like others, mail in my outbox finally is sent immediately when I turn take down the WiFi interface and bring it back up. Furthermore, I get mailbox connectivity errors/warnings in mail sometimes that prevent me from syncing new mail. I'm using IMAP and SMTP -- imap.gmail.com and smtp.gmail.com, specifically.

I do have some further information to contribute though. It only occurs when I am at home connected to a single particular WiFi access point -- an AT&T furnished access point and router. What's even more interesting is that the problem *does not* occur if I am fully VPNed into my place of business (all traffic; not just business subnet). What this tells me is that the problem is circumvented by tunneling mail traffic through my AP and router to some other place where the rest of the world/Internet thinks I'm located. The only difference as far as my AT&T router is concerned is that the mail traffic is now disguised within the VPN tunnel and the router is no longer able to (if it wished) filter any specific type of traffic, since its all in an opaque tunnel. Another difference to note is that the full VPN forces my Mac to circumnavigate all of AT&T's network services and use my business ISP's instead, DNS servers in particular.

Now, what type of traffic is generated when we try to send or receive mail? The first thing that will happen is the local machine will ARP for its gateway (assuming IPv4), since the mail server is obviously outside the local network. This isn't the issue, since all other applications besides mail seem to work okay and I can ping any public IP w/o an issue. Next, we need to consider how the mail server is addressed. It's configured as a domain name, so we must use DNS to resolve it to an IP address if our local machine doesn't have it cached already. After the mail server's IP has been identified, a TCP connection is established to the mail server, in my case to the SMTP port. After that, it's all SMTP stuff and the network should be in a steady state while the message is uploaded from my outbox.

Here's what we see:

11:34:53.799973 IP (tos 0x0, ttl 52, id 1628, offset 0, flags [none], proto UDP (17), length 130)

64.6.64.6.53 > 172.16.1.250.53999: [udp sum ok] 50209 q: A? smtp.gmail.com. 3/0/0 smtp.gmail.com. [1m42s] CNAME gmail-smtp-msa.l.google.com., gmail-smtp-msa.l.google.com. [5m] A 173.194.219.108, gmail-smtp-msa.l.google.com. [5m] A 173.194.219.109 (102)

11:55:31.797938 IP (tos 0x0, ttl 53, id 517, offset 0, flags [none], proto UDP (17), length 126)

64.6.64.6.53 > 172.16.1.250.64294: [udp sum ok] 51371 q: A? imap.gmail.com. 3/0/0 imap.gmail.com. [4m19s] CNAME gmail-imap.l.google.com., gmail-imap.l.google.com. [5m] A 74.125.196.108, gmail-imap.l.google.com. [5m] A 74.125.196.109 (98)

As shown above, while the problem is occurring (a message sitting idle in my outbox), DNS works fine to resolve the SMTP and IMAP servers, which we now know are at 173.194.219.108 and 109 while the IMAP servers are 74.125.196.108 and 109.