Yes, is this true.
In this case, the Source (Your bank) is the originator and that is all
you need to worry about as to *whom* is the mail server (bank) and who
is the mail receiver (you).
But in the general sense, an "ISP" who is also "ESP" these days, so he
can offer:
- SMTP routing services (for downlink host, business accounts)
- POP3 pickup service (for user accounts)
- WEB Mail Server (for user accounts)
The ISP/ESP can do the DKIM/SSP for the user accounts, and it MAY do the
same for the hosting accounts. But also offer a passthru service for the
hosting accounts, with the idea the hosting accounts will do the final
DKIM/SSP processing.
So you need to look at the DKIM/SSP service features that an SMTP vendor
may offer in her product for ISP/ESP to use these to offer/sell these
services or a typical host will use.
--
HLS
Wietse Venema wrote:
Hector Santos:
[ Charset ISO-8859-1 unsupported, converting... ]
Wietse Venema wrote:
Perhaps an analogy from a different but familiar world will help.
Consider DKIM or SSP as broadcast radio transmissions (or TV if
you must). The point is that it is a UNIDIRECTIONAL thing. The
sender doesn't know if anyone is receiving the signal, and they
certainly can't force anyone to listen (or watch their TV program).
Likewise, the sender of DKIM-enabled email doesn't know if the
receiver implements DKIM or SSP, and they certainly can't force
them to implement unenforceable statements that say "deny".
DKIM and SSP have no more "enforcement" power than broadcast radio.
You don't know who "receives" the signal and you certainy can't
force them to do anything with it.
With the DKIM and SSP broadcast model, you can define the format
of the signal and its meaning. That's all. If you want to control
the receiver and "deny" mail, then you need a fundamentally different
model.
Yes Wietse.
Thank you for highlighting the simple broadcaster/receiver model. It was
very appropiate.
By the way, I neglected to clarify my remark about fundamentally
different model, so I will take the opportunity to correct that.
Current email is primarily push technology. The problem therefore
is authenticating the pusher.
A fundamentally different model would be pull-based. For example,
to receive mail from my bank, I would pull it from their website.
I wouldn't have to worry if the mail is spoofed (it came from the
bank's website, I have their DNS name and SSL cert), and the bank
could easily claim that all other mail in their name is a forgery.
Note that pull-based email technology is immune to the problems of
forwarding, mailing list munging and third-party signatures.
One implementation is for the bank to send a tiny email message
with just a token, plus a plain old URL for legacy mail clients.
As in early MIME days, legacy clients show ugly stuff to the user.
Smart MTAs (or MUAs) would handle the download step transparently.
There's nothing revolutionary in this. It's just basic application
of a different email distribution model. In fact, that model can
be built on top of the existing one.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html