Language:
switch to room list switch to menu My folders
Go to page: [1] 2 3 4 5 ... Last
↑↑↑ Old messages ↑↑↑            ↓↓↓ New messages ↓↓↓
[#] 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.



 



[#] Wed Nov 01 2017 12:57:58 EDT from techacq1Aa @ Uncensored

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

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

Hi Kinetix,

Thanks for the interest -

yes what you describe is exactly what I am working against.

I expect I have probably mangled something in the install or later, but not quite sure where it went off the rails.

The OS is the atest Solydx which is a very close Debian descendan, but there are variations to be sure.

 

There are a number of issues and I suspect they all arise from common mismatches.

The MTA and MSA ports both work well, using SSL everything is tight and works mostly,
except for the Preferred Display Name.

(Looking at your use of Thunderbird, I will give that a try tomorrow,

but our staff are allergic to anything that does not involve MicroSoft, sadly.)

 

The result is that the desired username is replaced with the login name.

This is a disappointment in that I am trying to provide login names very different from email addresses and preferred names.

For example:

 

1.
for Bob@somecitamail.com

2.
he might want his emails show the  attribution  "Mr. Robert Payswell"

3.
and I give him a login username of  "FaBd51bB"  alongside an encouragement to use a real passphrase

 

but this all is pointless  if everyone receives emails from:    "FaBd51bB" <Bob@somecitamail.com>

instead of "Mr. Robert Payswell" <Bob@somecitamail.com>

 

Using something beside "Bob" as the login username is a big reason for all this,

 I seem to be swimming in an ocean of people who insist on email names like "Mary@" "Bob@" "Tom@" and "Joe@"

with passwords like 123456 or 77777777 and unable to fathom logins longer than 6 letters long.

But we must try....

 

 

cheers

 

 

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

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 ... Last