nisse@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.
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote
| 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"?
No. Current spec:
MAIL FROM RCPT TO XHASHCASH-stuff DATA
An alternative organization is:
MAIL FROM XHASHCASH-stuff RCPT TO DATA
Then the reply code for the RCPT can contain the definitive answer as to message acceptance.
För hash-cash funkar det, men det blir kruxigt att göra MAC på header och body innan DATA, för autenticering.
Not necessarily.
The sender (SMTP client) knows all needed data. It passes the message and MAC to the receiver (SMTP) server. The receiver can defer actual checking of the MAC until after DATA. If any MAC turns out to be incorrect, delivery fails (totally, for all recipients), and the reply code from DATA will say so.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 04 Oct 2004 16:16:16 +0200:
| Then the reply code for the RCPT can contain the definitive answer as | to message acceptance.
I was erroneously thinking that the RCPT command contained hashcash payment. Confused. Sorry.
| The sender (SMTP client) knows all needed data. It passes the message | and MAC to the receiver (SMTP) server. The receiver can defer actual | checking of the MAC until after DATA. If any MAC turns out to be | incorrect, delivery fails (totally, for all recipients), and the reply | code from DATA will say so.
Yes, failing *all* delivery if hashcash payment or authentication fails for *any* recipient is a solution.
Linus Nordberg linus@nordberg.se writes:
| The sender (SMTP client) knows all needed data. It passes the message | and MAC to the receiver (SMTP) server. The receiver can defer actual | checking of the MAC until after DATA. If any MAC turns out to be | incorrect, delivery fails (totally, for all recipients), and the reply | code from DATA will say so.
Yes, failing *all* delivery if hashcash payment or authentication fails for *any* recipient is a solution.
There are two failure modes which we shouldn't mix up:
1. The server requires hashcash or authentication in order to deliver the message, but the client doesn't provide any.
2. The client claims that it provides valid hashcash/authentication, but when verified later (after DATA), the privided data turns out to be incorrect.
I think failures of type (1) may quite normal and common, and it must be reported per recipient. The failure indicates incompatible requirements or mis-configurations of involved MTA:s.
In contrast, failures of type (2) have to be rare, they indicate implementation errors or perhaps an active attack on the SMTP-connection. I don't think this needs need any per-recipient error reporting; aborting delivery for all recipients, and reporting that back to the client, seems like an appropriate thing to do.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 04 Oct 2004 17:21:00 +0200:
| > | The sender (SMTP client) knows all needed data. It passes the message | > | and MAC to the receiver (SMTP) server. The receiver can defer actual | > | checking of the MAC until after DATA. If any MAC turns out to be | > | incorrect, delivery fails (totally, for all recipients), and the reply | > | code from DATA will say so. | > | > Yes, failing *all* delivery if hashcash payment or authentication | > fails for *any* recipient is a solution. | | There are two failure modes which we shouldn't mix up: | | 1. The server requires hashcash or authentication in order to | deliver the message, but the client doesn't provide any. | | 2. The client claims that it provides valid hashcash/authentication, | but when verified later (after DATA), the privided data turns out | to be incorrect. | | I think failures of type (1) may quite normal and common, and it must | be reported per recipient. The failure indicates incompatible | requirements or mis-configurations of involved MTA:s.
Good point.
But we still have to abort the delivery for all the recipients since "The SMTP model does not allow for partial failures at this point [...]".
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote | There are two failure modes which we shouldn't mix up: | | 1. The server requires hashcash or authentication in order to | deliver the message, but the client doesn't provide any. | | I think failures of type (1) may quite normal and common, and it must | be reported per recipient. The failure indicates incompatible | requirements or mis-configurations of involved MTA:s.
Good point.
But we still have to abort the delivery for all the recipients since "The SMTP model does not allow for partial failures at this point [...]".
That sentence is from section "4.1.1.4 DATA (DATA)" in RFC 2821, right? That refers to errors reported to the DATA command, after the <CRLF>.<CRLF>. If we instead report the error before DATA, it should be possible to reject the message per recipient, as in the following example (with no hash-cash involved, for simplicity).
MAIL FROM: adam@foo.com 250 Ok RCPT TO: bertil@foo.com 250 Accepted for delivery RCPT TO: ceasar@foo.com 550 Refused for policy reasons DATA 354 Start mail input; end with <CRLF>.<CRLF> <message> . 250 Ok
As far as I understand, this means that the recievning MTA delivered the message to bertil@foo.com, but not to ceasar@foo.com.
To be able to do this, we must report the error before DATA. And I think it will be easier to get it to work with for old MTA:s if we do it in the response to RCPT.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 05 Oct 2004 09:51:01 +0200:
| > But we still have to abort the delivery for all the recipients since | > "The SMTP model does not allow for partial failures at this point [...]". | | That sentence is from section "4.1.1.4 DATA (DATA)" in RFC 2821, | right? That refers to errors reported to the DATA command, after the | <CRLF>.<CRLF>. If we instead report the error before DATA, it should | be possible to reject the message per recipient, as in the following | example (with no hash-cash involved, for simplicity). | | MAIL FROM: adam@foo.com | 250 Ok | RCPT TO: bertil@foo.com | 250 Accepted for delivery | RCPT TO: ceasar@foo.com | 550 Refused for policy reasons | DATA | 354 Start mail input; end with <CRLF>.<CRLF> | <message> | . | 250 Ok | | As far as I understand, this means that the recievning MTA delivered | the message to bertil@foo.com, but not to ceasar@foo.com. | | To be able to do this, we must report the error before DATA. And I | think it will be easier to get it to work with for old MTA:s if we do | it in the response to RCPT.
Assumption: - We move XHASHCASHCHALLENGE/RESPONSE and XHASHCASHAUTH to after MAIL FROM but before RCPT.
Will the following statements hold? - The receiving MTA will
- be able to report failure due to missing hash cash and authentication, in the response to RCPT.
- be able to report failure due to erroneous hash cash payments, in the response to RCPT.
- have to wait until the response to DATA (and the message, ended with <CRLF>.<CRLF>) to report failures due to erroneous authentication.
Linus Nordberg linus@nordberg.se writes:
Assumption:
- We move XHASHCASHCHALLENGE/RESPONSE and XHASHCASHAUTH to after MAIL FROM but before RCPT.
Will the following statements hold?
The receiving MTA will
- be able to report failure due to missing hash cash and authentication, in the response to RCPT.
Yes.
- be able to report failure due to erroneous hash cash payments, in the response to RCPT.
Probably. Unless we make the challenge salt depend on the message contents or something like that.
- have to wait until the response to DATA (and the message, ended with <CRLF>.<CRLF>) to report failures due to erroneous authentication.
Yes.
/Niels
nisse@lysator.liu.se (Niels Möller) wrote 04 Oct 2004 16:16:16 +0200:
| No. Current spec: | | MAIL FROM | RCPT TO | XHASHCASH-stuff | DATA | | An alternative organization is: | | MAIL FROM | XHASHCASH-stuff | RCPT TO | DATA | | Then the reply code for the RCPT can contain the definitive answer as | to message acceptance.
The XHASHCASHADVISE extension will then have to move to MAIL FROM. The MAIL FROM response is unable to suggest keys to use for authentication. The sending MTA will have to guess if a given key is valid or not, with the risk of being rejected as a spammer with fake auth.
Should we add anotother extension (XHASHCASHADVISEAUTH) to RCPT, with a response that can inform the sending MTA about valid keys for sender/recip pair?
Linus Nordberg linus@nordberg.se writes:
The XHASHCASHADVISE extension will then have to move to MAIL FROM.
Perhaps it is better to make it a command than a parameter?
Anyway, it has to include the intended recipient (a little redundant with RCPT) in order to let the server give useful advice.
What do you think about a RL (real-life) meeting soon? I think we have a bunch of issues to discuss, including
* protocol details
* forwarding
* if keys should be per user or per mta.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 06 Oct 2004 17:35:43 +0200:
| > The XHASHCASHADVISE extension will then have to move to MAIL FROM. | | Perhaps it is better to make it a command than a parameter? | | Anyway, it has to include the intended recipient (a little redundant | with RCPT) in order to let the server give useful advice.
C: MAIL FROM: alice@frotz.foo XHASHCASH-WANNA-PAY-FOR bob@bletch.bar S: 311-Expecting hash cash or authentication with key 311-<4711> 311 <1897> C: XHASHCASHCHALLENGE method-foo,method-bar S: 250 method-bar hashcash-challenge C: XHASHCASHRESPONSE method-bar hashcash-response S: 250 Ok C: RCPT TO: bob@bletch.bar S: 250 Ok
or, as a separate command
C: MAIL FROM: alice@frotz.foo S: 250 Ok C: XHASHCASH-HOW-MUCH-IS-A-STAMP-FOR bob@bletch.bar S: 311-Expecting hash cash or authentication with key 311-<4711> 311 <1897> C: XHASHCASHCHALLENGE method-foo,method-bar S: 250 method-bar hashcash-challenge C: XHASHCASHRESPONSE method-bar hashcash-response S: 250 Ok C: RCPT TO: bob@bletch.bar S: 250 Ok
| What do you think about a RL (real-life) meeting soon? I think we have
I think that would be good. Is Stockholm fine with you? I'm afraid it can't happen very soon, Stockholm or not.
Earliest opportunity for me would be daytime next wednesday (2004-10-13). Earliest non-daytime would be 18th, 19th or 20th of October. :(
| a bunch of issues to discuss, including | | * protocol details
Have you had any luck finding someone with a bit more knowledge about SMTP?
| * forwarding
I guess we'll have to include relaying here as well.
| * if keys should be per user or per mta.
What are the arguments against per user keys?
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 06 Oct 2004 17:35:43 +0200: | What do you think about a RL (real-life) meeting soon? I think we have
I think that would be good. Is Stockholm fine with you? I'm afraid it can't happen very soon, Stockholm or not.
Earliest opportunity for me would be daytime next wednesday (2004-10-13). Earliest non-daytime would be 18th, 19th or 20th of October. :(
2004-10-13 works fine for me, I'd suggest at 14:00. Location? We could meet at KTH, using my department's library or so. (I think our meeting place must have a working whiteboard or blackboard).
Have you had any luck finding someone with a bit more knowledge about SMTP?
Not really.
I guess we'll have to include relaying here as well.
Right, forwarding is a special case of relaying.
| * if keys should be per user or per mta.
What are the arguments against per user keys?
Per-user keys implies a much larger database. The keys aren't owned by the users anyway, and are of quite limited usefulness for user authentication. Some things, like the handling of mailing lists that use multiple addresses, are simplified when keys are assoicated with mta:s rather than with addresses. One may still associate some per-user information with the keys. I haven't made up my mind yet, but simplicity is important.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 07 Oct 2004 12:48:04 +0200:
| > Earliest opportunity for me would be daytime next wednesday | > (2004-10-13). Earliest non-daytime would be 18th, 19th or 20th of | > October. :( | | 2004-10-13 works fine for me, I'd suggest at 14:00. Location? We could
I will have to leave at approximately 16:30 unless I manage make some arrangements. Would 2.5 hours be enough, you think? Or is it possible to make it 12:00 or maybe 13:00?
Any more attendants?
| meet at KTH, using my department's library or so. (I think our meeting | place must have a working whiteboard or blackboard).
Internet access would be nice, but not necessary.
[Database discussion in separate thread.]
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 07 Oct 2004 12:48:04 +0200:
| 2004-10-13 works fine for me, I'd suggest at 14:00. Location? We could
I will have to leave at approximately 16:30 unless I manage make some arrangements. Would 2.5 hours be enough, you think? Or is it possible to make it 12:00 or maybe 13:00?
We can say 13:00. If 3.5 hours isn't enough, we're probably too tired for useful discussions anyway.
Any more attendants?
Not yet. Tege, can you come or are you tied up at work? I'll invite other people I've talked to, once we have decided time and place.
| meet at KTH, using my department's library or so. (I think our meeting | place must have a working whiteboard or blackboard).
Internet access would be nice, but not necessary.
There's wavelan access, but it requires a kth.se account (I haven't bothered to get one). Not sure about wired access, but if all else fails and we need to get some references, my office is some 10 meters away.
/Niels
Perhaps Swox offices would be better? There is a large table and a large (not very good) whiteboard there. And (believe it or not) Internet access there.
Whereever you decide, I would like to participate.
Torbjorn Granlund tg@swox.com writes:
Perhaps Swox offices would be better? There is a large table and a large (not very good) whiteboard there.
I remember that whiteboard as quite suckish. So I think I'll prefer our library. There's room for half a dozen people, a large whiteboard, and a good espresso machine nearby.
So, lets met at
Time: 2004-10-13, 13:00 Place: S3 departmental library, Osquldas väg 10, floor 6.
I have a short list of other people I'll invite. Cc: me if you invite more people.
You are interested in lunch somewhere before the meeting, that would be nice too.
Regards, /Niels
mta-hashcash@lists.lysator.liu.se
-
Linus Nordberg -
nisse＠lysator.liu.se -
Torbjorn Granlund