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@mipassoc.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