530060:
--------------
Fix the following problems as indicated by Christoph Bartoschek in kde-pim:
- kmail/imapjob.cpp:240
- kmail/imapjob.cpp:262 (similar)
If account is NULL as indicated by line 226, then line 240 crashes.
- kmail/imapjob.cpp:104
If msg_parent is NULL as indicated by line 90, then line 104 crashes.
530074:
--------------
Second batch of fixes related to Christoph Bartoschek's report in kde-pim:
- kmail/kmfoldercachedimap.cpp:1749
If the if conditions in line 1741 and 1745 are both false, then line 1749 crashes.
- kmail/kmfoldertree.cpp:1480
If fti is NULL as indicated by line 1475, then line 1480 crashes.
- kmail/kmfoldertree.cpp:164
If mFolder is NULL as indicated by line 154, then line 154, 160 crash.
- kmail/kmfoldertree.cpp:143
If mFolder is NULL as indicated by line 136, then line 143 crashes.
- kmail/kmfoldertree.cpp:1549
If folder is NULL as indicated by line 1537, then line 1549 crashes.
The last bug is only partially fixed, the whole KMFolderTree::slotUpdateCounts(KMFolder * folder)
function could use a rewrite.
530119:
------------
Third batch of fixes related to Christoph Bartoschek's email in kde-pim:
- kmail/imapaccountbase.cpp:1102
If line 1092 gets executed and also 1102, then the second crashes.
- kmail/kmmsgdict.cpp:248
If folder is NULL as indicated by line 244, then line 248 crashes.
- kmail/kmmsgdict.cpp:214
If folder is NULL as indicated by line 208, then line 214,225, crashes.
- kmail/renamejob.cpp:64
If storage is NULL as indicated by line 57, then line 62 crashes.
Lines where the operator preference between & and == leads to an error.
- kmail/kmmsgbase.cpp:873
- kmail/kmfolderimap.cpp:876
If f is NULL as indicated by line 869, then line 876 crashes.
- kmail/kmsender.cpp:362
If sentFolder is NULL as indicated by line 340, then line 362, 367
crashes.
Thanks to Christoph for working on this.
svn path=/trunk/KDE/kdepim/; revision=532932
SVN commit 490568 by tilladam:
Implement a non-gui-exposed option to allow sending of MDN messages with
an SMTP MAIL FROM of <>, which conforms to the rfc, but doesn't work
with many real world servers, since they discard such messages for spam
protection. Still, integrators might want to set it, via Kiosk, for
example.
svn path=/trunk/KDE/kdepim/; revision=490572
QMAX/QMIN -> qMax/qMin
I don't know what to do about Q_LONG and Q_ULONG because of the following code in qglobal.h:
#if defined(Q_OS_WIN64)
typedef __int64 Q_LONG; /* word up to 64 bit signed */
typedef unsigned __int64 Q_ULONG; /* word up to 64 bit unsigned */
#else
typedef long Q_LONG; /* word up to 64 bit signed */
typedef unsigned long Q_ULONG; /* word up to 64 bit unsigned */
#endif
Should I simply convert to (unsigned) long?
svn path=/trunk/KDE/kdepim/; revision=468393
Improve the sent mail folder logic and the readOnly protection to
first try the folder specified in the mail, then if there was none, or
it's not usable, try the identity one, and if that also fails, the
system one.
svn path=/branches/kdepim/proko2/kdepim/; revision=433147
first try the folder specified in the mail, then if there was none, or
it's not usable, try the identity one, and if that also fails, the
system one.
svn path=/trunk/KDE/kdepim/; revision=433145
- addRecipients was a Template Method that called virtual addOneRecipient() = 0 in a loop. I might even be the one to blame for that, but the need for the curious temporary member variables mQuery* made me inline addRecipients. After all, for sendmail it's just appending all the stuff to the command line, and for SMTP it's more readable as a simple QStringList::join(). So add*Recipient*() are gone.
svn path=/trunk/KDE/kdepim/; revision=430477
here: http://lists.kde.org/?l=kmail-devel&m=111945756024656&w=2
I've changed the KMMsgDict::instance() to return a pointer instead of a
reference, compared to the patch I posted, after valid criticism from
Marc that the pattern is generally used with a pointer, in KDE, so it's
better not to surprise people here.
svn path=/trunk/KDE/kdepim/; revision=428560
a specified transport.
This means that if the user moves from home to the office or somesuch he
can override the trasnport in the queued msg and force all mail to be sent
using a specific transport that he knows works.
Also it will pop up a warning if the selected transport is non encrypted to
avoid sending sensitive emails over an unecnrypted transport.
svn path=/trunk/kdepim/; revision=401726
Don't let KMail forget the "X-KMail-Recipients" header if sending
of messages failed (Patch by Ingo Klöcker)
svn path=/branches/KDE_3_4_BRANCH/kdepim/; revision=398187
CVS commit by tilladam:
Fix issue 139 by using the mechanism we use for setting the replied and
forwarded status after a mail has been sent succesfully to move the mail
that originally triggered the sending of the accept/decline mail, whose
serial number is remembered in a link header to the trash folder configured
for that account. In other words, if you click to accept an invitation, and
then send the generated reply, the invitation mail will automagically go
away.
svn path=/trunk/kdepim/; revision=347299
forwarded status after a mail has been sent succesfully to move the mail
that originally triggered the sending of the accept/decline mail, whose
serial number is remembered in a link header to the trash folder configured
for that account. In other words, if you click to accept an invitation, and
then send the generated reply, the invitation mail will automagically go
away.
svn path=/branches/KDE_3_3_BRANCH/kdepim/; revision=347297
Volker Krause
Reinhold Kainhofer
Dirk Mueller
Allen Winter
Stephan Kulow
Laurent Montel
Ismail Onur Filiz
Chusslove Illich
Andreas Gungl
Till Adam
Ingo Klcker
Stephan Binner
Marc Mutz
Matt Douhan
Carsten Burghardt
Karl-Heinz Zimmer