-->

sexta-feira, 27 de fevereiro de 2009

Instalei a Google Toolbar ontem. Já desativei.

O único interesse que eu tinha na Google Toolbar para Firefox era poder ver o Pagerank dos sites (incluindo o de minhas páginas, que eu nunca havia visto antes), mas a instalação veio com um efeito colateral desagradável: Toda vez que eu tentava usar a lista de abas, a mesma ficava congelada por uns 4 segundos.

Talvez seja porque estou com 195 abas abertas, mas eu não me vejo mudando o meu jeito de navegar (ou pensar) para satisfazer os bugs de um complemento.

Após a instalação eu achei um bônus interessante o fato da barra mostrar uma lista com os e-mails mais recentes na minha conta no Gmail, porque eu ainda estou tentando me livrar dos surtos de CPU provocados pelo Gmail, mas eu fiz um teste fechando a aba do Gmail e o uso da CPU continuou o mesmo (até me pareceu pior).

A propósito, o Gmail Notifier é um programa muito burro. Eu só quero saber de novas mensagens (ou pelo menos das 10 mais recentes), mas ele insiste em listar, uma por uma, as 2546 que eu tenho não lidas nos meus 4 anos de conta. (Edit: Erro meu. Veja o que realmente ocorre neste outro post).

Não foi preciso desinstalar, mas após desligá-la eu precisei reiniciar o Firefox para o problema sumir.

quinta-feira, 26 de fevereiro de 2009

Novo site golpista. O alvo é o Banco Real e a propaganda é no Gmail.

No último dia 19 eu achei estranho quando vi isto nos links patrocinados do Gmail:



foifeitoparavoces.com? Como eu nem sou cliente do Real cliquei só para conferir. Por causa do noscript, a primeira coisa que vi foi uma mensagem de erro:



Por estranho que pareça, esta mensagem me enganou e me fez dar credibilidade ao site. Habilitei o javascript e me deparei com isso:



Que também parecia "certo", tirando o buraco branco (Edit: por causa do noscript eu acabei acostumado a ver anomalias em sites e não dar atenção). Fiz snapshots das imagens e guardei para falar depois da doideira do Banco Real de ficar usando nomes diferentes para seu domínio, o que acaba por reduzir sua segurança.

Hoje eu fui fazer uma checagem para ter certeza no registro.br e foi aí que me toquei mesmo:

".com"?! Deveria ser .com.br...

Então eu digitei qualquer besteira nos campos usuário, agência e conta e...

Aceitou!



Daí para a frente, eu não precisava de mais nenhuma prova de que o site era falso. Por mais "desligado" que eu esteja e mesmo que eu fosse cliente do Banco Real (mas se fosse não teria usado aquele link e provavelmente teria notado outras anomalias), "atualizar dados cadastrais" é o ca**te!.

O Whois para esse domínio dá as seguintes informações:

Registrant:

VANDEMIR MONTEIRO DA SILVA
qd22 lt24 casa 24
goiania - GO
74030-090 - BR

Domain Name:

domain: FOIFEITOPARAVOCES.COM
nserver: NS1.LOCAWEB.COM.BR
nserver: NS2.LOCAWEB.COM.BR
nserver: NS3.LOCAWEB.COM.BR
status: transfer-prohibited
created: 20090219
changed: 20090219

Administrative Contact:

person: VANDEMIR MONTEIRO DA SILVA
address: qd22 lt24 casa 24
address: goiania - GO
address: 74030-090 - BR
phone: +55 62 96222378
e-mail: rataum2009.5@gmail.com

Technical Contact:

person: VANDEMIR MONTEIRO DA SILVA
address: qd22 lt24 casa 24
address: goiania - GO
address: 74030-090 - BR
phone: +55 62 96222378
e-mail: rataum2009.5@gmail.com

Excetuando o fato de que está hospedado na Locaweb, tudo o mais deve ser falso.

Às vezes o meu Firefox e o Blogger não se entendem...

Hoje ocorreu pela segunda vez esse problema no meu Firefox ao tentar criar um novo post no meu blog:



Quando deveria ser assim:



Da primeira vez eu fui obrigado a usar o Chrome para fazer essas coisas, porque não conseguia resolver. Desconfiei do noscript, que é muito inclinado a provocar esse tipo de coisa, mas aparentemente não era. Devo ter passado umas duas semanas assim até perder a paciência (porque o Chrome ainda tem problemas demais) e parei para pesquisar. Não encontrei nada sobre esse problema específico mas uma dica em algum lugar me fez limpar o cache do Firefox.

Problema resolvido. Nem é preciso reiniciar o Firefox. O estranho é que eu lembro de ter tentado o SHIFT+Atualizar, que teoricamente ignora o cache, sem sucesso.

Vá em Opções -> Privacidade -> Limpar Agora e deixe marcado apenas Cache:



Depois é só atualizar a página.

O danado é que eu passei pelo Firefox 1.x, pelo 2.x e vinha usando o 3.x há muito tempo sem isso acontecer. E agora com um intervalo de duas semanas aconteceu duas vezes. Estou usando a versão 3.06.

A única coisa incomum que estou fazendo agora é no meu número de abas abertas ao mesmo tempo, que está variando de 150 a 210 já a várias semanas.

quarta-feira, 25 de fevereiro de 2009

Dando uma acelerada nos backups com o Winrar.

Neste post eu vou discutir o fato de que o Winrar tenta comprimir até o que já está comprimido e como evitar isso.

Por default, o Winrar não diferencia arquivos por tipo. Ele tenta comprimir qualquer coisa, mesmo que as chances de compressão sejam pouquíssimas ou nulas. Tem um arquivo *.rar na lista? Ele tenta comprimir com a mesma paciência reservada para um *.bmp.

E isso pode ser um problemão para o usuário.

Como exemplo eu escolhi ao acaso um diretório de 190MB de fotos da minha câmera digital e mandei o Winrar comprimir para outro drive, usando compressão normal. O processo levou 6 minutos, ocupando 100% da CPU do meu PC, e produziu um arquivo de... 190MB.

Para ser justo, houve um ganho sim. Mas é preciso olhar nos números miúdos:

Original: 200.180.515 bytes
RAR: 200.144.574 bytes

Seis minutos para ganhar 36KB. Nem que eu fosse distribuir esse arquivo pela internet para mil pessoas esse ganho me interessaria. E olha que esse diretório é uma fração de um diretório maior de 13GB, só com imagens. Pelas minhas contas, se o RAR passasse por esse diretório inteiro ia levar quase 6 horas para ganhar menos de 3MB.

Por sorte, existem pelo menos dois meios de evitar que o Winrar faça isso.

Ao comprimir, mude o método de compressão para Armazenar (store):




Isso tem um inconveniente: todos os arquivos são armazenados sem compressão, mesmo que o Winrar encontre algo que seja altamente comprimível na pasta, como um arquivo *.wav. Por isso tem utilidade limitada. Por exemplo, a cópia offline que tenho do meu site inteiro tem 1GB numa mistura grande de arquivos não comprimíveis (jpg, zip, rar) com arquivos comprimíveis (html, bmp, wav) e seria improdutivo para mim ter que separar os arquivos por tipo para depois comprimir.

Isso nos leva ao segundo método, que eu considero bem melhor:




O Winrar não vai perder mais tempo tentando comprimir nenhum dos tipos de arquivo listados acima à medida que os for encontrando e vai simplesmente guardá-los dentro do .RAR. Os tipos de arquivos são separados com espaços. Se você usa o Cobian Backup já deve ter percebido que ele lhe dá essa opção também de listar os tipos de arquivo que não devem ser comprimidos.

Você pode definir uma lista a cada compressão ou pode definir uma lista que vai ser usada por default em todas as compressões. Para isso siga o caminho (Winrar 3.70):

Opções -> Configurações -> Compressão -> Criar Padrão -> Arquivos

Se quiser automatizar isso ainda mais, isso fica armazenado no Registro em:

HKEY_CURRENT_USER\Software\WinRAR\Profiles\0\StoreNames

Exemplo de arquivo .reg para aplicar em dois cliques:
---------------- recorte aqui ------------------------
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\WinRAR\Profiles\0]
"StoreNames"="*.rar *.zip *.7z *.cbr *.cbz *.jpg *.mp3 *.wma *.wmv *.avi *.mkv *.divx *.mpeg *.mpg *.ogm *.ogg *.rmvb *.mp4 *.aac *.m4a *.m4v *.vob

---------------- recorte aqui ------------------------

Infelizmente não parece haver um jeito fácil de dizer ao Winrar para ignorar também os arquivos de multivolumes que ele cria, porque para isso eu precisaria de uma máscara muito genérica do tipo *.r??, que pode atingir outros tipos de arquivo.

E usando "Armazenar" o Winrar levou apenas 30 segundos (contra seis minutos) para processar aquele diretório de 190MB do meu exemplo.

Consegui bloquear minha conta no Gmail.

Ainda bem que é só por 24H.



Há muito tempo eu preciso fazer o download via POP3 de todas as minhas mensagens e lembrava de ter tentado há anos, sem sucesso, mas não lembrava o motivo. Depois dessa eu me lembrei.

Não é a primeira vez que sou bloqueado. O Gmail permite que você baixe por POP3, mas pelo jeito tem que ser em doses homeopáticas. Se você simplesmente configurar o programa de e-mail e mandar baixar, pode acabar bloqueado se tiver muitas mensagens. No caso eu fui bloqueado apenas por configurar o Magic Mail Monitor (recomendação do Sony Santos) para listar as mensagens não lidas. Como são mais de 3000 (tem muita coisa que eu nem leio, nem apago, como os extratos do Bradesco), o Gmail me bloqueou.

Ainda bem que não testei isso com a conta de um cliente. Eu posso perfeitamente ficar sem e-mail por até bem mais que 24H.

terça-feira, 24 de fevereiro de 2009

Como descobrir o tamanho máximo que um e-mail pode ter.

O procedimento abaixo foi testado no Windows 2000 SP4 e XP SP3.

Esse problema ocorreu comigo há algumas semanas. Um e-mail precisava ser enviado com anexo e não se sabia qual o tamanho máximo de anexo que podia passar pelos dois servidores (o do remetente e o do destinatário). Na ocasião eu tive que descobrir por tentativa e erro metade da resposta e pesquisa no Google para o resto.

Ontem eu descobri que poderia ter feito a pergunta diretamente aos servidores (às máquinas, não aos administradores).

Quando o servidor facilita

Por exemplo, para saber o tamanho máximo de e-mail que o meu servidor aceita abra um prompt do DOS e digite:

telnet ryan.com.br 25 [ENTER]

O meu servidor responderá com algo assim:

220-gator194.hostgator.com ESMTP Exim 4.69 #1 Tue, 24 Feb 2009 01:38:39 -0600
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.

E um cursor piscando. O servidor está esperando. Digite às cegas (sua digitação não vai aparecer):

EHLO [ENTER]

O servidor responde com:

250-gator194.hostgator.com Hello [189.70.54.187]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP

A linha SIZE diz o tamanho máximo que cada mensagem pode ter, independente do tamanho da caixa postal. No exemplo, uns 52MB. Tenha em mente que o valor reportado é o valor total já com o overhead de 33% de que falo no meu post anterior. Para saber o tamanho máximo aproximado do total de anexos de uma mensagem, multiplique esse valor por 0,75. No caso, vai dar 39MB. Como a regra dos 33% não é perfeita mandar algo maior que 30MB pode ser uma loteria.

Entendendo como funciona

"telnet ryan.com.br 25" significa algo como "estabeleça uma conexão RAW (bruta) com ryan.com.br usando a porta 25". A porta 25, como vocês devem saber, é a porta padrão para entrada de e-mail do protocolo SMTP. Sistemas mais modernos, e o exemplo mais conhecido deve ser o Gmail, usam também a porta 587 e outros usam a porta 465.

Os protocolos de e-mail (SMTP, POP) foram desenhados para serem usados por humanos, como se fosse uma "conversa" (em ASCII) com o servidor.

Para poder conversar com o servidor você precisa de um programa que estabeleça uma conexão TCP "bruta" (conecta e se limita a passar para o outro lado tudo o que você digitar e exibir as respostas) e telnet.exe é justamente esse tipo de programa.

Já "EHLO" é uma extensão do comando "HELO" (parece piada, mas é sério) que faz o servidor responder com uma lista de suas características. Uma delas é o tamanho máximo que cada mensagem pode ter.

Quando o servidor não facilita

O meu servidor associa diretamente qualquer tentativa de conexão à porta 25 com o serviço de e-mail, mas nem sempre a coisa é fácil assim. Muitas vezes você precisa saber exatamente qual o FQDN (host.dominio) do encarregado de manipular e-mail. No meu caso, é "mail.ryan.com.br", mas como você viu no exemplo, não foi necessário.

Se você tentar "telnet bol.com.br 25" vai dar um erro parecido com este:

421 Cannot connect to SMTP server 200.221.8.150 (200.221.8.150:25), connect error 10060

Você precisa saber qual o FQDN do servidor de e-mail do BOL, que geralmente é divulgado para seus usuários, mas se você não for usuário, ou tiver esquecido, pode chutar um dos nomes padrão:

mail.nome_do_domínio
smtp.nome_do_domínio
smtps.nome_do_domínio
mx.nome_do_domínio

Ou seguir o procedimento explicado aqui.



Se ao dar o comando:

EHLO [ENTER]

O servidor reclamar algo do tipo:

501 Syntax: EHLO hostname

Então faça do jeito que ele quer:

EHLO teste.com [ENTER]

O problema é que a sintaxe padrão dos comandos HELO e EHLO requer que você se "apresente", mas como você sempre pôde se apresentar como quisesse (isso não é verificado de maneira alguma), muitos servidores dispensam essa identificação. No lugar de "teste.com" você pode escrever BRADPIT que vai funcionar do mesmo jeito.

Como identificar o servidor de e-mail de um domínio.

Se você trabalha com manutenção de PCs, provavelmente já ficou em dúvida na hora de preencher isto para um cliente:



A configuração do BOL, por exemplo, supostamente é esta:

POP3: pop3.bol.com.br (ainda funciona)
SMTP: smtps.bol.com.br (isso não funcionou nos meus testes. Provavelmente a documentação do BOL está desatualizada).

O problema é que "quase" não existe um padrão para isso. E é com esse "quase" que você perde tempo e se aborrece. Muitos servidores facilitam as coisas permitindo que você simplesmente coloque o nome do domínio nos dois campos e eles decidem pela porta de conexão (25 ou 110) do que se trata. Mas em muitos outros você precisa saber o FQDN (host.domínio) correto.

Nota: cuidado para não se atrapalhar. Do ponto de vista do usuário (e do Outlook Express), SMTP é saída, mas do ponto de vista do servidor, é entrada. Para evitar confusão, não vou me referir a saída ou entrada mas sim a SMTP e POP3.

Servidor POP3

Eu não conheço um meio automatizado para descobrir e possivelmente isso não existe, visto que quem pega os e-mails no protocolo POP3 é sempre o usuário e nunca um outro servidor em nome dele. As suas alternativas são ligar para o provedor e perguntar, consultar a ajuda no site dele, ou "chutar" as alternativas mais comuns:

nome_do_domínio
pop.nome_do_domínio
pop3.nome_do_domínio
mail.nome_do_domínio

Servidor SMTP

Para este existe um procedimento automatizado, porque a mesma conexão que o usuário utiliza para enviar seu e-mail é usada por outros servidores no mundo inteiro que se conectam para deixar e-mail para ele.

Vamos ver qual é o servidor SMTP atual do BOL. Abra um prompt de comando e digite:

nslookup -type=mx bol.com.br [ENTER]

A resposta será parecida com isto:

Servidor: resolver1.opendns.com
Address: 208.67.222.222

Não é resposta de autorização:
bol.com.br MX preference = 10, mail exchanger = mx.bol.com.br

O FQDN em negrito é o servidor SMTP atual do BOL.

Você também pode chutar os mais comuns, se preferir (ou não lembrar como se usa o nslookup):

nome_do_domínio
smtp.nome_do_domínio
smtps.nome_do_domínio
mail.nome_do_domínio
mx.nome_do_domínio


Como funciona

nslookup (Name Server Lookup) é uma ferramenta genérica de diagnóstico DNS. No nosso exemplo estamos pedindo que seja feita uma consulta ao servidor DNS corrente (no meu caso, resolver1.opendns.com) para obter os registros MX (Mail eXchange) associados ao domínio bol.com.br. Nos registros MX o domínio informa que hosts são encarregados de receber e-mail. Podem ser vários, numa hierarquia. No caso de bol.com.br só há um: mx.bol.com.br.

Mas se você experimentar com o Gmail verá cinco:

nslookup -type=mx gmail.com

gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com

Por sorte, smtp.gmail.com (que não aparece na lista, não me pergunte o motivo) também serve.

O segredo para tanto espaço no Gmail.

Faz o LHC parecer um brinquedo importado da China :)



E olha que isso foi publicado no blog oficial :)

Antes de enviar e-mail com anexo, avalie as opções.

Isso não deve ser novidade para boa parte de meus leitores, mas servirá de suporte para textos mais complexos que estou rascunhando. Algumas informações também podem não estar inteiramente corretas (por favor, apontem o que estiver errado) mas vou publicar assim mesmo porque esse texto está emperrando a publicação de outro e estou razoavelmente seguro de que os erros, se existirem, são inócuos.

E-mail é uma ferramenta fantástica, do tipo que faz a geração atual se perguntar como a gente se virava há 20 anos (eu ainda sou da época de trocar cartas apaixonadas com a namorada que morava longe). Porém muita gente acaba usando o e-mail não para se comunicar, mas como "meio genérico de transporte e distribuição de arquivos" sem nem se tocar de quanto tempo perde e faz as outras pessoas perderem com isso.

Um exemplo extremo:

Eu já dei mais de uma bordoada na minha irmã mais velha por ela insistir em querer me enviar arquivos por e-mail. Nesse ponto alguns já devem estar arqueando as sobrancelhas e se perguntando "por que raios isso seria um problema?", mas deixem eu terminar: Minha irmã mora comigo, no andar de baixo da casa. Todos os computadores estão na mesma rede e a casa tem até servidor que roda 24/7. Além disso, mais de uma vez ela estava no meu quarto dizendo que ia mandar os arquivos para mim por e-mail!

Ou seja: congestionar duas vezes nossa conexão com a Internet só para mandar arquivos de um lado para outro da casa (pegando um "atalho" por um servidor nos EUA).

E tenho certeza de que isso não acontece apenas na minha família.
"para quem só sabe usar um martelo, todo problema parece com um prego"

Mais recentemente (talvez por ter levado outras bordoadas) ela enfrentou o escorpião que tem no bolso e comprou um pendrive. Parece que agora ela está considerando usar o pendrive antes de enviar por e-mail. E olha que ela sempre pôde gravar em CD-RW.

Os problemas

Não é apenas quando as duas pessoas moram na mesma casa que o uso sem critério do e-mail para enviar arquivos é desaconselhável. Existem outros motivos (alguns se aplicam a todo tipo de e-mail e não apenas ao com anexos grandes):
  • Devido a limitações históricas do protocolo SMTP, que só é capaz de enviar anexos graças a uma gambiarra (que eles chamam de "extensão", mas se parece mais com gambiarra do ponto de vista do usuário), todo arquivo anexado a um e-mail fica cerca de 33% maior. Ou seja: se você enviar um arquivo de 10MB, a sua conexão e a do(s) destinatário(s) ficarão ocupadas até que 13MB passem. Edit: Isso não se aplica ao destinatário que usa webmail, pois quando ele "baixa um anexo" este já vem sem o encapsulamento. /Edit O exemplo abaixo mostra no Outlook Express 6 como o "tamanho real do e-mail" só aparece se habilitar-mos a coluna "Tamanho", que por default é oculta provavelmente por que é melhor não deixar o usuário comum com essa pulga atrás da orelha;


  • Por motivos de segurança contra SPAM praticamente não é mais possível se enviar um e-mail diretamente para o servidor do destinatário (é, isso costumava ser possível), então mesmo se você tiver uma conexão 24H com a internet e estiver enviando para apenas uma pessoa, sua mensagem tem que obrigatoriamente passar pelo seu servidor de e-mail (acredite, isso não era necessário), o que nos leva aos próximos problemas;
  • Depois que você finalmente conseguiu terminar de fazer o envio, seu servidor coloca sua mensagem em uma fila onde ela vai aguardar sua vez de ser enviada para o(s) servidor(es) do(s) destinatário(s). Dependendo do tamanho dessa fila, do tamanho do seu anexo e da banda de conexão entre seu servidor e o dos destinatários, pode levar um tempo considerável até que o servidor do destinatário receba a mensagem e só depois disso o mesmo vai poder começar a baixar. Isso parece ser um problema menor hoje do que era há dez anos. Na época que a Internet foi "liberada" no Brasil, a elógica (hoje, br.inter.net) tinha um problema que foi "carinhosamente" chamado de "o buraco negro da elógica" pelos usuários da lista noticias-l. A doideira das filas da "semlógica" (outro apelido carinhoso) era tamanha que não era incomum receber uma pergunta horas depois de já ter recebido a resposta. Honestamente faz tempo que eu não vejo isso acontecer, mas também eu já não sou mais usuário da "ecalógica" faz tempo :)
  • Servidores e programas de e-mail não são exemplos de eficiência do ponto de vista do usuário. Quem nunca teve que começar de novo, desde o início, o envio ou recebimento de uma mensagem grande porque o servidor "deixou de responder"?
  • Cada servidor de e-mail tem suas próprias regras quanto ao tamanho máximo de uma mensagem e o usuário geralmente não sabe (mas deveria) o limite do seu próprio provedor e muito menos o dos destinatários. É muito comum enviar um grande e-mail e horas depois receber uma mensagem de erro dizendo que seu tamanho excede as regras do servidor de destino;
  • Sua mensagem pode ser considerada SPAM, virus ou mesmo "inadequada" pelo servidor do destinatário, obrigando-o a enviar de novo, de outra forma. O Gmail, por exemplo, da última vez que testei rejeitava todos os tipos de executáveis, mesmo dentro de arquivos ZIP;
  • Nem todo mundo usa o Gmail com seus vários GB de espaço. Não é muito difícil "entupir" a caixa postal do destinatário de tal forma que ele nem consiga mais receber mensagens;
  • Se seu destinatário usa leitores POP3 como o Outlook Express para descarregar e ler o e-mail, o anexo que você enviou pode atrasar, dificultar ou impedir a leitura de outras mensagens mais importantes que tenham chegado depois, pois pelo menos nos leitores que eu conheço não há opção para saltar uma mensagem. Eu costumava ficar p*to quando usava o OE e só tinha tinha conexão discada e alguém que provavelmente estava no trabalho e não tinha noção do tamanho do que estava mandando me enviava uma besteira qualquer que atravancava toda a minha conexão. E o danado era só descobrir que era inútil depois de ter baixado;
  • A troca de e-mail pela internet não possui um mecanismo eficaz de confirmação do recebimento (em parte por causa da praga do SPAM, mas também existem considerações sobre privacidade). Os que existem dependem da colaboração e honestidade do destinatário (veja na imagem a seguir). A confirmação só funciona mesmo no e-mail corporativo, onde você não pode impedir o remetente (seu colega de trabalho) de saber que você abriu a mensagem se o administrador do sistema definir que ele saiba;




Vantagens
  • Familiaridade - Espera-se que todo mundo que sabe usar um computador saiba usar um programa de e-mail (incluindo webmail) qualquer;
  • Menos trabalho mental - Clique, clique, clique, clique... E já pode se ocupar com outra coisa;
  • Se o seu destinatário é uma empresa podem não existir alternativas. Em certas empresas (eu trabalhei em uma) todo o acesso à internet é bloqueado, exceto o e-mail;
  • Algumas empresas e organizações vão preferir o uso de e-mail não importando as desvantagens, por causa das associações permanentes entre conversas e anexos e a facilidade de se arquivar tudo junto.

Alternativas


  • Se você e o destinatário usam MSN, use a facilidade de transferência de arquivos do programa. Isso requer que o destinatário esteja online e não vai permitir que ele escolha outra hora para baixar o arquivo, mas pelo menos não tem o overhead dos 33% do e-mail e você vai ter confirmação imediata do recebimento. Existe outra desvantagem para o destinatário: como a capacidade de upload geralmente é menor que a capacidade de download na maioria das conexões à internet, ele vai ficar preso à conexão com você mais tempo do que seria estritamente necessário, embora você vá usar toda a sua banda de upload e ele vá ficar com a maior parte da de download dele livre;
  • Use um serviço gratuito de hospedagem de arquivos, como o pioneiro e mais conhecido Rapidshare ou o hotshare.net, que é um dos poucos que "falam português" e pelo menos por enquanto suporta gerenciador de arquivos (testado com Flashget) e parece suportar "resume" (reiniciar o download de onde parou). Veja uma comparação entre as muitas opções existentes. A vantagem é depois poder passar apenas um link para todos os destinatários, que vão baixar o arquivo quando puderem, sem o overhead de 33% (você também faz o upload mais rápido, claro). A desvantagem é a quantidade de passos necessários, pois você tem que fazer o upload do arquivo (não é nada difícil) e depois lembrar de pegar o link e enviar por e-mail para os destinatários. Como isso dobra o serviço e o trabalho mental, as pessoas vão preferir o e-mail ou o MSN. É claro que também não há confirmação do recebimento.
  • Alguns serviços de hospedagem gratuita como o Sendspace lhe dão a opção de fornecer o e-mail do destinatário e ele receberá automaticamente um link para download quando o upload terminar. O problema é justamente que você pode estar "delatando" um e-mail válido de um (possível futuro ex-) amigo para um serviço de reputação questionável que pode acabar usando o endereço para outros fins.

Antigamente, e-mail podia ser mandado direto ao destinatário.

É, mas isso era quando se amarrava cachorro com lingüiça e se podia confiar nos remetentes :)

Nota: Alguns fatos podem não estar 100% certos. Eu conheço o protocolo SMTP como usuário, como programador (se bem que SMTP não requer "programação") e como administrador de site, mas nunca tive o ponto de vista do provedor de e-mail.

O esquema atual, onde você envia a mensagem para o seu servidor, que depois envia para o servidor do destinatário, é tão generalizado que você pode imaginar que não existe (ou existiu) outra maneira, mas existe sim. A porta só está fechada por causa dos spammers.

O protocolo SMTP permite que você deposite o e-mail diretamente no servidor do destinatário, dispensando a necessidade de outro servidor ou até de senha (mas nenhum programa popular de e-mail jamais explorou isso, que eu saiba). Assim se você quisesse enviar e-mails para:

fulano@bol.com.br
beltrano@bol.com.br
cicrano@hotmail.com

Você poderia se conectar a bol.com.br e entregar os e-mails de fulano e beltrano. Depois se conectar a hotmail.com e entregar o e-mail de cicrano. A vantagem disso é que uma vez recebido o OK final do servidor de destino, você tem certeza de que o e-mail foi entregue. E corretamente. Só faltando o destinatário ir lá pegar.

Eu mesmo escrevi um programa simples de e-mail há uns oito anos que funcionava dessa forma, mas hoje ele não funciona mais :(

Em caso de erro você também saberia imediatamente. Hoje quando um e-mail "se perde" fica difícil saber se a culpa é da "infraestrutura" do destinatário ou da sua.

Antigamente nem era preciso de senha para enviar e-mail. Só para receber a autenticação do usuário sempre foi necessária. Os primeiros spammers exploraram isso para fazer com que um servidor qualquer mandasse SPAM por eles. Alguns provedores de acesso então criaram um bloqueio para que você só pudesse enviar e-mail se estivesse conectado à internet por eles (mais ou menos como só poder enviar e-mail pelo Hotmail se o Hotmail fosse seu provedor de acesso). Como isso obviamente não é uma boa solução os servidores foram gradativamente adotando uma extensão do protocolo SMTP que exige senha para o envio.

Mas há um detalhe: a mesma conexão/protocolo que você, usuário, usa (ou usaria) para enviar e-mail diretamente também é usada pelos servidores para trocar e-mails entre si. E obviamente a coisa ficaria complicada se o Hotmail precisasse ter a senha do servidor da Americanas se um usuário do Hotmail precisassse mandar e-mail *@americanas.com.br. Para evitar isso, a regra é que quando você se conecta a um servidor de e-mail para deixar mensagens para usuários desse mesmo servidor, não é necessário senha.

Assim como nenhum servidor de e-mail do planeta precisa de autenticação para enviar e-mail para meu servidor em ryan.com.br. Eles só não podem deixar e-mail no meu servidor que é destinado para pessoas fora dele. Isso só quem pode fazer são meus usuários.

Mas aí os spammers começaram a explorar isso também.

É claro que dá mais trabalho. No modelo antigo bastava depositar uma mensagem com 100 pessoas (até mais) em qualquer ordem no campo CC (Com Cópia) para que o servidor de e-mail dos outros se encarregasse do trabalho sujo. Com a conexão direta o spammer precisava então ordenar suas mensagens por servidor de destino, conectar-se a cada um deles e deixar as mensagens correspondentes (talvez uma só, com CC para todos). Pior que isso: o spammer se conectava e começava a "chutar" nomes de usuário. Os que não davam erro ele sabia que existiam e mesmo que fosse desconectado/bloqueado poderia voltar outra vez com uma lista "certa". Muitos provedores de hospedagem (o meu, inclusive) precisaram proibir o uso do recurso de "catch-all" por causa disso, pois todo e-mail que o spammer chutava dava válido. Eu cheguei a receber uns 1500 spams por dia, quando eu tinha um catch-all e um spammer se "pendurava" no meu domínio. Eu não me incomodava porque era tudo redirecionado para minha conta no Gmail que filtrava quase tudo com perfeição, mas o que eu não sabia é que a carga era significativa para o meu provedor.

Para evitar que isso aconteça, os servidores de e-mail legítimos agora checam o IP de quem se conecta contra uma "blacklist" para saber se pode ser de um conhecido spammer ou de um servidor de e-mail público que anda agindo irresponsavelmente (como quando o IG inteiro entrou na blacklist em 2000). Na verdade o esquema de blacklist já existia, mas acabou por englobar (não sei se "por default" ou "naturalmente") toda a faixa de endereçamentos atribuída a usuários ADSL ou discados. Ou seja: toda a faixa "não fixa".

(des)Graças a isso, eu estava tentando ressuscitar umas rotinas de meu antigo programa de envio de e-mail para usar em outro programa que estou criando mas desisti. Como tanto eu como os possíveis usuários de meu programa iriam usá-lo de uma conexão com IP variável, é quase certo tentar a conexão e receber uma resposta do destino dizendo que você está numa RBL (ou resposta nenhuma).

Bateu saudade daquele tempo, 10 anos atrás... :)

quinta-feira, 19 de fevereiro de 2009

O que há por trás do "fim das multas" da OI.

Ignore a propaganda que diz que isso foi feito "em respeito a você" (como se eu fosse acreditar nisso em algum momento), pois trata-se de mais uma tapeação da OI/Telemar.

Eu não posso falar de todos os contratos de telefonia, mas nos que eu li as multas existiam porque a operadora oferecia a você algum benefício imediato (descontos em celulares, modem grátis, instalação grátis, etc.) que só valeria a pena para ela se você permanecesse cliente por um certo tempo. Também nos que eu li a multa era proporcional ao tempo que faltava para encerrar seu compromisso com a empresa.

Eu considero que se o tal "benefício imediato" é interessante para mim e vale um compromisso de x meses, eu não tenho nada do que reclamar da multa depois. E eu sempre faço as contas.

O que a OI fez foi trocar o "benefício imediato" por um "benefício de longo prazo" e chamar de "bônus" ou "créditos". Nos contratos que li, o bônus começa a ser pago em dez prestações mensais, iguais, dois meses depois do início da relação. No final o contrato é de 12 meses.

Se você decidir deixar a OI antes do prazo contratual, em vez de "pagar a multa" você "deixa de receber o bônus". Se você prestar atenção, é difícil dizer se isso é vantagem para o consumidor que não teve qualquer motivo para querer encerrar seu contrato, já que ele trocou um benefício recebido de imediato por algo diluído em 12 meses. A única vantagem clara é, como a própria OI apontou em outra propaganda, que você pode usar o bônus em qualquer coisa e não apenas em uma "conjunto restrito de coisas" (como modelos específicos de celulares).

Isso se parece mais com "jogo de palavras" do que "respeito ao consumidor" para mim. Mas o marketing da OI sabe explorar a "ingenuidade" das pessoas.

quarta-feira, 18 de fevereiro de 2009

Submarino agindo de má fé na oferta de cartões.

Esse golpe não é novo. Aconteceu comigo uma vez há uns três anos quando comprei minha LG de 29" aproveitando uma oferta muito boa do Carrefour. O preço habitual da TV era de cerca de R$1100 e estava saindo por cerca de R$900 (não eu não caio em papo de oferta, eu andava de olho nessa TV e conhecia o preço) em 12x "sem juros" no Cartão Carrefour. Comprei a TV.

Para a minha surpresa, o extrato do cartão chegou com um acréscimo de cerca de R$3,99 a título de "Taxa de Manutenção". Liguei para a administradora para saber do que se tratava e me explicaram que esse era um valor a ser pago todo o mês em que eu usasse o cartão.

Como eu havia comprado em 12x, por 12 meses eu teria que pagar a taxa, por nenhum motivo além da compra da TV, já que eu não era um cliente habitual do Carrefour. Foi a última vez que usei o cartão deles e agora eu mal entro lá.

Eu esperava realmente que o Submarino não fosse dessa "laia".

No dia 29 de janeiro eu recebi essa oferta do Submarino por e-mail (sou cliente cadastrado. Não é SPAM):





2Todos os clientes que solicitarem o Cartão Submarino Pré-Aprovado nesta promoção,
entre 29/01/2009 até 01/02/2009, terão anuidade grátis para sempre.
Favor desconsiderar a cláusula 6.1 referente à cobrança de anuidade que consta no contrato.



Eu ainda não tinha o Cartão Submarino (sempre comprei com meu VISA) e já que não teria que pagar anuidade, fui conferir a possível pegadinha na oferta de pendrive por R$2.

Quanto ao pendrive não tinha do que reclamar pois era um Kingston de 1GB. Mas eu quase recuei quando vi o custo do frete: R$18.

Como eu estava interessado em um livro também, coloquei Crepúsculo no carrinho para ver por quanto sairia. Quando sinalizou que o frete então seria grátis para ambos, concluí que o negócio era muito bom, pois o livro e o pendrive entregues na minha porta iam me custar R$29,90.

Até a entrega, não tive do que reclamar do Submarino. O meu aborrecimento começou quando finalmente recebi a senha do cartão e pude ir pagar o boleto online: A cobrança era de R$32,89.

Quando fui checar o detalhamento do extrato, lá estava a maligna "taxa de manutenção", de R$2,99.



OK. Legalmente, "sem anuidade" não significa "sem custos". Mas acho que para quase 100% da parcela da população que sabe o que é um cartão de crédito, significa sim. Trata-se de evidente má fé.

Este é o exemplo de extrato no Guia de Uso. O "custo de manutenção" convenientemente não aparece aqui:

Como o boleto pode ser pago parcialmente, eu paguei apenas os R$29,90 da minha compra. Já vi pelo contrato que eu só posso cancelar o cartão depois de pagar todo o débito, então não vou cancelá-lo, mas não vou pagar isso nem que a vaca tussa. Estou só esperando por um dia em que eu esteja bem "zen" para comunicar isso por telefone a eles. Segundo o que entendi do contrato, se não houver mais nenhuma surpresa, isso vai me custar por mês em taxas (15% + 2% +1%) 54 centavos. Vou "pagar prá ver" (ou seria "não pagar"?) se eles tem a coragem/audácia de me colocar no Serasa por isso.

Depois de ter pago pela internet, o boleto em papel chegou (a próposito, o vencimento era no dia 15 e o boleto chegou no dia 16). Nele eu encontrei o único exemplo de honestidade de toda a operação (claro, porque eu já havia sido fisgado):



Em nenhum outro momento o Submarino avisou sobre essa taxa.

A propósito, eu li o contrato entregue pelo correio e seus termos fazem do Cartão Submarino um troço nojento, do tipo que deve ser tocado com luvas e segurado à distância para não ofender o olfato.

Edit: Eu entendo que os R$2,99 cobrados podem ser devidos à necessidade de se pagar ao banco (no caso, o Santander) pela emissão do boleto e ao contrário do que diz o Procon eu acho essa cobrança justa, desde que eu saiba com antecedência que vou pagar por boleto e que a taxa existe. Como eu não fui avisado de nenhuma das duas coisas com antecedência e não tenho opção de pagar por nenhuma forma que evite a cobrança (incluindo depósito em conta), considero que houve má fé e não reconheço a dívida.

Mais um exemplo de "golpe da hospedagem".

Na semana passada, dois de meus clientes pediram minha opinião sobre boletos que receberam pelo correio de uma tal ABHS (Associação Brasileira de Hospedagem de Site). Eu peguei um deles para mostrar aqui:


A intenção do golpe é a mesma do caso do Nicregistro.com: Torcer para que a pessoa confunda o boleto com a cobrança anual de registro de domínio ou de hospedagem e pague. No caso acima nota-se que tomaram diversos cuidados para dificultar uma prova da fraude, como deixar claro que o pagamento é "facultativo".

Nem chegam perto do descaramento do NicRegistro, que usou até o mesmo tipo de fonte do Registro.BR em sua logomarca, mas ainda assim fica óbvia a má intenção.

Por acaso alguém pode enviar correspondência para alguém onde a cobrança é maior que a descrição (praticamente inexistente) do serviço e alegar honestamente que não está tentando ser confundido com um credor habitual do destinatário? Ninguém vai conseguir me convencer disso. O desatento que cair nessa vai ter pouquíssimas chances de reaver o dinheiro.

Um exemplo de quem faz isso com seriedade é a editora Abril (pelo menos, até a última vez que eu vi), que até envia boletos não-solicitados mas sempre como parte de uma correspondência maior, que desde a impressão no envelope não deixa a menor dúvida de que se trata de uma oferta e não de um débito.

Assim como no caso de NicRegistro (cujos sites nicregistro.com e nicregistros.com.br já sumiram), os pilantras criaram um site para dar maior veracidade ao golpe (inclusive é ".org" para não parecer uma empreitada comercial) e chamam as empresas que receberam o boleto de "associados", como se houvesse a mínima chance de meus clientes terem se associado a esse tipo de coisa.

O CNPJ é real. Basta acessar esta página da Receita Federal e consultar o número 10423985000111. Mas também perceba que, como na maioria desses golpes, o cadastro deles é bem recente: apenas quatro meses. Com só esse tempo no mercado eu não confio nem em vendedor do MercadoLivre.

Enquanto não houver uma lei proibindo o envio de boletos por serviços não solicitados (como já existe para o envio de cartões de crédito não solicitados), os pilantras vão continuar conseguindo aplicar esse golpe à vontade.

Isso ainda não é ilegal (pelo menos eu acho que não é), mas um dia vai ser.

domingo, 15 de fevereiro de 2009

Mais um firmware alternativo para o LG DV397H.

A coisa está melhorando :)

Um usuário com experiência em assembly juntou-se ao esforço coletivo de desenvolver algo melhor para o DivX player da LG e publicou no fórum um firmware com algumas melhorias interessantes.

Além disso, Rictad está esclarecendo como fez as modificações. Algo muito importante por causa da carência de documentação dos hacks nos firmwares LG. Isso poderá eventualmente ajudar a implementar as mesmas modificações em outros modelos. 

quinta-feira, 5 de fevereiro de 2009

Conectores USB de 10 pinos.

Confesso que eu deveria ter notado isso antes. De cara é bom lembrar que o padrão de comunicação USB só utiliza quatro fios.

Este é um conector USB "mini-B" do mesmo tipo usado em centenas de aparelhos. Se você tem um aparelho USB portátil, provavelmente o conector é assim:


E este é o plug correspondente, que você encontra em qualquer loja de informática:



Perceba que são apenas cinco contatos e as lâminas de um deslizam sobre as trilhas do outro. Os dois conectores acima, até onde sei, estão dentro da especificação USB.


Porém este é o conector USB do meu celular JC777S+:


Você pode ver perfeitamente as cinco lâminas, mas é muito difícil ver as trilhas sem ângulo de visão e iluminação favoráveis. Dá para "acreditar" que elas estejam lá baseado em dois indícios:
  • Compare esta foto com a do conector padrão. Perceba que a ilha de plástico central é bem mais magra.
  • Note os cinco orifícios negros de cada lado da ilha. Pelos cinco inferiores passam as lâminas. Pelos outros passam as trilhas.
O plug USB padrão encaixa normalmente no conector acima, por isso se você não prestar atenção não percebe que existe uma diferença. Eu mesmo só percebi que havia algo errado por dois motivos:
  • Os diagramas de conexão para instalação de firmware em celulares chineses mostram um conector com o formato de um mini-USB, mas com 10 pinos;
  • O plug de fone de ouvido do celular é USB e é detectado quando inserido, como acontece com um dispositivo USB qualquer, mas o fone é vagabundo demais para ter uma interface USB embutida.
Detalhe do plug "USB" usado no fone de ouvido. A resposta está nos cinco contatos extras:



O artigo na Wikipedia não faz a menor menção à existência desses conectores. E não estou com saco para ler pessoalmente a especificação USB à procura disso, até mesmo porque acho que seria perda de tempo. 

E não, este não é um "hack chinês" da especificação USB. Está mais para "hack asiático" porque eu fui conferir na minha câmera Canon A630 (a Canon é japonesa) e ela usa o mesmo conector.

Edit: Exemplo de fabricante que chama esse conector de "MINI USB 10PIN". Ignore o desenho mostrado na página, porque é claramente de um mini-B padrão.

Foto: