ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

2011-05-10 01:17:06
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

<Prev in Thread] Current Thread [Next in Thread>