Brad Knowles explained:
Indeed. We need to be careful about the SMTP Response Codes that we
issue on a hashcash-enabled MTA.
problem. You are looking at the hashcash model in a classic but fundamentally
flawed way. I have a very different insight which camram takes heavy advantage
of. This insight is that e-mail really consists of two protocols, the transport
layer (SMTP) and the content interpretation layer (headers and body). By
recognizing that you only need to change the interpretation layer to include
stamps or certificates or whatever, the problem is simplified.
camram puts all of its efforts into the interpretation where because that's
where you need to make the decisions about spam. Now you may want to have some
additional authentication features at SMTP layer but that is completely
independent and orthogonal to what camram does.
camram implements electronic stamps. Stamps go on the envelope and are
associated with the message independent of how you get it there.
although I have discovered that server side filtering and stamp generation
really needs to know who is okay and who is not for sending messages. It's
probably going to require either multiple interfaces (for enterprise) or
SMTPAUTH for the general ISP case.
That sounds like an interesting first-pass, yes. Of course, this
would have to be integrated into the default version of SpamAssassin
that everyone installs (and other filtering agents), in order for
something like this to be of value. Otherwise, you're calculating this
stuff and stamping your messages with it for nothing.
well, that's is what will be happening with camram 0.2. All messages classified
as "yellow" (neither spam nor ham) will be triggering postage due notices. So
with no stamps, it's what you describe.
there is a problem with setting up a response only environment and that is
determining when to start generating stamps. If we implement automatic postage
due response handling in the very beginning, then once you hit the 10 percent
threshold for postage due notices vs. outbound mail, then it might be possible
to do that. It would also have the advantage of giving folks chance to
establish a white list and minimize stamp generation from the get go.
anyway, this is definitely getting into the implementation realm and I encourage
you to sign up for the camram mailing list (it's low-volume, believe me) and
start making this shared vision real.
---eric
PS, I've been living with stamp generation for the past four months on a Pentium
II/333 in foreground mode and it doesn't suck too bad although it would be
better in the background. Check the headers.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg