Gmail - recibo de leitura

[Valium]

Falha de segurança ou não, para algumas pessoas envio com o aviso de receção e leitura, muitas entidades aceitam-nos sem intervenção do destinatário, pelo que é sempre mais dificil "ainda não li" ou "não recebi", com os bancos por exemplo quando necessito de enviar alguma informação, pois o confirme pode demorar uns dias...

Quando me pedem e conheço o remetente também acuso a leitura, não vejo mal nenhum nisso.

 

[Nuno156]

Falha de segurança ou não, para algumas pessoas envio com o aviso de receção e leitura, muitas entidades aceitam-nos sem intervenção do destinatário, pelo que é sempre mais dificil "ainda não li" ou "não recebi", com os bancos por exemplo quando necessito de enviar alguma informação, pois o confirme pode demorar uns dias...

Quando me pedem e conheço o remetente também acuso a leitura, não vejo mal nenhum nisso.

Mesmo com READ RECEIPT não podes acusar o destinatário de ter lido a
mensagem, se ele disser que não leu.

Exemplo:
Tens o "preview" activo no teu programa de e-mail.
O teu programa de e-mail está configurado para marcar como lido assim
que a mensagem é apresentada no preview.
Usas as setas para avançar (ou recuar) para um e-mail no qual queres
trabalhar. Passaste pelo tal que ainda não tinhas lido. O programa envia
um recibo de leitura. E o destinatário ainda não o leu.

Portanto...

Também existe o oposto.
Há programas configurados para marcar como lido apenas quando se abre
o e-mail numa janela separada. Logo, as pessoas podem ler os e-mails
todos sem que o remetente receba um recibo de leitura.
Até acontece receber avisos de que a mensagem foi APAGADA sem ter sido
lida (porque foi lida no preview).

 

[Nuno156]

Acho que o pessoal dá demasiado valor aos recibos de leitura/entrega.

 

[Titanio]

Falha de segurança ou não, para algumas pessoas envio com o aviso de receção e leitura, muitas entidades aceitam-nos sem intervenção do destinatário, pelo que é sempre mais dificil "ainda não li" ou "não recebi", com os bancos por exemplo quando necessito de enviar alguma informação, pois o confirme pode demorar uns dias...

Quando me pedem e conheço o remetente também acuso a leitura, não vejo mal nenhum nisso.

E será que esses avisos de recepção resolvem alguma coisa? Isso não vai acelerar coisa nenhuma por parte dessas entidades. Se tiverem que dar alguma desculpa, dão-na de igual modo.

Pessoalmente considero que os avisos de recepção são uma intromissão na vida dos outros e é por isso que nunca envio nenhum, seja por email seja em papel. Ninguém me pode obrigar a ler, receber ou assinar o que quer que seja; isso é do meu livre arbítrio e ninguém tem nada com isso.

 

[SPV]

Acho que o pessoal dá demasiado valor aos recibos de leitura/entrega.

~lol


Porque tu nao usas ... os outros dão valor a mais , tá certo

Entendo o recibo como uma carta registada com aviso de recepção ... para mim , é importante nao dou demasiado valor , dou o valor que merece , é util, é algo que uso desde sempre.

Quantas vezes envio um mail com algo , e assim que que recebo o recibo pego no telefone e ligo a explicar melhor o que queria com o email.

 

[augustus]

É um pouco como o Nuno diz, a melhor forma de saber se o email foi entregue ou não é aguardar pela mensagem de erro que dá caso esta seja rejeitada ou por blacklisting, mailbox cheia, endereço inválido ou outra razão qualquer.

Os recibos de entrega e leitura são óptimos para mailboxes do mesmo servidor (ou domínio), normalmente Exchange da Microsoft, cujas transacções são bem mais fáceis de controlar por esta lógica.

Hoje em dia a maior parte dos servidores têm um SPF record (validação de mailboxes) que dão-nos mais garantias de que os emails são efectivamente entregues.

 

[Nuno156]

~lol


Porque tu nao usas ... os outros dão valor a mais , tá certo

Entendo o recibo como uma carta registada com aviso de recepção ... para mim , é importante nao dou demasiado valor , dou o valor que merece , é util, é algo que uso desde sempre.

Quantas vezes envio um mail com algo , e assim que que recebo o recibo pego no telefone e ligo a explicar melhor o que queria com o email.

A carta registada com aviso de recepção funciona porque a entidade
a quem tu pagas pelo serviço assegura-te que não deixa ler a carta,
nem a entrega, sem que o recibo seja assinado.

No e-mail isso simplesmente não é verdade. Não existe nenhuma
garantia. Não existindo garantia... o valor é nulo.

Portanto, continuo a dizer: dão demasiado valor aos recibos de
leitura/entrega.

Lá que o teu caso seja especial (as pessoas estão contratualmente
obrigadas), não significa que o que eu disse não tenha validade.

Seja como for, e referindo-me apenas ao teu caso especial, ou essas
regras valem só para dentro (e-mails internos), ou então os responsáveis
pela segurança baixaram as calcinhas aos burocratas. Já agora... também
são obrigados a mudar a password de X em X tempo?

 

[Nuno156]

É um pouco como o Nuno diz, a melhor forma de saber se o email foi entregue ou não é aguardar pela mensagem de erro que dá caso esta seja rejeitada ou por blacklisting, mailbox cheia, endereço inválido ou outra razão qualquer.

Os recibos de entrega e leitura são óptimos para mailboxes do mesmo servidor (ou domínio), normalmente Exchange da Microsoft, cujas transacções são bem mais fáceis de controlar por esta lógica.

Hoje em dia a maior parte dos servidores têm um SPF record (validação de mailboxes) que dão-nos mais garantias de que os emails são efectivamente entregues.

O SPF não é para dar garantias de entrega.
O SPF é para "garantir" (na medida das possibilidades) que o remetente é legítimo.
Isto é: que o domínio do endereço indicado como remetente pode usar o servidor
que está a entregar o email ao servidor do destinatário.

Basicamente o servidor do destinatário olha para o endereço do remetente, contacta
o domínio do endereço, pede o registo SPF, e verifica se o endereço IP do servidor
que está a entregar a mensagem está na lista dos servidores autorizados indicados no
registo SPF, e actua de acordo com o definido na regra SPF.

 

[SPV]

A carta registada com aviso de recepção funciona porque a entidade
a quem tu pagas pelo serviço assegura-te que não deixa ler a carta,
nem a entrega, sem que o recibo seja assinado.

No e-mail isso simplesmente não é verdade. Não existe nenhuma
garantia. Não existindo garantia... o valor é nulo.

Portanto, continuo a dizer: dão demasiado valor aos recibos de
leitura/entrega.

Lá que o teu caso seja especial (as pessoas estão contratualmente
obrigadas), não significa que o que eu disse não tenha validade.

Seja como for, e referindo-me apenas ao teu caso especial, ou essas
regras valem só para dentro (e-mails internos), ou então os responsáveis
pela segurança baixaram as calcinhas aos burocratas. Já agora... também
são obrigados a mudar a password de X em X tempo?

Mas eu nao uso o recibo como garantia de nada ... eu uso apenas para minha informação nada mais , apesar de ser politica interna e constar nas regras de utilização , como é obvio apenas emails dentro do nosso domínio. Os responsaveis pela segurança estão em Palo Alto, eles lá saberão , não é a minha especialidade.

Sim , a password é de mudança obrigatória.

 

[SB]

recibos de leitura []

tenho um BB com email corporativo, e tenho o habito (tenho que o alterar) de os abrir logo no telemóvel.

Problema: vêem que já recebi e que demoro muito a dar a resposta []

 

[Titanio]

A carta registada com aviso de recepção funciona porque a entidade
a quem tu pagas pelo serviço assegura-te que não deixa ler a carta,
nem a entrega, sem que o recibo seja assinado.

No e-mail isso simplesmente não é verdade. Não existe nenhuma
garantia. Não existindo garantia... o valor é nulo.

Portanto, continuo a dizer: dão demasiado valor aos recibos de
leitura/entrega.

Lá que o teu caso seja especial (as pessoas estão contratualmente
obrigadas), não significa que o que eu disse não tenha validade.

Seja como for, e referindo-me apenas ao teu caso especial, ou essas
regras valem só para dentro (e-mails internos), ou então os responsáveis
pela segurança baixaram as calcinhas aos burocratas. Já agora... também
são obrigados a mudar a password de X em X tempo?

Nem isso é tão linear, porque ninguém pode obrigar o destinatário a assinar o Aviso de Recepção. Eu não os assino (e não recebo a carta)! Como nunca ninguém me manda cartas com AR para me dar alguma coisa, o interesse é sempre do lado de lá []

 

[augustus]

O SPF não é para dar garantias de entrega.
O SPF é para "garantir" (na medida das possibilidades) que o remetente é legítimo.
Isto é: que o domínio do endereço indicado como remetente pode usar o servidor
que está a entregar o email ao servidor do destinatário.

Basicamente o servidor do destinatário olha para o endereço do remetente, contacta
o domínio do endereço, pede o registo SPF, e verifica se o endereço IP do servidor
que está a entregar a mensagem está na lista dos servidores autorizados indicados no
registo SPF, e actua de acordo com o definido na regra SPF.

Não era minha intenção dizer que era garantia de entrega.

Hoje em dia, há muitos servidores de email que rejeitam o envio para outros que não tenham um SPF record.

 

[Nuno156]

Mas eu nao uso o recibo como garantia de nada ... eu uso apenas para minha informação nada mais , apesar de ser politica interna e constar nas regras de utilização , como é obvio apenas emails dentro do nosso domínio. Os responsaveis pela segurança estão em Palo Alto, eles lá saberão , não é a minha especialidade.

Sim , a password é de mudança obrigatória.

Nesse caso está OK.
Ter isso para fora é um problema de segurança.

Quanto à password... já vi que são dos que seguem à risca o ISO/IEC 17799/27002...
Coitados...

 

[Nuno156]

Nem isso é tão linear, porque ninguém pode obrigar o destinatário a assinar o Aviso de Recepção. Eu não os assino (e não recebo a carta)! Como nunca ninguém me manda cartas com AR para me dar alguma coisa, o interesse é sempre do lado de lá []

Não estou a falar disso.
Estou a falar do facto de os e-mails com pedido de Read Receipt (RR) ser
entregue, e lido, sem no entanto enviar qualquer RR. Coisa que não acontece
nas cartas Registadas c/AR.

 

[Nuno156]

Não era minha intenção dizer que era garantia de entrega.

Hoje em dia, há muitos servidores de email que rejeitam o envio para outros que não tenham um SPF record.

Não será ao contrário?
Servidores que rejeitam e-mails originários de domínios sem SPF...

Não estou a ver qual o problema em obrigar a que o destinatário tenha
registo SPF. É que o registo SPF serve para validar o remetente, e não
o destinatário.

Aliás, SPF significa Sender Policy Framework.
[]

 

[augustus]

Não será ao contrário?
Servidores que rejeitam e-mails originários de domínios sem SPF...

Não estou a ver qual o problema em obrigar a que o destinatário tenha
registo SPF. É que o registo SPF serve para validar o remetente, e não
o destinatário.

Aliás, SPF significa Sender Policy Framework.
[]

Exacto! O problema que tive em 2008 foi precisamento o de não poder enviar por incapacidade de verificar o remetente (do outro lado).

Rejeição por não conseguir identificar o "sender". []

 

[augustus]

Exemplo de uma mensagem devolvida:
---------------@clix.pt
SMTP error from remote mail server after RCPT TO:<---------------@clix.pt>:
host smtp.clix.pt [195.x.x.x]: 550 See http://spf.pobox.com/why.html?sender=suporte@----------.pt&ip=X.X.X.X&receiver=-----.isp.novis.pt (#5.7.1)

O que confere porque a máquina que estava a fazer o relay não tinha qualquer registo SPF...

 

[Nuno156]

Exacto! O problema que tive em 2008 foi precisamento o de não poder enviar por incapacidade de verificar o remetente (do outro lado).
Rejeição por não conseguir identificar o "sender". []

Não conseguir enviar é quando estás a usar um servidor de envio que não
está na lista dos autorizados para o domínio do endereço de remetente
que estás a usar.

Exemplo:
Estar a enviar um email como XXX@gmail usando um servidor do SAPO.

 

[Nuno156]

Exemplo de uma mensagem devolvida:
---------------@clix.pt
SMTP error from remote mail server after RCPT TO:<---------------@clix.pt>:
host smtp.clix.pt [195.x.x.x]: 550 See SPF: Why (#5.7.1)

O que confere porque a máquina que estava a fazer o relay não tinha qualquer registo SPF...

Não é por aí...
Primeiro, não são as máquinas (de mail) que têm os registos SPF. São os domínios.
Segundo, RCPT TO não tem a ver com o registo SPF.

O que é validado é o MAIL FROM.

O domínio do MAIL FROM é que tem que ter um registo SPF que inclua o endereço
IP da máquina usada para entregar a mensagem.

 

[augustus]

Não conseguir enviar é quando estás a usar um servidor de envio que não
está na lista dos autorizados para o domínio do endereço de remetente
que estás a usar.

Exemplo:
Estar a enviar um email como XXX@gmail usando um servidor do SAPO.

Ou seja, neste caso, é de enviar mas o outro rejeitar.