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

From: [email-masked]
Date: Thu, 24 Jan 2008 10:20:57 -0500

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:<[email-masked]> SUBMITTER=[email-masked]

3rd party expectation:

  MAIL FROM:<[email-masked]> SUBMITTER=[email-masked]

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 16:51:24 +0100

> Frank can tell us more here.

LOL, and tempt the coauthor of 4405, 4871, 5068, SSP, etc.
(including a book on my shelf) to ask me what I'm smoking ?

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jan 2008 12:24:36 -0500

> (including a book on my shelf) to ask me what I'm smoking ?

Well, I don't know what you are smoking, but do you think SUBMITTER can 
help here?

-- 
Sincerely

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 18:49:01 +0100

> Well, I don't know what you are smoking, but do you think
> SUBMITTER can help here?

I have a THING with any EEE "embrace, extend, and extinguish"
strategy as attempted in RFC 4406 3.4, fortunately a miserable
failure.  An attempted unfriendly takeover of 4405 SUBMITTER,
clearly designed for PRA, wouldn't be better.  

If you only want a *similar* concept (mutatis mutandis) it is
a technical question.  It might be hard to get the significant
deployment of an AUTHORS (if that's the name) SMTP extension
making it worthwhile.  But I can't judge this, I can't guess,
you don't need me to toss a coin.  Ask Eric, and tell us what
your SUBMITTER experiences with Wildcat! are. 

 Frank