I'm answering the easy parts now , hopefully getting back to the harder parts later. I'll be pretty busy with teaching and stuff the rest of the autumn.
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 22 Oct 2004 10:49:27 +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).
From what I've heard, many spammers send 10k messages or less from each single zombie machine nowadays to avoid that the operator notices what's happening.
And if that is beneficial for the spammer, the work could be divided between the zombies in such a way that all the 10k email transmitted by one zombie goes to a single or to a small number of MTA:s.
Generally, I would like to avoid tying keys to IP addresses, but it might be what's most effective after all.
One simple thing one could do is to associate the keys that are established by the big upfront payment mechanism with an IP address, without having such an association for keys in general. But I'm still sceptic to the usefulness if this mechanism. Are there any legitimate email use cases?
| > 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 user@example.com, and we have
example.com MX mail1.example.com # (precedence/priority doesn't matter) example.com MX mail2.example.com
mail1.example.com A 1.2.3.4 mail1.example.com A 1.2.3.5
mail2.example.com A 1.2.3.6 mail2.example.com A 1.2.3.7
Say that the client connects to 1.2.3.4, gets a challenge, disconnects, solves challenge, and then connects again. Do you want it to connect to
* 1.2.3.4 (i.e. same IP as last time)
* Either of 1.2.3.4 and 1.2.3.5 (i.e. any A record associated with mail1.example.com, which was the domain used for the A lookup last time)
* Any of 1.2.3.4-7 (i.e. any A record associated with any MX associated with example.com)
Regards, /Niels