Language:
switch to room list switch to menu My folders
Go to page: 1 2 3 [4] 5 6 7 8 ... Last
[#] Tue Oct 17 2017 06:32:58 EDT from techacq @ Uncensored

Subject: Re: RPi2 Debian Stretch: Easy Install failing at serv_crypto.o

[Reply] [ReplyQuoted] [Headers] [Print]

Me too but I fixed it with a tried and reliable shotgun approach. ;^)

modules/crypto/serv_crypto.c:305:35: error: dereferencing pointer to incomplete type 'X509_REQ {aka struct X509_req_st}'
      X509_set_issuer_name(cer, req->req_info->subject);
                                   ^~
In file included from /usr/include/openssl/ssl.h:48:0,
                 from modules/crypto/serv_crypto.c:20:
modules/crypto/serv_crypto.c: In function 'CtdlStartTLS':
modules/crypto/serv_crypto.c:637:23: error: dereferencing pointer to incomplete type 'SSL {aka struct ssl_st}'
  BIO_set_close(CC->ssl->rbio, BIO_NOCLOSE);
                       ^
At top level:
modules/crypto/serv_crypto.c:61:22: warning: 'id_callback' defined but not used [-Wunused-function]
 static unsigned long id_callback(void)
                      ^~~~~~~~~~~
Makefile:145: recipe for target 'modules/crypto/serv_crypto.o' failed
make: *** [modules/crypto/serv_crypto.o] Error 1
Operating system: Linux Debian 9.1 ( 4.9.0-4-amd64 x86_64)

 

The error indicates dereferenced pointers in libssl stuff

so I installed a couple of out-of-scope dev files which brought in the necessary bits to get it all working:

Install: lua-luaossl-dev:amd64 (20161214-1), lua-luaossl:amd64 (20161214-1, automatic)

Install: libbsd-dev:amd64 (0.8.3-1, automatic), libghc-network-dev:amd64 (2.6.3.1-3+b1, automatic), libffi-dev:amd64 (3.2.1-6, automatic), libgmp-dev:amd64 (2:6.1.2+dfsg-1, automatic), ghc:amd64 (8.0.1-17+b1, automatic), libgmpxx4ldbl:amd64 (2:6.1.2+dfsg-1, automatic), libghc-hsopenssl-x509-system-dev:amd64 (0.1.0.3-2+b1), libncurses5-dev:amd64 (6.0+20161126-1+deb9u1, automatic), libtinfo-dev:amd64 (6.0+20161126-1+deb9u1, automatic), libssl1.0-dev:amd64 (1.0.2l-2, automatic), libghc-hsopenssl-dev:amd64 (0.11.3.2-3+b1, automatic)
Remove: libssl-dev:amd64 (1.1.0f-3)

this is a SolydX machine which is a Debian derivative:

 

note that  this removes         libssl-dev,

so this is just a 5-minute hack which should probably be repealed  when the next fixes come out,

I presume.

 

 

 

 

Mon Oct 09 2017 05:12:26 EDT from madpoet @ Uncensored Subject: Re: RPi2 Debian Stretch: Easy Install failing at serv_crypto.o

I suppose that could be the case. In previous updates to this thread, I include the versions/package info for all the packages noted as needed on the install site. I tried to compile it without easy install and I get the same results. If you would like me to manually compile anything, please let me know what.

 

Thu Oct 05 2017 11:48:39 EDT from bennabiy @ Uncensored Subject: Re: RPi2 Debian Stretch: Easy Install failing at serv_crypto.o

Is it possible that the RPi repos you are using might not have the full versions of the dependencies? I know it compiles fine on a standard system, and have not tried it on a pi yet. I would check to make sure you have the correct openssl dev packages and that might mean compiling openssl for your pi.

Wed Oct 04 2017 01:53:27 AM EDT from madpoet @ Uncensored Subject: Re: RPi2 Debian Stretch: Easy Install failing at serv_crypto.o

Yes, agreed. My google-fu is failing on this as well though. I am getting no where troubleshooting it. Do you have any suggestions?

Tue Oct 03 2017 17:13:15 EDT from bennabiy @ Uncensored Subject: Re: RPi2 Debian Stretch: Easy Install failing at serv_crypto.o

This might have something to do with it...

In file included from /usr/include/openssl/ssl.h:48:0,
                 from modules/crypto/serv_crypto.c:20:
modules/crypto/serv_crypto.c: In function 'CtdlStartTLS':
modules/crypto/serv_crypto.c:637:23: error: dereferencing pointer to incomplete type 'SSL {aka struct ssl_st}'
  BIO_set_close(CC->ssl->rbio, BIO_NOCLOSE);
                       ^



 



 



 



 



[#] Thu Oct 19 2017 06:57:46 EDT from techacq1 @ Uncensored

Subject: Re: Mail Aliases not beeing saved

[Reply] [ReplyQuoted] [Headers] [Print]

This appears to be a permissions issue

apparently admin level can edit vcards,

 but 'preferred' and lower user levels are unable.

Here on Uncensored this works correctly,

so the problem could be some kind of configuration issue.

Since this is Easy Install there is probably someone who may be able to point out where this goes wrong.

Perhaps this is a PAM probleThe 5minute hack solution is to just assign editing to the admin level,

 and there may be good reasons not to leave this to lesser permissions due to the potential for misuse. ?

 

 

Wed Aug 30 2017 12:15:37 EDT from Maria @ Uncensored Subject: Re: Mail Aliases not beeing saved

 

Mon Aug 28 2017 12:17:24 EDT from Maria @ Uncensored Subject: Mail Aliases not beeing saved

(newest Version over Easy Install)

 

Hi, another small Problem:

When I enter an E-Mail Alias into the Vcard of the user and hit save... it`s not been saved!

Not sure why... everything else, for example Fax, Telephone, Name is saved...

I found the file "mail.aliases" and made the changes there... but not shure about the syntax there, how to make one Mail Alias for 4 Users (so 3 Users share the same alias)

Checked also the permissions of the file "mail.aliases", seems to be OK (staff > 644)

ThX for any Help :)

Maria



Hi... Could anybody help me with this?

Or how is the right Syntax for the "mail.aliases" File?

I`m using:

test@domain.com, user1

 

Thanks in advance.. ;)



 



[#] Thu Oct 19 2017 13:48:49 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]


Ok, so if Citadel builds without libssl-dev, it means there's something in the new version of OpenSSL that is breaking Citadel, and by temporarily removing libssl-dev you are building Citadel without encryption support. If that's an acceptable workaround, go for it. We will have to figure out what changed and code around it.

[#] Thu Oct 19 2017 22:29:23 EDT from techacq1 @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]

 

Thu Oct 19 2017 13:48:49 EDT from IGnatius T Foobar @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

Ok, so if Citadel builds without libssl-dev, it means there's something in the new version of OpenSSL that is breaking Citadel, and by temporarily removing libssl-dev you are building Citadel without encryption support. If that's an acceptable workaround, go for it. We will have to figure out what changed and code around it.


I will examine what is going on and report back,

which is about all the time I have to help  out with this at this moment.

 

The server created with the hack as described

 does work through https (port 80/2000 is locked out in this instance),

It does seem to work without libssl-dev in this fashion

 but this out-of-scope solution probably causes other problems

 not yet perceptible.


and yes - encryption support is too important to live without.


cheers



[#] Thu Oct 19 2017 22:58:18 EDT from techacq1 @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]

Perhaps I should have attached some wireshark dump on this ?

- it appears to be encrypted according to what I see at first look...

 

Thu Oct 19 2017 22:29:23 EDT from techacq1 @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

 

Thu Oct 19 2017 13:48:49 EDT from IGnatius T Foobar @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

Ok, so if Citadel builds without libssl-dev, it means there's something in the new version of OpenSSL that is breaking Citadel, and by temporarily removing libssl-dev you are building Citadel without encryption support. If that's an acceptable workaround, go for it. We will have to figure out what changed and code around it.


I will examine what is going on and report back,

which is about all the time I have to help  out with this at this moment.

 

The server created with the hack as described

 does work through https (port 80/2000 is locked out in this instance),

It does seem to work without libssl-dev in this fashion

 but this out-of-scope solution probably causes other problems

 not yet perceptible.


and yes - encryption support is too important to live without.


cheers



 



[#] Fri Oct 20 2017 10:15:05 EDT from bennabiy @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]

libssl-dev is 1.1 now, but there is a compatibility file for now which gives the 1.0.2 api, which works for citadel. If you include libssl1.0-dev instead of libssl-dev, it should compile as normal... for now.

Thu Oct 19 2017 01:48:49 PM EDT from IGnatius T Foobar @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

Ok, so if Citadel builds without libssl-dev, it means there's something in the new version of OpenSSL that is breaking Citadel, and by temporarily removing libssl-dev you are building Citadel without encryption support. If that's an acceptable workaround, go for it. We will have to figure out what changed and code around it.

 



[#] Sun Oct 22 2017 11:04:24 EDT from manupatet @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]

 

Fri Oct 20 2017 10:15:05 EDTfrom bennabiy @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

libssl-dev is 1.1 now, but there is a compatibility file for now which gives the 1.0.2 api, which works for citadel. If you include libssl1.0-dev instead of libssl-dev, it should compile as normal... for now.

Thanks for this lead, huge relief that I'm not alone with this. Could you also post the commands to disable/downgrade OpenSSL to 1.0? I tried 'pacman -U' and using soft-links to point to the old libssl, without much luck.
Thanks
Manu


[#] Sun Oct 22 2017 12:06:28 EDT from bennabiy @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]

The packages I listed were for Debian. I am not sure if Arch has a similar issue, and similar package, but I am not sure. I do not use Arch.

Sun Oct 22 2017 11:04:24 AM EDT from manupatet @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

 

Fri Oct 20 2017 10:15:05 EDTfrom bennabiy @ Uncensored Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

libssl-dev is 1.1 now, but there is a compatibility file for now which gives the 1.0.2 api, which works for citadel. If you include libssl1.0-dev instead of libssl-dev, it should compile as normal... for now.

Thanks for this lead, huge relief that I'm not alone with this. Could you also post the commands to disable/downgrade OpenSSL to 1.0? I tried 'pacman -U' and using soft-links to point to the old libssl, without much luck.
Thanks
Manu


 



[#] Tue Oct 24 2017 01:55:26 EDT from techacq1 @ Uncensored

Subject: Re: Citadel is running, no STARTTLS

[Reply] [ReplyQuoted] [Headers] [Print]

I was searching for the answer to this and how to possibly repair it

when I stumbled upon the code for citadel.c:

Finally, we only offer TLS on
         * the SMTP-MSA port, not on the SMTP-MTA port, due to
         * questionable reliability of TLS in certain sending MTA's.

 

which explains why we get this warning from people like mxtoolbox.com:

ESMTP Citadel server ready.

 TestResult 
SMTP TLS Warning - Does not support TLS.

 

which is simply what you see when you run telnet on the port25.

Given that so much of the world cannot be bothered to encrypt ( ala latimes.com and a whole planet of that ilk !)

it is not such a surprise. TLS and encryption is an aggregation of moving parts.

 

Thu Jun 01 2017 11:12:40 EDT from graylion @ Uncensored Subject: Citadel is running, no STARTTLS

This is a fun one. I have citadel installed via easy install. all seems good. If I go to checktls.com, I get this:

seconds test stage and result
[000.112]   Connected to server
[000.356] <--  220 mail.socialdemocrats.ie ESMTP Citadel server ready.
[000.357]   We are allowed to connect
[000.357]  --> EHLO checktls.com
[000.622] <--  250-Hello checktls.com (www4.checktls.com [216.68.85.112])
250-HELP
250-SIZE 10485760
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 8BITMIME
[000.622]   We can use this server
[000.622]   TLS is not an option on this server

if I telnet to localhost port 25, I get the same. But when I state "starttls", I get 220 start tls negotiation

Whatnow? And how do I persuade citadel to offer starttls on ehlo?

Thanks!

 

 

 

 

 



 



[#] Thu Oct 26 2017 10:13:17 EDT from IGnatius T Foobar @ Uncensored

Subject: Re: EasyInstall on Arch giving compilation errors about incomplete types

[Reply] [ReplyQuoted] [Headers] [Print]


The code downloadable from the web site, and via Easy Install, has been patched.
It should work with OpenSSL 1.1 now.

Big thanks to Chris West who sent in the required patches. Turns out we already had this fixed in the development tree thanks to his efforts; we just had to backport those patches to production.

[#] Mon Oct 30 2017 06:34:35 EDT from HDuepmann @ Uncensored

Subject: Install ssl-certifikate from CA (Commodo)

[Reply] [ReplyQuoted] [Headers] [Print]

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



[#] Mon Oct 30 2017 13:42:00 EDT from Dedonde @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mon Oct 30 2017 06:34:35 EDT from HDuepmann @ Uncensored Subject: Install ssl-certifikate from CA (Commodo)

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



Was getting the certificate from Commodo free? I have used startSSL in the past and I am hoping I can use it again and get it working.

How have you dealt withe securing your mail server?



[#] Tue Oct 31 2017 01:50:17 EDT from kinetix @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

[Reply] [ReplyQuoted] [Headers] [Print]

I think there's two sane ways to go about this - use the .key, .csr and .crt files as directed in http://citadel.org/doku.php/faq:systemadmin:how_to_install_a_certificate_signed_by_a_recognized_certificate_authority or use apache to do the SSL and offload that work to apache using proxypass http://citadel.org/doku.php/faq:installation:apacheproxy

With Apache you can do SNI, so you can use multiple SSL setups on a single IP, which may have some benefit to you.



[#] Tue Oct 31 2017 01:56:03 EDT from kinetix @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

[Reply] [ReplyQuoted] [Headers] [Print]

Was getting the certificate from Commodo free? I have used startSSL in the past and I am hoping I can use it again and get it working.

As a public service, I would strongly recommend against using startSSL ever again, browsers aren't trusting them any longer, and for good reason: https://en.wikipedia.org/wiki/StartCom
From what I've seen lately, it's worth your while to setup certbot and use https://letsencrypt.org/ if you want free certificates.  Seems to work very nicely.


[#] Tue Oct 31 2017 04:15:54 EDT from bennabiy @ Uncensored

Subject: Re: Install ssl-certifikate from CA (Commodo)

[Reply] [ReplyQuoted] [Headers] [Print]

citadel.key and citadel.cer and then dont forget to link webcit to them as well....

Mon Oct 30 2017 06:34:35 AM EDT from HDuepmann @ Uncensored Subject: Install ssl-certifikate from CA (Commodo)

I have a certificate generated for apache2 (key, crt, ca-bundle) on my Citadel-Server with the proper FQDN. Can I use this files just by renaming them to citadel.key, citadel.cer and citadel.ca-bundle and put them in place instead of the existing files. What is about the csr-file.



 



[#] Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored

Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

[Reply] [ReplyQuoted] [Headers] [Print]

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



[#] Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

[Reply] [ReplyQuoted] [Headers] [Print]

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



[#] Wed Nov 01 2017 00:11:45 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

[Reply] [ReplyQuoted] [Headers] [Print]

well, what can I say ?

one space is okay for login name but SENDCOMMAND RENU reaalllyy does not like that,
even wrapped in quotes, escaped in backlsahes or whatever

using two adjacent spaces is even more exciting
- I can login with a username of "one two  three" and have no problems inside WEBCIT,

but deleting the user "one two  three" seems to be mission utterly impossible.

we are having fun now ;^)}

 

Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,

we still get hung up by the 'preferred display name' not being used when connecting from outside SMTP.

It appears that only WebCit understands how to retrieve the "Preferred Display Name for Email Messages".

 

from serv_smtp.c:

 341 /*
 342  * The configuration item for the user's preferred display name for outgoing email is, unfortunately,
 343  * stored in the account's WebCit configuration.  We have to fetch it now.
 344  */

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



 



[#] Wed Nov 01 2017 02:21:46 EDT from techacq1Aa @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

[Reply] [ReplyQuoted] [Headers] [Print]

learned something new today:

sudo /usr/local/citadel/sendcommand "ASUP someUserNamewhatever|0|0|0|0|0|"

will erase even a username with two consecutive spaces in it, as demonstrated below with a username of "one two  three":

sudo /usr/local/citadel/sendcommand "ASUP one two  three|0|0|0|0|0|"

The key is wrapping the entire ASUP command in quotes so SENDCOMMAND sentds it as a single sentence.

Using webcit aide status does not work at this time for usernames with two consecutive spaces

(adjacents become a single space, which fail the test for deletion - on my particular OS,

so probably not always true )

now back to SEENDCOMMAND IGAB and fixing the Display Name issue....

Wed Nov 01 2017 00:11:45 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

well, what can I say ?

one space is okay for login name but SENDCOMMAND RENU reaalllyy does not like that,
even wrapped in quotes, escaped in backlsahes or whatever

using two adjacent spaces is even more exciting
- I can login with a username of "one two  three" and have no problems inside WEBCIT,

but deleting the user "one two  three" seems to be mission utterly impossible.

we are having fun now ;^)}

 

Tue Oct 31 2017 23:39:25 EDT from techacq1Aa @ Uncensored Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Notes along the way:

Webcit runs as root but citserver runs as a user (citadel or whatever set) but this is apparently not the problem.

I was thinking this may be some systemd issue (having run into systemd permissions issues elsewhere)
but running without using systemD fails the display name as well, so this may not be the issue. Still investigating...

usernames with spaces (yep, this is not windows but I find that a single space is acceptable in login name
and also (as usual) in display names. for an email address this obviously fails,

 but maybe using spaces in the login name could be a problem, checking now.

The plan to "raise the security bar" by using an obfuscation login name with a different email  username is thwarted
by the failure to have a username assigned to emails, which is why this is a definite "want".

And I will continue to dig,
someone else may end up here looking for this problem someday.

cheers for now

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

Accepting that aliases are for the moment stuck,



 



 



 



[#] Wed Nov 01 2017 11:41:45 EDT from kinetix @ Uncensored

Subject: Re: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

[Reply] [ReplyQuoted] [Headers] [Print]

Hey there,

Can you describe in a little further detail what exactly is occurring, and where?  What are you trying to do and/or what are the expected results, and what are you experiencing instead?

From what I understand from your report, you're not able to set the From: email header the way that you'd like - is that the issue?  I just ran a test through a citadel installation of mine, using Thunderbird (though it shouldn't make a difference), and delivering through the MSA port, the From shows the name I configured in Thunderbird.

Perhaps that's not quite what you're having issues with, though?

 

Tue Oct 31 2017 06:50:08 EDT from techacq1 @ Uncensored Subject: Preferred Display Name unavailable outside Webcit for SMTP/IMAP emails

when sending from Webcit we have a username,

when sending from something like Claws, Outlook, etc  we get the login name (=room name)

the aliases issue seems to have more to it than first appeared.

(Editing the Global Address Book has no effect, just in case someone suggests)

Debian 9.1  here, latest Easy install upgrade (today)

Still looking but not sure where in the logs to go for this vcard ? issue

probably something simple, as usual.



 



Go to page: 1 2 3 [4] 5 6 7 8 ... Last