On the IMAP issue, there is a file IMAPServer.C in
programs/dtmail/libDtMail/Common that seems to be handling the
interaction with an IMAP server v2bis or v4. But this is only for an
unencrypted connection.
My ISP for instance are using IMAP over SSL so dtmail cannot be used to
access their server.
However, it is possible to use fetchmail with the following .fetchmailrc
####
set postmaster "login"
set bouncemail
set no spambounce
set softbounce
set properties ""
set daemon 20
poll imap.myisp.net with proto IMAP
user 'firstname.lastname' there with password 'l33thax0r'
sslproto ssl3 sslcertck is 'login' here keep mda "/usr/sbin/sendmail
-i -f %F -- %T"
####
replacing login, l33hax0r firstname.lastname myisp.net with correct
values to get email delivered
in a local mailbox. The program getmail could also be used for that.
Since there is an option in dtmail
for using a custom delivery program it seems a possible workaround. I
have tested this approach on
Slackware 14.2 32bit, with sendmail running in the background. I am not
so sure it would work on the more 'modern' linuxes such as Ubuntu where
dtmail does not start for lack of a /var/spool/mail/$LOGNAME file and
sendmail is not used.
On the HTML handling side, there is a XmHTML library
https://sourceforge.net/projects/xmhtml/
that renders HTML 3.2 and supports Xft and UTF-8. So it might be
possible to use it for rendering some HTML
in dtmail. But the real issue may be that HTML email is not sent as
text/html attachments but directly as message body (at least Android
phones seem to be doing this) and that modern email clients have some
subroutines to detect whether the body is HTML or plain text.
On the positive side, UTF-8 accents are already handled correctly by
the current dtmail.
On the issue of retiring dtmail, it seems reasonable to simply not build
it by default but leave the option in configure to build it. One would
just need to explain how to configure the desktop so that clicking on
the mail icon of the front panel would bring thunderbird (or a dtterm -e
elm in HP VUE style).
Le 17/01/2020 à 11:50, Matthew R. Trower a écrit :
2. HTML handling - yeah, you could tackle this incrementally. That's
probably how I'd want to approach it.
1. IMAP - it's interesting to hear reports of IMAP success. I
remember reading that it was supposed to be there, and even seeing
some support in the codebase, now that I think about it. I thought,
anyway; it was years ago. But, I was never able to get it working. I
don't think it was a TLS issue (I think the configuration fields were
nowhere to be found?). When I was using it, it was directly with
filesystem mailboxes. I'll have to have another look at it, and ask
back if I can't figure it out.
-mrt
*From:* j...@n8fq.org
*Sent:* January 16, 2020 11:36 PM
*To:* cdesktopenv-devel@lists.sourceforge.net
*Subject:* Re: [cdesktopenv-devel] CDE 2.3.2 has been released
dtmail does indeed support IMAP, and I've had it running with my home
dovecot server without issue. It's certainly a primitive MUA but I
don't really understand the sheer level of *hate* I keep seeing for it.
Seems like getting it up to a fundamentally "usable" level would only
take two things:
1. SSL/TLS support
probably the hardest part, but doesn't OpenSSL do most of the work?
2. HTML handling
first step could be as simple as stripping out the tags with a
regexp leaving plain text, kinda like what Sylpheed does
maybe try handling <b> and <i> after that?
perhaps job out HTML display to an external viewer? I think it
already supports opening messages in a text editor...
-Jill
On 1/16/20 10:06 PM, Jon Trulson wrote:
On 1/16/20 7:24 PM, Matthew R. Trower wrote:
DtAppBuilder is a bit weird, and not my niche to comment on. As for
DtMail...
If it had IMAP support I'd be using it today. It's actually always
irked me that I can't. It has some rough edges, but those can also
be smoothed. It doesn't do HTML mail, but not everyone even wants
HTML mail.
I haven't looked into it in a serious capacity, but I can't imagine
IMAP support is some monstrous thing. I'd wanted to get to this at
some point (honestly the top thing I actually *want* to work on in
CDE, as opposed to necessary maintenance work.)
I did it once for a customer using the alpine IMAP toolkit some years
ago. It was not trivial, but not really rocket science either. From
what I understand, TLS is what's really missing in dtmail... I don't
remember, but I thought dtmail did already support IMAP. Just
unsecure/no encryption. Oh, and HTML rendering, and....
DtMail may not be serving much purpose at the moment, but I don't
see a viable replacement for it, either - not something with the
history, not something built for motif, not something that runs
comfortably on the same baseline of hardware that the rest of CDE does.
How about thunderbird? That's what I am using right now... Pisses
me off from time to time, but it works.
Though to be honest, I no longer even use CDE as my DT of choice.
I'm firmly in the KDE camp and have been for the last 10 years.
I've been wondering why I waste my spare time continuing to maintain
CDE. Perhaps it's time for someone who actually uses it day to day
to take over in a primary role. I'm about done to be honest.
There's so much more stuff out there that I'm interested in, and more
willing to spend precious spare time on. Any takers?
I ask - is this application actively hindering development? I'm
sure it has the same kind of code problems that the rest of CDE has,
but are we, say, constantly fixing problems with it to keep the
build going? Does it have problems that are leaking out into the
rest of CDE?
-mrt
From my perspective, the fact it is unusable and no one is fixing it
is good enough for me to remove it. I don't care about 'actively
hindering development', whatever that means. What OSS project ships
known broken crap with it's implied support (and responsibility!).
-jon
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
