mta-hashcash

mta-hashcash@lists.lysator.liu.se

244 discussions

Gold & diamonds: Rolex
by nani mcqueen 22 Jul '06

22 Jul '06

TOP BRANDS - LOW LOW COST Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets Leather, silk and white gold sound good? Visit our site for real photos. Everything comes with a certificate, tags and all the extras, plus a warranty. http://nerginflk.com/luxury/ guinea grains wheel plate thrasher whale axle rougher engine-room telegraph cam press thistle noble check roller fish wire still-closed leather-cutting Pre-israelitish pseudo prosperity coal dump two-pin escapement sour-visaged spirit-soothing nut crab town-imprisoned all-nourishing Pro-allied bend leather cushion maker peacock pheasant sad-looking slow-combustion land rock

1 0

(NS) Informativo :: Excelencia global ::
by Excel�ncia Global 08 Aug '05

08 Aug '05

Segunda-Feira, 8 de Agosto de 2005 - ano I - no. 3 O SITE OFICIAL DOS CONCURSOS PÚBLICOS PROFESSOR DE EDUCAÇÃO BÁSICA (PEB I e II) - Filosofia e Educação Física Edital Publicado - 15.308 vagas para professor no Estado de São Paulo - Inscrições de 11 a 19 agosto. CONFIRA AQUI TODAS AS INFORMAÇÕES. OFICIAL DE JUSTIÇA - Edital iminente. PREPARE-SE JÁ! Apostilas disponíveis. Em breve 558 vagas para São Paulo e Interior. Confira aqui as informações.! AGENTE DE TELECOMUNICAÇÕES DA POLÍCIA CIVIL - SP. - Edital publicado. Inscrições: 17 a 23 agosto - Confira aqui edital completo e apostilas disponíveis. PROCURADOR DO ESTADO DE SÃO PAULO - Edital publicado. 100 vagas. Inscrições: 11 a 19 agosto. Confira aqui edital completo, e legislação. PROGRAME-SE - PREPARE-SE JÁ. 49 CONCURSOS PÚBLICOS PREVISTOS PARA 2005. Confira aqui todas as informações divulgadas. Apostilas disponíveis. 67 CONCURSOS PÚBLICOS EM ANDAMENTO - MUITAS OPORTUNIDADES PARA VOCÊ! Clique aqui e acompanhe todos os concursos públicos em andamento no Brasil. FÓRUM - LEIA E PARTICIPE - Tudo sobre Concursos Públicos e Empregos. Fórum Especial: descubra o que não querem que você saiba! www.excelenciaglobal.com.br - TUDO SOBRE CONCURSOS PÚBLICOS. Milhares de informações gratuitas e atualizadas diariamente para você. Cadastre-se e receba o informativo. Esta mensagem eletrônica obedece, rigorosamente, o Código de Etica Anti SPAM , publicado em 11.11.03 (www.brasilantispam.org). Caso não queira mais receber esta mensagem clique aqui. This electronic message obeys, rigorously, the Code of Ethic Anti Spam, published in 11.11.03 (www.brasilantispam.org). In case that you don't want to receive this message anymore click here. © Instituto Excelência - Todos os direitos resevados www.excelenciaglobal.com.br

1 0

Concursos Públicos .: Portal Excelência :.
by Portal Excel�ncia 16 Jun '05

16 Jun '05

1 0

Key exchange
by Linus Nordberg 03 Nov '04

03 Nov '04

Should XHASHCASHNEWKEY be accepted only after MAIL and before RCPT, as the draft says? We want a way of charging lots of hash cash for accepting keys. Accepting as non-tentative, that is. We also want accepting of keys to depend on other criterias. But this is all policy. What should the draft say and what are the ideas on how to implement some of the foreseeable policies?

2 6

Forward path vs. recipient
by Linus Nordberg 21 Oct '04

21 Oct '04

What's the relation between the terms "forward path" and "envelope recipient"? The draft says "forward path" nowadays.

2 2

Initial reactions
by Simon Josefsson 21 Oct '04

21 Oct '04

Hello all, I read your draft, belated. I'm sure you have discussed and solved these issues already, but just for reference, below were my initial thoughts on the proposal. I am not fully convinced by section 6 and 9.2, in particular: that it is impossible to abuse the MAC key management scheme. If a spammer can somehow fool you into talking to them, it seem the scheme is ruined. There may be subtle technical issues here. There may even be non-technical concerns with the approach; i.e., merely because you talk to someone doesn't mean you want them to talk to you. If the idea and server implementation mature, I can probably be fooled into implementing some basic support for this in Emacs' smtpmail.el. Thanks. Secondary mail servers ---------------------- There is no discussion how primary and secondary MX's interact, if they do at all. If they are intended to interact, I believe that may be a serious deployment issue. My experience is that secondaries cannot be assumed to have useful out of band communication with the primaries. Inventing and deploying a protocol to keep some information synchronized between MX's appear to me complicated. One of nice properties of the mail system design is that different MX's for a domain can be separated to a big extent, making them interact more closely seem like an unwanted direction. To illustrate the degree of separation between MX's: some secondaries may not even know the complete list of which domains they are secondaries for (see sendmail FEATURE(`relay_based_on_MX')). If however the MX's for a domain are not intended to interact, I guess I do not understand how the secret key authentication is going to work. As far as I understand, the keys are stored in a database indexed on SMTP envelope addresses corresponding to recipient and receiver. Consider then a client that is sending mail to user@domain via mail1.domain and mail2.domain. Which keys are used, and how are they negotiated? One idea: Instead, have the keys be shared between two MTA's, and index the database on MTA names. MTA "A" share a key with MTA "B". Since MTAs can be known under many names, the canonical name should be used, i.e., the <Domain> field of the 220 initial response. Note that policy matters, such as one disabling the use of MAC keys per-user, is still possible with this approach, as far as I can tell. Input to MAC computation ------------------------ The draft says: If a key is found, it is used to form a MAC on data consisting of sender and receiver id (in that order), selected headers, and the message body. The header lines included are From, To, Cc, Date, Content-type and Message-id. They are followed by an empty line, and then the message body, without transport encoding (to allow MTA's to change the transport encoding of messages in transit). The resulting MAC is provided to the receiver during the SMTP transaction. What do you mean by "transport encoding"? MIME Content-Type-Encoding? If so, that appear to require a MIME decoder in the MTA, which is complex. Further, decoding a large e-mail may require large amounts of storage. Not all MIME libraries are written to make one-pass MAC computation easy. Finally, the format of decoded MIME objects is not well defined, which seem to be required for MAC computations. Only the MIME encoding is well defined. One idea: Do the MAC on the data that is actually sent on the wire. Security properties of the MAC ------------------------------ There should be a security section on the highly specialized property required from the MAC: that it is computationally infeasible to produce a prefix MAC value with given value. As far as I am aware, existing MACs are not designed for this property. I suspect this property may collapse into more well known MAC properties. It would be neat if there was a nice reduction from this special property into more well studied properties. I.e., "if you can break the MAC for this property, you can break the same MAC for common MAC properties". Btw, what kind of MAC's are you thinking of? HMAC-SHA1 may be the simplest choice, even though I would prefer something based on a block cipher. The choice of MAC seem critical to get "fair" computation costs, i.e., it should be difficult to optimize the MAC much more compared to typical implementations. MUA discussions --------------- In an ideal world, MUAs don't talk to MTAs, they talk to MSAs. See RRC 2476. There may be some consequences for how the MUA discussions are phrased. One might even consider introducing special protocol elements for MUA<->MSA, to specify policy matters. I'm not sure that is a good idea, though.

3 2

Minor comments to draft
by Linus Nordberg 21 Oct '04

21 Oct '04

In section 5, the terms challenge message and prefix seem to mean the same thing. Typo fixes in attached patch.

2 2

Seminar on spam in Stockholm next tuesday
by Linus Nordberg 19 Oct '04

19 Oct '04

ISOC-SE inbjuder alla intresserade till seminariet ************************************************** SPAM - Vad görs åt det från stat och tekniker? Vilket är värst - plågan eller botemedlet? ************************************************** Alla klagar på vädret men ingen gör något åt det, brukar det heta. Alla klagar också på nät och brevlådor igenslammade med SPAM; vi skall få höra vad som görs åt detta med lag och teknik som verktyg. Ola Svensson, handläggare på Konsumentverket med uppgift att bekämpa SPAM med marknadsföringslagen som medel skall berätta om Konsumentverkets regeltillämpning på området. Amar Andersson, Internetprofil m m på TeliaSonera kommer att berätta om hur spammers agerar idag, hur nätoperatörer gör för att hindra SPAM, och om vilka problem SPAM innebär för nätoperatörerna som ISPer. Slutligen kommer Henrik Nilsson, jurist på advokatfirman Bird & Bird och styrelsledamot i ISOC-SE att reflektera över frågan om botemedlen är nog så illa som plågan vad avser SPAM. Finns det alls förutsättningar för lagregleringar kan ge önskat resultat eller stör de kommunikationerna mer än hjälper? Mer information om seminariet finns på www.isoc.se/ Seminariet är kostnadsfritt och öppet för alla. Inbjudan får vidarebefordras i oförändrat skick. Tid: 26 oktober kl 17.30 - ca 20.00 Plats: Lärarhögskolan i Stockholm, Kyrksalen, Hus Q plan 3. Vägbeskrivning: www.lhs.se/organisation/kartor.html Anmäl dig senast den 22 oktober på e-post <anmalan-sth(a)isoc.se> eller använd anmälningsformuläret på www.isoc.se/ Smörgås och dryck serveras i anslutning till seminariet. Varmt välkomna! ISOC-SE ********************************************************* Björn Ohlsson, Medlemsansvarig Arb: 08 - 737 98 98 Bjorn.Ohlsson(a)isoc.se Mobil: 070 - 539 97 95 ISOC-SE Bost: 08 - 640 75 64 Box 7559 http://www.isoc.se/ 103 93 Stockholm

1 0

Mail flow overview by paf
by nisse＠lysator.liu.se 18 Oct '04

18 Oct '04

While searching for something completely different, I stumbled upon paf's presentation at the marid-bof in February (http://www.imc.org/ietf-mxcomp/Seoul/PatrikFaltstrom/marid-bof.pdf, link also added on our homepage). It contains both an clear list of mail flow cases (relaying, forwarding, etc), and observations like : I am of the view people attack the spam problem from the wrong angle : : Look for a solution : Fine-tune it : Look for a problem the solution solves Regards, /Niels

2 1

Yahoo domainkeys?
by nisse＠lysator.liu.se 18 Oct '04

18 Oct '04

This proposal seems related to our work: http://www.shaftek.org.nyud.net:8090/blog/archives/000148.html http://antispam.yahoo.com/domainkeys Summary, after a quick browsning of the draft: An MTA (usually a border MTA) signs all outgoing mail. The signed data includes the message body and selected headers. Signature is added as a message header. The receiver examines the signature-header, looks up the corresponding public key in DNS, and verifies the signature. The Sender: and From headers are also involved in the verification in some way, but I don't understand precisely how. Potential problems: * MTA have to generate signatures for all outgoing email. (But a mailing list can use the same signature for all copies; that's the traditional scaling advantage of public keys. list-bots usually insert a Sender:-header, right?) * They sign message contents, hence need canonicalization of headers and body. Not kosher from an SMTP-point of view. * I think they have the same problems as us with people using unrelated MTA:s for in- and outgoing email. * Potential patent sillyness, I haven't tried reading Yahoo's patent license carefully. Like spf, I don't think it's particularly useful in itself, but it may be another way to let mail from white listed domains bypass hashcash. Regards, /Niels Möller

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mta-hashcash