spf-discuss
[Top] [All Lists]

Re: Hotmail preparing to check SID with spf2.0/pra only?

2005-06-22 04:40:32

On Wed, 22 Jun 2005, Hector Santos wrote:

"Jeremy Harris" <jgh(_at_)wizmail(_dot_)org> wrote in message

You could (strictly, violating SMTP but hey...) determine the PRA
result after only the headers are transferred, and drop the TCP
connection at that point (and blacklist some combination of IP,
2821.Mail, 2821.Rcpt for the likely retry).

True, but as you say, it violates SMTP.  No fun there.  But yes, some tricks
can be done to drop and then catch repeats, etc based on failed SPF/PRA look
ups.

The proposal I made during MARID was to introduce a HEAD command that
separates the 2822 header block with the 2822 message payload.

There has been one or two drafts couple years back proposing that.

And proposal you'll see from me in about 2-4 months will be somewhat similar
although it goes a bit further then just separating header fields from body
and proposes to separate trace data out of header as well. But in the
way it works, its pretty much what you described it, i.e. new command
that allows to send parts of what we know consider email body separately.

This would not only cater to the SenderID higher bandwidth consideration
but also open the door for many other new 2822 analysis considerations,
including Yahoo's DomainKeys or Cisco's IIM.

It'll not do much for domainkeys because it needs entire email body to
to verify the signature. It could be of some use for IIM because than
you could verify signature publickey with fingerprint on remote server
before proceeding to data (but actual signature verification PKI
process would still need entire data).

But with META-Signatures this actually does work because signature is
based entirely of header fields data. So entire public key cryptography
could be done immediatly after receiving header data and what is left
after data is received is to just verify that digest hash of data is
correct (based hash data entered in Edigest header field).

Anyway, good point Jeremy.  In lieu of some new HEAD command, I can see
Senderid systems down the road having to do update their SMTP software to do what you say to catch the PRA payload abusers.

I believe PRA is quite wrong in that it creates this combined algorithm
and misses who the sender really is. It would have been much better if
PRA only focused on Sender header field and that is all.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net