"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.
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.
I guess it would world like this:
C: EHLO mail.example.com
S: 250-host.com, welcome mail.example.com
S: 250-HEAD
S: 250-........
S: 250 HELP
The HEAD extension is exposed to the client.
C: MAIL FROM: <sender address>
S: 250 ok
Depending the sender domain, if the SPF2.0/PRA record is available, then
means the SENDER is SENDERID compliant - thus client software has been
changed. If this is the case, the HEAD command will be enforced. If no
SPF2.O/PRA record is found, then backward compatibility is in place.
C: RCPT TO: <local_address>
S: 250 ok
Assuming the sender address domain was SPF2.0/PRA ready, the HEAD command
will be enforced for the next command sequence in the state machine.
C: HEAD
S: 354 - proceed with header block
Date: ...
From: ....
.
At this point the server performs its magic with no payload problems.
Assuming all is ok, the client proceeds with the DATA command to remaining
2822 body block.
Again, this is something that requires change in clients. But we are
promoting SENDERID payload concepts which require change anyway, then do so
with some level of optimization to solve the senderid problem but also help
prepare SMTP for future header considerations as well.
I can envision ideas where ESMTP the HEAD block with no DATA text block can
be use to drive other automated process concepts.
The sky is the limit.
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com