 |
gildot |
 |
| |
 | Contribuído por vd em 31-08-04 9:10
do departamento email-news | |  | |  | | |  Após a discussão da MSFT sobre a possibilidade de haver um "caller id" nos emails, garantindo assim a autenticidade do mesmo e combatendo o spam, o sendmail disferiu a primeira facada, antecipando-se com o sender id. Este é uma implementação hibrida do Caller ID da MSFT, onde as duas estão a trabalhar em parceria para desenvolver um standard, criado pelo dono da pobox.com - Meng Wong.
Ainda sobre email, a Netline Internet Service que comercializa um concorrente ao Exchange da MSFT, disponbilizou o seu produto em opensource, com licença GPL, o OPEN-XCHANGE™ Server. | | | | | |
Quem quiser testar a funcionalidade de "sender id" do sendmail, pode instalar o modulo sid-milter. < XChat para Windows agora é a pagantes | Americas Army: Recrutamento Online em Linux > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Não me parece que esta tecnologia traga algo de mais que já não esteja disponível usando, - servers IMAP com autenticação SSL implementada
- mensagens assinadas digitalmente
IMHO acho que a tecnologia PKI existente fornece um melhor serviço do que o que está aqui proposto.
|
| | | | | | A certificação resolve-te um problema, sim, mas cria-te outro: o custo.
Por outro lado, o SPF também cria problemas (principalmente com o forwarding), por isso também não é a magic-bullet para o problema da falsificação de endereços (gerir forwards e MX secundários é uma merda com SPF). Mas tem duas grandes vantagens em relação à certificação:
1 - Custo negligenciável
2 - Interacção nula com os end-users (não que alguns administradores de MTA sejam muito melhores, mas sempre são mais fáceis de "gerir" que a grande massa de utilizadores finais de e-mail).
Apesar de publicar records de SPF nos meus domínios, ainda estou à espera de ver o que sai das DomainKeys do Yahoo. Tecnicamente, parece-me ter mais probabilidade de sucesso. Mas como o SPF é apoiado pela MS e pelo AOL, vamos lá ver...
|
| | | | | (Olá! Há que tempos... How's life?) Relativamente a spam, alguma experiência c/ greylisting?
hugs
Strange |
| | | | Sim. É, pelo menos por enquanto, bastante eficiente. Mas cria-te um problema muito chato de gerir no contexto de um ISP: o delay nas mensagens. Cada tuplo novo (i.e., cada mensagem de alguém novo e/ou de uma origem nova) é, como deves ter visto na descrição funcional, sujeito a um delay, que para resultar deve ser no mínimo de 30 minutos (testes reais). Para road-warriors, isto é do piorio.
Também não é muito simpático para os peers remotos, que podem não achar piada a ver a queue sempre elevada nas mensagens para ti. E não te resolve os problemas de open-relays ou spambots recentes (os primeiros, porque são MTA, logo fazem retries. Os segundos, porque usam o MTA configurado no Outlook, tipicamente o do ISP, e é esse que vês). Como a tendência parece ser cada vez mais um aumento no número do segundo, não acredito que o greylisting vá ser tão eficaz durante muito mais tempo...
|
| | | | Onde foi que eu li que a Novell ia pôr em OSource o exchange deles? Ou foi só o "conector" para o MSExchangeda, da Ximian? Não me recordo lá muito bem.
"No comments"
|
| | | | | | O Groupwise??? Acho que isso tão cedo não vai acontecer...
---
MS Windows, há 10 anos que a taskbar no topo do ecrã gera um bug. |
| | | | Não, o servidor de email da SuSE. Mas também temos o OpenGroupware.
"No comments"
|
| | | | | Onde foi que eu li que a Novell ia pôr em OSource o exchange deles? A notícia está no artigo acima. O link para o anúncio está aqui. Já agora, uma notícia sobre a reorganização da Novell. O meu obrigado à LWN pelos links. Cumps.
"mudem de rumo, já lá vem outro carreiro" |
| | | | Eia, é verdade. Por isso o nome era tão familiar.
"No comments"
|
| | | | Bom, o que vou dizer aqui pode ser completamente estúpido, uma vez que não tenho noção de todas as realidades. No entanto, tenho noção de algumas realidades, e nessas realidades o que vou dizer aplica-se perfeitamente. Peço aos outros leitores que me corrijam onde estiver errado ou que me façam ver a questão por outros pontos de vista que potencialmente eu possa não ter abordado.
A solução que eu prefiro pessoalmente, tendo em conta aquilo que tenho ao meu dispor neste preciso momento para evitar o spam e os worms é usar os recursos actualmente disponíveis, como os MX e A records para verificar se o host de onde saiu o mail é responsável pela recepção de mail para o domínio de onde diz que o mail que recebi veio.
Isto pode efectivamente causar problemas com mailing lists, mas aqui o problema é das próprias mailing lists. A implementação correcta de uma mailing list deveria conter SEMPRE o endereço da própria mailing list no "From:" e opcionalmente (no caso de listas como a lkml) incluir um "Reply-to:" para informar que a resposta deve ser dada directamente ao sender, não à mailing list. Hoje em dia as mailing lists fazem exactamente o contrário: colocam o sender no "From:" e opcionalmente o endereço delas próprias no "Reply-to:".
Obviamente ao fazer isto, as mailing lists estão a criar uma situação de spoof que é detectável. Opcionalmente sempre se pode adicionar "trusted relays" até que as mailing lists mudem.
Existe ainda uma alternativa para o problema das mailing lists mais radical: deixar de usar SMTP e começar a usar NNTP. O NNTP até oferece condições muito melhores para chit chat que as mailing lists, pois permite identificar facilmente quem responde a quem devido à organização das mensagens em threads.
Não compreendo a utilidade dos mail forwarders para alem de bulk mail. Pergunto-me se nos casos em que é preciso fazer forward de mail não seria mais rentavel usar os mesmos recursos que se usa nas deliveries normais e colocar esse bulk mail com menos prioridade na queue. Os recursos que antes eram apenas usados para forward estão agora livres para as mesmas tarefas que os restantes (regular deliveries com prioridade mais alta, bulk deliveries com prioridade mais baixa). Com a nova estratégia distribuída não só o bulk mail continua a ser enviado durante as horas de menos tráfego como as deliveries normais são tratadas mais rapidamente devido à adição de recursos.
Claro que há casos em que a rede de onde se fazem as regular deliveries não tem recursos suficientes para fazer bulk deliveries. Nesses casos é preciso contratar serviços de empresas externas, mas para esses casos também há solução: cria-se um sub-dominio onde será devidamente configurado um MX record que autorize o bulk server a usá-lo. Em relação às mensagens enviadas através do bulk server, as mesmas regras que descrevi em cima sobre a correcta implementação de uma mailing list devem ser aplicadas aqui.
Portanto, a minha questão é bastante simples: para quê complicar o que é simples? Porquê extender protocolos quando a correcta utilização dos actuais resolve os problemas existentes?
Mais uma vez volto a repetir que o meu conhecimento da realidade é limitado, portanto podem haver casos que não tenha previsto e gostaria de os ler a fim de averiguar até que ponto é que a minha solução simples é consistente.
"Better die in failure than live in hope." |
| |
|
