Nós executamos um servidor pop3 personalizado sem problemas por muitos anos. Mas agora alguns clientes estão tentando usar iPhones e há alguma incompatibilidade misteriosa. Para e-mails com um determinado tamanho (para testes que usamos em torno de 32K), o iPhone apenas recupera cabeçalhos e as primeiras 40 linhas usando o comando TOP . Ele exibe essas linhas, "Esta mensagem é apenas parcialmente baixada" e um botão para "Download restante".
Com o nosso servidor, ele nunca recupera a mensagem completa. Atingir "Download restante" apenas envia um comando STAT . Com um servidor de teste executando o servidor POP3 da Dovecot, ele envia um comando RETR conforme o esperado e exibe a mensagem completa. Também monitorizei a troca de protocolo com uma conta de teste da AOL, que funciona como esperado.
Eu obviamente não espero que alguém depure nosso código de servidor pop3, mas alguém tem uma pista sobre o que o iPhone pode estar vendo que faria com que ele se comportasse dessa maneira - nunca enviando o RETR ? Eu comparei as trocas de protocolo e não vejo diferença prática entre os servidores que trabalham e os nossos. Eu verifiquei o formato da mensagem (linhas de cabeçalho + linha em branco + corpo da mensagem + período único em uma linha para terminar) muitas vezes.
Aqui está a troca de protocolo para o nosso servidor:
+OK MultiBase POP3 Server Ready
USER [email protected]
+OK Name is a valid mailbox
PASS a
+OK Mailbox locked and ready
STAT
+OK 1 34572
UIDL
+OK
1 20110607123720000006
.
LIST
+OK 1 messages (34572)
1 34572
.
TOP 1 40
+OK message top follows
[--message headers + 40 lines--]
.
[--Download remaining button hit--]
STAT
+OK 1 34572
Aqui está a troca de protocolo para o servidor Dovecot:
+OK Dovecot ready.
USER stuff
+OK
PASS a
+OK Logged in.
STAT
+OK 1 34732
UIDL
+OK
1 000000014dee8328
.
LIST
+OK 1 messages:
1 34732
.
TOP 1 40
+OK
[--message headers + 40 lines--]
.
[--Download remaining button hit--]
STAT
+OK 1 34732
RETR 1
+OK 34732 octets
[--full message--]
.
O iPhone parece ter o hábito de não fechar a conexão em breve, por isso não há nenhum comando QUIT nessas trocas.
Qualquer sugestão ou pista muito apreciada.
Se o iPhone funcionar corretamente contra o servidor Dovecot, duvido que o problema esteja no lado do iPhone. Eu sugeriria colocar um programa de captura de pacotes no servidor, iniciar uma captura e observar a comunicação entre o iPhone e o servidor para procurar pistas. Talvez o servidor esteja encerrando a sessão TCP antes que o comando RETR seja recebido do iPhone. Procure por um RST do servidor ou alguma outra anamolia.