Quoting Daniel Vollbrecht <d.vollbre...@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-md5h...@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@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@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@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 <slus...@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 [slus...@horde.org]
--
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: imp-unsubscr...@lists.horde.org
