Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen <abraham@dina.kvl.dk>]

prj@po.cwru.edu (Paul Jarc) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>> E.g. have a single parameter 
>> 
>>             mail-address
>> 
>> which states the main mail address associated with the folder,
> 
> Can we make it a vector?  Some lists have widely-used aliases in
> addition to the primary address; all of these should be used for MFT.
> For mail-types that apply to "a" and "f", we'd just use the first
> entry.
> 
> If it is a vector, then we might let it be a list of address-type
> pairs, but I'm not sure that would be useful.

I'd prefer using a list over a vector, and it should be named
mail-addresses then.

Other than that, I think it would be a good idea.  Some people have
multiple mail addresses, this would be a natural place to list them.

>>             mail-type
>>                 Unknown (default)
>>                 Personal        use m-a for "a", don't set 
>>                 Open List       use m-a for "a", set MFC
>>                 Closed List     use m-a for "a" and "f", set MFC
>> 
>> which state what type of folder it is.
> 
> What would Unknown mean?  I.e., how would code react to it?  I think
> it might be better to have no Unknown value and make, say, Open List
> the default; I imagine that'd be the most common case.  Either that,
> or ignore mail-address(es?) when mail-type is not set.  (Since these
> are new parameters, we won't be affecting any existing configurations
> with the choice of default.)

I did imagine "a" would be ignored for unknown types, but I have no
strong opinion what the default should be.  If "Open List" is most
common, then that should probably be the choice.

>> The "to-list" and "to-address" parameters should then be recognized
>> for backward compatibility,
> 
> Does this mean the MFT code should do anything with them, or only the
> code that already uses them?

If the default mail-type is open/closed list it would be more safe to
ignore them.  Otherwise, use them if it is not to much trouble to
implement.