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 PROTECTED]> [EMAIL PROTECTED]
3rd party expectation:
MAIL FROM:<[EMAIL PROTECTED]> [EMAIL PROTECTED]
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
