nisse@lysator.liu.se (Niels Möller) wrote 27 Oct 2004 21:35:42 +0200:
| > | Hmm. I think the reason we need an id for the sending MTA is as | > | follows: | > | | > | 1. Say a@a.com sends email to b@b.com for the first time. They | > | exchange a key k, and now a.com knows that this key is associated | > | with b.com, and it will try to use it next time it sends mail to | > | b.com. | > | | > | The problem is the reply; how can b.com know that it should use | > | this key for email to a.com? | > | > a.com will suggest the key k in its response to XHASHCASHADVISE, based | > on the domain part of the envelope sender? | | Makes some sense. I think the effect is about the same as to specify | that the "mta id" is the domain-part of the envelope address. But it | won't work if b.com is a relay (but I'm not sure that matters, perhaps | bidirectionality is broken anyway in that case).
The bidirectionality seems deemed when the sending and receiving MTA's for a domain are not sharing key and policy databases. I can't see how this can be fixed regardless of how the id for the sending MTA is constructed. The relationship between sending and receiving MTA's might perfectly well be nil.
| > | > When speaking of client coming back, we mustn't forget to demand that | > | > the client connects to the very same MTA the second time. | > | | > | What does "same" mean? Same A-record (IP address), or the same | > | MX-record? | > | > Same machine, | | "Same machine" is not an answer that makes sense to the client at the | other end of the network. Say the smtp client is sending mail to
I thought I was speaking to a human being. :-)
I mean the same machine, the very same host running a single instance of MTA software listening on port 25. But of course, we'll have to specify "same IP address" if we want the client to understand that and hope that people putting their MTA's behind load balancing equipment realise that SMTP has changed.