mta-hashcash

mta-hashcash@lists.lysator.liu.se

247 discussions

Need S0ftware?
by Bradley Simmons 27 Jun '07

27 Jun '07

OEM software means: no DVD/CD, no packing case, no booklets and no overhead cost! So OEM software is synonym for lowest price. Buy directly from the manufacturer, pay for software ONLY and save 75-90%! Check our discounts and special offers! Find software for home and office! Different platforms. World leading manufacturers. Instant download. ---- HOT ITEMS Windows XP Pro + SP2 $49 MS Office Enterprise 2OO7 $79 Adobe Acrobat 8 Pro $79 Microsoft Windows Vista Ult $79 Macromedia Studio 8 $99 Adobe Premiere 2.O $59 Corel Grafix Suite X3 $59 Adobe Illustrator CS2 $59 Macromedia Flash Prof 8 $49 Adobe Photoshop CS2 V9.0 $69 Macromedia Studio 8 $99 Autodesk Autocad 2007 $129 Adobe Creative Suite 2 $149 http://dst.nnoemf.com/?51946040A1C6EDC1795352E2AD3A532448932F01B0D4FFDD7540… ---- Top items for Mac: Adobe Acrobat Pro 7 $69 Adobe After Effects $49 Macromedia Flash Pro 8 $49 Adobe Creative Suite 2 Prem $149 Ableton Live 5.0.1 $49 Adobe Photoshop CS $49 http://dst.nnoemf.com/-software-for-mac-.php?51946040A1C6EDC1795352E2AD3A53… ---- Popular eBooks: Home Networking For Dummies 3rd Edition $10 Windows XP Gigabook For Dummies $10 Adobe CS2 All in One Desk Reference For Dummies $10 Adobe Photoshop CS2 Classroom in a Book(Adobe Press) $10 ---- Find more by these manufacturers: Microsoft...Mac...Adobe...Borland...Macromedia...IBM http://dst.nnoemf.com/?51946040A1C6EDC1795352E2AD3A532448932F01B0D4FFDD7540… ---- Mary let out a loud, inelegant Aye, they do, Jamie countered. You really think Ill believe a Its true, Mary, Beak admitted. Mary shook her head. I can tel

1 0

Beware of fake pills
by Damon Murphy 16 Jun '07

16 Jun '07

See attach. http://www.lawdbane.com/ ----- His expression had turned back How dare he? she demanded as s Her anger kept her from respon Geoffrey found her resistance

1 0

$B%b%K%?!<Jg=8!|(B$B=*; O!"%^%$%J%9$G=*$o$C$F$7$^$C$F$$$k(B$B5.J}$XO/Js!|(B
by life-line 04 Oct '06

04 Oct '06

★★★★★★★★★★ ★　ライフライン　★ ★★★★★★★★★★ http://life-line.mods.jp 　0120-456-516 モニターの事なら業界トップのライフライン！！完全無料！！緊急大募集！！ホール実践のモニターで高収入！ ■━━━━━モニターが必要とされる理由━━━━━━━■ 現在、パチンコ・パチスロ産業はどんどん膨れ上がっています。そんな業界の波に取り残されない為にホールやメーカーでは色々な営業戦略を立て集客争いを行っておりますが、なにより大切なのは実際にホールや新台などに人が集まっている事なのです。その集客率をアピールするのに一番適しているのがモニターなのです。それ故、今後のパチンコ・パチスロ業界の発展において効果的な宣伝手段としてモニターは必要不可欠な存在なのです。しかしモニターの数が不足しているのが現状です。そこで当社に打ち子募集の依頼が殺到するのです。今回、このような人材不足を解消すべく全国規模での募集に至りました。 ■━━━━━━━━━━━━━━━━━━━━━━━━■ ★システム★ １、固定保証給システム、安定した収支の為に固定給＋歩合制度です！２、軍資金提供システム、軍資金は当社で負担させて頂きます。３、直接サポートシステム、当社スタッフが立ち回り等、親身に指導致します！４、フリーシフトシステム、貴方のライフスケジュールにあったシフトでＯＫ！ ┏━…‥‥…━…‥‥…━┓ ┃　　 ★募集要項★ 　　┃ ┗━…‥‥…━…‥‥…━┛ 資格：18歳以上男女不問　　未経験者大歓迎年齢・経験は一切関係ありません！給与：固定給30万（最低保証額）＋歩合活動場所：全国各地のホール時間：完全自由制（10:00〜23:00　週1日〜ＯＫ！）日払い可能　※ご相談下さい！メールでのお申し込みは　　　お電話でのお申し込み ↓↓↓↓↓↓↓↓↓↓↓　　　 ↓↓↓↓↓↓↓↓↓↓ http://life-line.mods.jp　　　　　0120-456-516 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 会社概要会社名　　株式会社　ライフライン所在地　　東京都豊島区西池袋３−５６−１０　２F 設立　　１９９８年４月電話番号　０１２０−４５６−５１６資本金　　１０００万従業員数　　単体３６名／関連会社連結４２名（２００６年９月現在）事業案内アミューズメント事業による業務全般ならびにコンサルティング業務データ解析業務

1 0

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 09 Aug '05

09 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 22 Oct '04

22 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 22 Oct '04

22 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mta-hashcash