Hantering av felaktig hash

[Linus Nordberg]

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.