Alessandro Vesely wrote:
On 08/May/11 19:13, Dave CROCKER wrote:
In practical terms for the current world, what is the likelihood that
a signer has any information about the 'type' of an email address?
How can a signer possibly know that an addressee is a mailing list???
Currently, it has to query the /time-distributed database/ brought
about by the spotty subscription reminders that MLMs send on April
fools' day and similar occasions.
Seriously, since it is a civic and sometimes legal duty to confirm
subscriptions, one may wonder why that database is not maintained by
means of present-day technologies. Every MTA would then have a list
of mass mailers, cross-linked to its users, to be looked up when
whitelisting, signing, resolving complaints, and, occasionally,
attesting (un)subscriptions.
Forgive the OT.
Well, Dave's perspective is that of an independent (3rd party) free
wheeling signer. The issue at hand regarding the need to use the "l="
is that of an author domain signing his own mail and thus has already
selected a s= value to use, its own or a provisioned independent
signer domain. But it the author domain doing all the picking, setup
and signing - not the signer domain. Even if its the 3rd party, the
author domain can still dictate what it wants (see the ending comment).
In our current rev1 DKIM implementation, the outbound edge MTA does
the signing and it reads a setup file keyed on the From.domain or
List-ID.domain.
That is how it knows what to sign and with what options per domain
stream and this was the quickest and no MLM software change. It was
to handle the MLM list setups on our system or a customer system with
the same software to handle its mailing list.
In Rev2 it will updated to handle external mailing list (inbound)
using a "Mail Conference Type" factor and this is where the "l="
option MAY APPLY.
For example, for our API, the conference types are:
enum {
mtNormalPublicPrivate,
mtNormalPublic,
mtNormalPrivate,
mtFidoNetmail,
mtEmailOnly,
mtUsenetNewsgroup,
mtUsenetNewsgroupModerated,
mtInternetMailingList,
mtFidoEcho,
mtListServeForum,
mtUserEmail,
mtEND = 256
};
The operator can prepare "Internet Mailing List" conference where list
traffic can be stored. For this conference type, it also enabled a
Reply Network Address. For example:
Name : IETF-DKIM
Type : Internet Mailing List
Network Address: ietf-dkim(_at_)mipassoc(_dot_)org
This conference can be accessible by online users, including by News
Readers MUAs if the conference option is checked:
[X] Publish as a Local Newsgroup
Any (access allowed) user reading the conference can create or reply
and the mail is exported with a forced direction to the network address.
Now when we add DKIM, new options could be for a "internet mailing
list" conference type:
[X] Sign Mail
[X] Use Body Length tag
With this option enabled, our edge MTA will now have the "setup" info
to use the L= tag when signing it only for this specific network address.
Finally, it is not unheard off in the "outsource" or ISP/ESP/Anti-Spam
mail service business to provide a list of user addresses for your
system. In fact, before we added better anti-spam stuff, we offered
an utility to specifically export a complete or DIFF file of
"acceptable users" for the hosting service to accept, do whatever to
the mail if anything, and forward to mail to their smart host/MDA
system. This is how many early operators began to add Anti-Spam
protection to their mail.
So for DKIM, a domain that wishes to outsource the signing operation
to a 3rd party, can easily possibly to start using a similar manual or
email automated method to send a full/change list of domains and
addresses it wishes to be sign under specific options like a "l=". In
fact, the # of domains/addresses may even be part of the fee schedule
for the service. This will cater to domains with an fast DKIM entry
point who do not wish the deal with the internal overhead and cost to
setup/maintenance DKIM.
--
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