[imp] Various meaningful IMP default settings

[Michael M Slusarz]

Quoting Daniel Vollbrecht <d.vollbrecht at scram.de>:

> Am 16.12.14 um 15:44 schrieb Michael M Slusarz:
>> I fail to see the advantage of displaying e-mail addresses, especially
>> when half the messages in my mailbox would show things like "Foo
>> <do_not_reply-MD5hash at externalemailcontentprovider.server14.westcoast.meaninglessdomainname.com>".
>
> You don't have to activate it, if there was an option. I would be  
> happy to have it configurable. My main intention was to discuss  
> meaningful default settings, but in this case, I just would like to  
> propose the introduction of a setting for it. Can be deactived by  
> default of course.

I've written about this before, but this is a good time to revisit the  
point since it comes up often when discussing feature requests.

In short, adding a configuration option for a feature is most often  
NOT a viable/useful option.  Because configuration options are  
*expensive*.  They are expensive since someone has to write the  
initial code.  Then, as developers, we have to maintain this option.   
And for many of these options, it is likely that no devs use all the  
options so there is a code coverage issue.  Then, admins have that  
much more documentation that they have to read in a configuration  
file, which just adds to the confusion factor.

Horde has been accused in the past of being too "difficult" to  
install.  I don't believe that to really be the case - you can setup a  
default installation without too much effort - but because we are so  
configurable and handle so many different types of backend components,  
it can appear to be that way to someone who has never dealt with Horde  
before because our configuration files are so detailed and dense.

So configuration options only make sense when the optional behavior is  
either something a lot of people may use or it is debatable about what  
the proper default should be.  Neither of those are the case here.

I find this request no different than asking a phone to always show  
the phone number when someone calls, rather than a caller ID.  Nobody  
I know has memorized phone numbers, even of their most common contacts.

>>> https://en.wikipedia.org/wiki/Social_engineering_(security)
>>
>> So when I send you a mail message with a spoofed From e-mail address
>> from outside your domain, how is this any different?
>
> It is very likely that such a message gets processed accordingly  
> (rejected or filtered out as spam). You would have to choose a from  
> address with a domain which doesn't have SPF and then most likely  
> the missing good reputation would be critical for our spamfilter.
>
> I don't think hiding the from address helps at all. The unaware  
> users don't care and the skilled tend to be able to at least be able  
> to activate it.

Here's the problem with this argument from a UI perspective: an  
unaware user MUST care about the e-mail address, because it is taking  
up room on the screen.  This is just complicating the display.  This  
is not example of something you can bury in a submenu, where advanced  
features can live and not effect what a "normal" user views.

>> If you feel strongly about this, this is easily added locally by adding
>> the additional information to your local source.  But none of these
>> arguments even approaach a level where making this configurable makes
>> sense.
>
> What exactly do you mean with local source? Patching my local horde  
> source scripts myself to implement the desired functionality?

Yes.  You can insert the email address into the From data that is  
shown on the templates.

>>> [3. Mail view]
>>>> Hmm, the MAILER-DAEMON messages (bounces) actually has the empty sender
>>>> address in most cases, so not sure what you like to verify in this case.
>>>
>>> No, mailer daemons only have an empty envelope address. The From:
>>> address is 'Mail Delivery System <MAILER-DAEMON at host.domain>' and I
>>> only see just 'Mail Delivery System' all the time.
>>
>> Not seeing your point(?)
>
> You justified that bounces have an empty sender address (<>), but  
> I'm talking about the From: address as IMP doesn't show me the  
> sender address anyway. And as explained the From: address consists of
>
> Mail Delivery System <MAILER-DAEMON at host.domain>

The From address *might* contain this for a DSN.  But there is  
absolutely no requirement/standard.

What happens when this DSN originates from a SMTP server two hops down  
the transit path?

> which indeed lets me distinguish from which of my hosts the  
> notification is originating. - At least if I could see the full  
> From: including 'MAILER-DAEMON at host.domain' and not just the useless  
> information 'Mail Delivery System'.

I don't buy this argument.  You are essentially asking to determine  
the content of the DSN from envelope information only.  That's not how  
the mailbox list is designed to operate.

>> If you are asking to see e-mail addresses in the from address because it
>> provides information on the tiny subset of bounced/failure messages,
>> that is way too specialized a use case to be useful overall (especially
>> since 99% of users don't care about these messages anyway).
>
> This is just *one* example. I also get other mail, e.g. Icinga  
> monitoring mails etc. for which my argumentation applies as well.
>
> I'm not requesting magic, it's just a feature that almost any mail  
> client has as option which can be enabled in the settings, whether  
> it is enabled on default or not doesn't matter.
>
>> It's quite a bit of extra work, and influences things like escaping.
>> Which means it is something that requires maintenance.  I'm just not
>
> I don't see the problem about escaping here. If I click on 'Michael  
> M Slusarz' on your mail, the sender view expands and shows 'Michael  
> M Slusarz <slusarz at horde.org>'. Why is there no escaping issue then?  
> I just would like to have an option that I don't have to click  
> anymore to see it right away.

Those are escaped differently.  One is stored in an HTML attribute and  
one is inserted as HTML text.  Two completely different escaping  
schemes.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]