[imp] Various meaningful IMP default settings

[Simon B]

On 22 Dec 2014 19:10, "Michael M Slusarz" <slusarz at horde.org> wrote:
>
> 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.

I agree with everything you said.

Except that my phone shows the name and phone number.  And I wouldn't want
a phone that only displayed numbers.  Nor would I tolerate one that only
showed the name..

Simon

>
>>>> 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]
>
> --
> imp mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org