ietf-dkim
[Top] [All Lists]

[ietf-dkim] Using SUBMITTER (RFC 4405) as a SSP discovery

2008-01-24 08:25:08
BTW,

We also have the SUBMITTER protocol which is an 2821 technology
designed to optimized the 2822 SenderID protocol.

     http://www.rfc-editor.org/rfc/rfc4405.txt

For the past year or so, we supported SUBMITTER in our Wildcat! SMTP
products for SPF/SID purposes.

Off hand, without further review, it appears SUBMITTER can also
be used to optimized SSP at the 2821 level.

Example usage for SSP/SenderID augmented systems:

1st party expectation:

  MAIL FROM:<jqp(_at_)example(_dot_)com> SUBMITTER=jqp(_at_)example(_dot_)com

3rd party expectation:

  MAIL FROM:<service(_at_)service(_dot_)com> 
SUBMITTER=jqp(_at_)example(_dot_)com

The SUBMITTER is suppose to the PRA "From: " domain, Frank can tell us
more here.


--
Sincerely,

Hector Santos, CTO
http://www.santronics.com


Hector wrote:

Michael Thomas Responded:

Maybe. But maybe not. With SPF you had the lure of doing all of
your work at the 2821 layer. That is, reject things before you've
read the message. With SSP you have to read the message so you
might as well run SSP and the rest of your filtering and just
incorporate SSP as *one* datapoint of potentially many to
determine the delivery disposition. This seems a lot more
sensible and prudent to me as you're not elevating SSP to Silver
Bullet status which is always suspect.

Side point: SENDERID is a 2822 based version of SPF.

Ideally, you want SPF to remain at 2821 to avoid the potential
Bounce Attack problems. If you collect the DATA and perform a
consolidated filtering before responding to the DATA command,
then there a risk of a high payload DoS attack.  So you want as
much filtering as possible at 2821 before reading the payload.

But sure, SSP is a 2822 technology as well as SENDERID, so these
would need to be performed once the payload is obtained, if it
gets to that state.
 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>