mta-hashcash

mta-hashcash@lists.lysator.liu.se

244 discussions

Updated draft. MTA identification?
by nisse＠lysator.liu.se 15 Oct '04

15 Oct '04

I've updated the draft now (see http://www.lysator.liu.se/~nisse/misc/draft-nisse-hash-cash.txt), trying to address the issues raised by Simon and during the meeting. It now uses per-MTA keys. Then an important question is how an MTA is identified. Ideally, all border-MTA-s belogning to the same administrative domain should have the same identity (except perhaps secondaries). It's not clear if a mail server that accepts mail for multiple domains should have a single id, or one id per domain. I tried to write this down in section 4. Do we need new terminology for the things we identify? It's slightly confusing to say "MTA" when we are talking about not a single mail server, but a fuzzy group of them? Other notable changes: Authentication means signing a challenge string, of the same form as the hash cash challenges. Hash cash challenges now use hmac-sha1, with the string to be search for in the key argument, in order to make the construction somewhat more cryptographically sound. Most of the text on name-key semantics is deleted. /Niels

1 0

Filtering headers draft
by Linus Nordberg 14 Oct '04

14 Oct '04

Here's the draft I mentioned yesterday: http://millenix.zemos.net/asrg-filtering/draft-irtf-asrg-filtering-header.h…

1 0

Issues identified during todays meeting
by nisse＠lysator.liu.se 13 Oct '04

13 Oct '04

For the record, I'll list the most important issues identified during today's meeting. 1. It's undesirable that the MAC is computed over the message body. One possible alternative is to compute the MAC over a string constructed from envelope sender + receiver + salt, where the salt is chosen randomly by the receiving MTA. This is analogous to the things that go into a hash cash challenge string. 2. Asymmetric transport, where an email and a reply are relayed through different administrative domains. Example: Home user with a vanity domain and email address user(a)vanity.org. There's an MTA for vanity.org than handles incoming mail, but all outgoing mail is relayed by an ISP MTA acting as a relay, e.g. mail.telia.com, totally unrelated to vanity.org. If this user subscribes to a mailinglist, the mecahnism for automatic key setup will fail. 3. Communication between MTA and MUA. Current plan is that the MTA inserts a header analogous to the Received:-header, saying which authentication have been used. The MTA should also have a control-address, which users and MUA:s can use for configuring the MTA. These control messages need some kind of authentication. 4. The hash cash protocol probably needs a way that lets a client MTA disconnect, solves the challenge off-line, and reconnect and provide the answer later. Perhaps we can use confirmation emails, analogous to those used by mailing list software. In general, it's preferable that the MUA and MTA communicate by email, rather than by SMTP or by some other protocol directly on top of TCP. Regards, /Niels

1 0

Re: Hantering av felaktig hash
by Linus Nordberg 08 Oct '04

08 Oct '04

nisse(a)lysator.liu.se (Niels Möller) wrote 04 Oct 2004 15:17:12 +0200: | > | Sen finns det ju ett till felfall, som vi behöver lösa: Om servern | > | verkligen kräver autenticering eller hash-cash för en mottagare, och | > | klienten inte tillhanda håller något sånt. Hur förklarar man för | > | klienten att den här mottagaren tänker jag inte leverera till? | > | > Just. Hur pekar man ut en falerande av flera mottagare så sent i | > proceduren? Risken finns att SMTP förutsätter att man vet det redan | > när man besvarar RCPT. Kanske tolkas svaret på DATA som ett svar för | > hela transaktionen? | | Jag tror man definitivt *vill* ge felkoden före DATA. Om det krävs för | att kunna ge rätt felkoder, så får vi nog organisera om protokollet | och göra hash-cash-grejerna före RCPT. Före RCPT? Jag hänger inte med. Menar du "före DATA"? För hash-cash funkar det, men det blir kruxigt att göra MAC på header och body innan DATA, för autenticering. | Det är inte bra att generera studsar för saker som troligen är spam. Sant. Relevant avsnitt i RFC 2821, ang. DATA: The SMTP model does not allow for partial failures at this point: either the message is accepted by the server for delivery and a positive response is returned or it is not accepted and a failure reply is returned. In sending a positive completion reply to the end of data indication, the receiver takes full responsibility for the message (see section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in section 4.4. | > Man bör också tänka på att snabba sig på med svar på <CRLF>.<CRLF> för | > att undvika duplicerade meddelanden (RFC 1047). | | Ganska gammalt dokument, status UNKNOWN. Hur relevant är det? Att man | inte ska vänta flera minuter innen man svarar är ju rimligt, men vi | borde väl inte införa några längre fördröjningar där? Vi ska bara | beräkna en MAC på brevet, och huvuddelen av jobbet kan vi i princip | göra medan vi tar emot det (lite beroende på hur kommunikationen | mellan smtp-servern och local-delivery-program ser ut). Men jag tycker | inte det känns som att det borde vara ett stort problem, min laptop | kan processar drygt 60 MB/s med sha1. Du har rätt. | > Förresten, har du funderat på om det finns några problem med bcc? | | bcc tror jag är lugnt, men jag har inte tänkt så noga på det. | Forwarding är lurigare. Har jag redan skrivit om det här? Annars tar | jag och skriver om det på mailinglistan istället. Du har inte pratat om forwarding ännu.

3 15

Forwarding, and per-user keys
by nisse＠lysator.liu.se 08 Oct '04

08 Oct '04

How does forwarding fork, and why is it a problem? Assume that mail for fred(a)f.com forwards mail (via a .forward or aliases file) to ron(a)r.com, and stay stan(a)s.com sends an email to fred. There will be two smtp transactions. The first between the s.com and f.com MTA's, which will use MAIL FROM <stan(a)s.com> RCPT TO <fred(a)f.com> The next is between the MTA's for f.com and r.com, which will use MAIL FROM <stan(a)s.com> RCPT TO <fred(a)f.com> The problem here is that the f.com MTA sends mail on behalf of a user that "really" belongs to a different MTA, for s.com. So this is just a special case of relaying. So which keys should be involved? The first transaction involves a key for <s.com, f.com>, no problem there. The second transaction, between f.com and r.com, must use a key shared by those two mail servers (since the key for <s.com, r.com> is not known to f.com). So we use a key that has no obvious relation whatsoever with the address given in MAIL FROM. And we must make this case work. We also need to make more general relaying work. Consider the organization "Telia home users" which have a border MTA telia.com or some such, handling all out-going email. The users have arbitrary from addresses, unrelated to telia.com, which acts as a relay or "smarthost". The natural conclusion is that we must drop the notion that the keys can be used to authenticate the from address. A key can only be used to authenticate the MTA which owns it. And following this way of thinking, we have no use for per-user keys. (End-to-end per-user authentication is still a nice thing to do, but it can't work out-of-the-box with forwarding. When setting up a forward, the user must transfer his or her keys from the old place to the new place. Fortunately, that's not the MTA's problem). And one more forwarding comment: It would make sense to have an SMTP reply code that means "temporary redirect", 451 address forwarded to <some(a)where.else> and make it the clients responsibility to contact the right MTA server. This is analogous to 251 and 551, which are rarely used, and to HTTP redirects, which are used quite a lot. This could be done independently from our hash cash work, but I don't think it is worth the effort, since (i) it helps forwarding, but it can't replace general relaying, (ii) nobody uses 251 and 551 anyway, why would they use 451?, and (iii) it's probably too common with forwards that go to internal addresses and mail servers that aren't reachable from the Internet Regards, /Niels

2 2

Which recipient are we authenticating for?
by Linus Nordberg 07 Oct '04

07 Oct '04

We need a way to express which sender/recipient pair a given XHASHCASHAUTH is authenticating, in the case of multiple RCPT TO. The verifying server could calculate MAC for all recipients and try to match each an every one but that feels a bit annoying.

2 1

#mta-hashcash @ freenode
by Linus Nordberg 06 Oct '04

06 Oct '04

Are any of you into this IRC thing? We could meet at #mta-hashcash @freenode.net. I'm quite fond of that kind of communication.

2 2

Authentication header format
by Linus Nordberg 06 Oct '04

06 Oct '04

Draft, section 5 suggests that a header is added to messages that are successfully authenticated. o Add a header field, recording the result. If no MAC is provided, or the MAC is invalid, the server may require a hash cash transaction, and it should delete any possibly faked header in the incoming mail, that says the MAC was valid. Any ideas on what the header should look like?

2 1

[Niels Möller] Re: Auth efter challenge?
by Linus Nordberg 06 Oct '04

06 Oct '04

For the record. In swedish, unfortunately.

1 0

Typo in draft?
by Linus Nordberg 06 Oct '04

06 Oct '04

Index: draft-nisse-hash-cash.xml =================================================================== RCS file: /cvsroot/mta-hashcash/mta-hashcash/doc/draft-nisse-hash-cash.xml,v retrieving revision 1.1 diff -c -p -c -p -r1.1 draft-nisse-hash-cash.xml *** draft-nisse-hash-cash.xml 29 Sep 2004 19:10:16 -0000 1.1 --- draft-nisse-hash-cash.xml 6 Oct 2004 13:22:34 -0000 *************** *** 217,223 **** <figure> <preamble>Syntax:</preamble> <artwork> ! challenge = "XHASHCASHRESPONSE" SP method SP text CRLF </artwork> <postamble>The method must match the given challenge, and the text depends on the method. --- 217,223 ---- <figure> <preamble>Syntax:</preamble> <artwork> ! response = "XHASHCASHRESPONSE" SP method SP text CRLF </artwork> <postamble>The method must match the given challenge, and the text depends on the method.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mta-hashcash