All, Maybe I am confused on how email works. Sending, A. I want to send a message. My MTA looks up the MX record of the receiving party and initiates a bind and a conversation on port 25 with the receiver's MTA. As part of that conversation headers are exchanged one of which is DKIM. I then pass the message itself. The receiving MTA gives me a gooday then trundles off to do the magic receiving stuff.
B. My MTA must relay to another MTA because I am on a DHCP based static IP I initiate the conversation above with my relayer who then repeats the process with the MTA on the other end of the MX record. If my agreement with my relaying MTA is to sign on my behalf I have a 3rd party signature. Plus perhaps my own. C. Using the B example above my relayer thinks he is talking to the MTA of the receiver because of the MX record but is really talking to a 3rd party front end who runs spam filters for the real users (MXLogic comes to mind) they say thank you very much and may well sign again for the MTA and MUA of the real recipient behind them. Now I haven't addressed lists yet. Am I missing any pieces? Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thomas Sent: Wednesday, August 02, 2006 10:35 PM To: John L Cc: DKIM List Subject: Re: [ietf-dkim] A more fundamental SSP axiom John L wrote: >> I think a more fundamental question is who the consumers of SSP >> information >> are. I think that everybody agrees that DKIM receivers are an important >> constituent, but are they the only ones? It doesn't seem very hard to >> envision other consumers. > > > Usage scenarios would be very helpful. As Dave noted, if people can > throw stuff into a protocol because it might be useful for something > nobody actually plans to do, you end up with terminal bloat. Please don't shoot the messanger: I'm just asking. It's a fairly common occurrance that a successful protocol will have many more uses/consumers than was originally envisioned. Especially in the case of spam, it's not very clear what the mutations will be so it's worth questioning, IMO. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
