IMAP protocol support in different email servers - exchange-server

Having to interact with several different email servers via IMAP (using javamail), I have found that there is a very different level of support for IMAP features among them. The lack of support of some features has resulted in more developing time, more complicated code to deal with different support, worse perforamance due to not being able to SEARCH etc.
So I would like to get some info on other servers and what level of support they provide. So far I have dealt with Lotus Domino and Novell GroupWise (and to a lesser extend Exchange 2003 and 2007). I am particularly interested in most used one in unix/linux (Courier, Cyrus, Dovecot, UW IMAP) and also Zimbra, but feel free to add any you know. Also welcomed info about online services like gmail.
Features that I consider (comment if you are interested in others and I'll add them.
Custom flags
Searching Custom flags
Searching arbitrary headers
Partial fetching
Proxy authentication
And what I have found so far (correct if I am wrong anywhere):
Lotus Domino
Custom flags yes
Searching Custom flags yes
Searching arbitrary headers yes
Partial fetching ?
Proxy authentication sort of, you can give some user permissions to access other
users mailboxes and he will see them under his '\Other Users' folder
Novell GroupWise
Custom flags No
Searching Custom flags No
Searching arbitrary headers No
Partial fetching ?
Proxy authentication yes, you can use what is called a Trusted Application
Dovecot
Custom flags: yes
Searching Custom: yes
Searching arbitrary headers: yes
Partial fetching: yes
Proxy authentication: ?
Remarks: A list of custom flags is sent in "FLAGS" response of SELECT/EXAMINE commands and "PERMANENTFLAGS" response of SELECT command. This also includes flags that are no longer used. I'm not sure whether it's possible to get rid of these.
Gmail
Custom flags: yes
Searching Custom: yes
Searching arbitrary headers: yes
Partial fetching: yes
Proxy authentication: no
kudos Lukas! I'll wait for your exchange info and I'll add some stuff if you don't have it (I tested some time ago so your info will be more reliable)

This is what I tried so far. I will try to add more later (have access to Exchange 2003&2007 and Courier) later.
Dovecot
Custom flags: yes
Searching Custom: yes
Searching arbitrary headers: yes
Partial fetching: yes
Proxy authentication: ?
Remarks: A list of custom flags is sent in "FLAGS" response of SELECT/EXAMINE commands and "PERMANENTFLAGS" response of SELECT command. This also includes flags that are no longer used. I'm not sure whether it's possible to get rid of these.
Gmail
Custom flags: yes
Searching Custom: yes
Searching arbitrary headers: yes
Partial fetching: yes
Proxy authentication: most likely not
Remarks: It looks like there is no way to retrieve a list of currently-used custom flags.

Gmail IMAP session, doesn't look too good for PROXYAUTH:
---
* OK Gimap ready for requests from 1.1.1.1 wi9if8940621pbc.126
A001 LOGIN testuser testpassword
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE
A001 OK testuser Test User authenticated (Success)
A001 PROXYAUTH someotheruser
A001 BAD Unknown command: PROXYAUTH

Related

Firefox Okta integration, setting up Agentless DSSO

I am currently using trying to set up DSSO with Okta utilizing Firefox. I have been able to successfully set up Edge/Chrome/IE on the domain without issue. I have set the following documentation as outlined on the Okta website for setting up Firefox to no avail. We have been troubleshooting with the Okta experts for the last three days with no forward progress, so I figured I would post the information available here:
Firefox version 107.0.1 32-bit
TLS 1.2
NTLM v2
Windows Server 2019
the result that the agentlessDssoPrecheck is returning:
{"result" : "FAIL_NTMLSSP"} - (that is not a misspelling; the return should be NTLM, but whatever)
I have the following options set in Firefox:
network.negotiate-auth.trusted-uris. org.kerberos.okta.com
network.negotiate-auth.delegation-uris org.kerberos.okta.com
network.negotiate-auth.allow-non-fqdn true
network.negotiate-auth.allow-proxies true
network.automatic-ntlm-auth.trusted-uris org.kerberos.okta.com
network.automatic-auth.allow-non-fqdn true
I attempted to pull the logs using set NSPR_LOG_MODULES=negotiateauth:5, but while Firefox does create the log, it doesn't write anything, including the failure to the log. (If I set the value to all:5, I get a ton of information, it appears useless for what I am trying to troubleshoot)
I attempted to pull fiddler and Wireshark information; I haven't set up the decoding on the Wireshark portion yet; however, I did get an extract of the fiddler information, but I didn't spot anything in there that seemed to indicate why the failure was occurring.
I have one suspicion; the following option in both Edge and Chrome has been set: DisableAuthNegotiateCnameLookup = enable - I don't see an option like that in Firefox or something similar to be able to adjust that value.
Some additional information to share:
Firefox is connecting to and submitting an authentication message to org.kerberos.okta.com; however, it appears to be in the wrong format.
"""Received authorization header contains raw NTLM token, will fail
precheck. Okta is not getting Kerberos ticket but raw NTLM token
instead."""
Firefox with Kerberos can be sensitive to reverse name lookups.
For testing purposes have you tried to set a manual entry in the hosts file with an entry to return the correct DNS name?
I would be interested to know your results from Wireshark using the following filter
dns || Kerberos

what sip middleware can I use to modify sip headers

my sip provider doesn't support some SIP headers that I need to send to my IP Phones. I can specify my own headers, but my provider add some prefix in front of them everytime.
I need to send Call-info header to my phone. But my provider adds something like X-PH- prefix so my IP phone doesn't understand that modified header.
I need to create some sort of middleware which I'll have between IP phone and Provider's server in my network. Is there any proxy / middleware that I can use?
I would recommend putting a Session Border Controller [Sonus, Dialogic etc] with "Header Manipulation Rules" Capabilities. Other options are using Opensips / Kamailio to make the header manipulations, but it has a learning curve for the way the rules are defined and of course the pain of putting it together in the network.
BTW, since you are specifically looking for RFC compliant SIP Headers [Call_info], you can always push for it with the carrier you are dealing with. Get them to comply to the SIP Specs. Maybe they see merit pushing their vendors for compliance.

Forwarding HTTP headers using Juniper

I'm working with a sysadmin that uses a Juniper solution that behaves as a proxy. I have no idea what it is, but here's a picture of the web interface: http://imagebin.ca/v/1UKN1jGYPUWd
Through that proxy, I'm trying to use Sharepoint's REST API, unfortunately there are some headers (such as X-RequestDigest) that Juniper's proxy doesn't forward to Sharepoint.
Basically, I need the equivalent of nginx's proxy_pass_request_headers for Junipers' applications.
The sysadmin doesn't seem to know what HTTP header forwarding is, or how to configure it. Can anyone identify the solution he's using from the picture ? Does anyone know where to find documentation about this ?
Further to my comment added above, there appears to be no way to implicitly pass variables around. You can tell the current IVEOS images that the Web URL you're linking to is a Sharepoint Site, and it'll do "clever" things with the URL, but I'm not exactly sure what you want it to do, and whether they'll handle it.
Here are the screen shots for the "Sharepoint" configuration panels on the Web Resources page. As I'm not a Sharepoint Admin, I can't tell you whether these are useful to you or not.
I hope it helps!
You may be looking for the Web Resource custom header policy
https://www.juniper.net/documentation/en_US/sa8.0/topics/task/operational/secure-access-web-rewrite-custom-header-policy.html
Edit: The first resource became a dead link. New link: https://www.juniper.net/techpubs/en_US/nsm2012.2/topics/task/configuration/remote-management-secure-web-resource-policy-configuring-nsm.html
Fur custom headers (to send some user information) we've used the "Web Rewriting Resource Policy"
SSO Cookies/Headers > General tab -> Headers and Values
to pass custom user data (user name, role, client certificate).
I assume you have the backend application (sharepoint) configured as the a PTP (PassthroughProxy) we bresource. I am pretty confident that only standard HTTP headers are passed to the backend by default :(
To pass all custom headers I found following book (Juniper(r) Networks Secure Access SSL VPN Configuration Guide): https://books.google.be/books?id=5OYf6u5vzFsC&pg=PA369&lpg=PA369&dq=Juniper+pass+custom+headers&source=bl&ots=s5oF5NEKjP&sig=8091EV2Pyw6pIFQifMOIR2pLpLk&hl=de&sa=X&ved=0ahUKEwiFwpf6m_DOAhWFWRQKHXoRD0EQ6AEIPDAE
where it says
Passing custom headers can be enabled by:
Users > Resource Polities > Web > Custom Headers
This option may not be visible on the admin interface by default, it needs to be enabled:
Users > Resource Policy > Web > Web ACL and there's a "Customize" button

security of sending passwords through Ajax

Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS

localhost :: cross domain ajax

Is there any way to tell your localhost that it can do cross domain ajax calls?
I need this for my testing.
If it is a browser specific issue i am using google chrome.
Cheers.
It's very possible. Let's start with a dev browser.
Step 1: Download Chromium
Windows -- http://www.chromium.org/getting-involved/download-chromium
Mac -- http://www.macupdate.com/app/mac/36244/chromium/
There should be a build ready to go, but these locations change over time. So if these end up with 404's do a Google search for Windows Chromium Download and you'll find it.
Step 2: Then run the executable with this flag after it. --disable-web-security
Windows -- Create a shortcut to the executable and tag this in the Properties. Or run from [CMD].
Mac -- Open up a terminal and run this straight from there with the flag.
And, you should be good to go. I also setup a quick Apache service and run through a 127.0.0.1 configured domain, but localhost should be just fine. Here's proof.
I hope this helps you!
No, it's absolutely not possible. If it could be disabled by the user then it would be the main target for anyone with nefarious or dubious intent, and as prone as any other software to exploitation. It's difficult enough making secure software, without painting on even more attractive targets.
The only way to implement cross-domain Ajax is to route requests via a server-side script.
It's worth mentioning that there is, perhaps, a glimmer of hope for you: in the form of cross-window messaging with HTML 5 postMessage
It's probably worth your having a read of some related (though I'm not sure they're duplicate) questions:
Why the cross-domain Ajax is a security concern?
Firefox Cross Domain Request
Edited in response to comment:
So you mean have a script that takes the params, adds them to the request, sends it out, and then echos out the response object?
Essentially yes. In picture format:
client |--------------> | server side |-----------------------> | remote domain
browser | <----ajax------| script | <------------------------|--/
Edited to add that this is now sort of possible, using Cross-Origin Resource Sharing (CORS); in which a script from one domain sends an Origin HTTP header stating the URL of the page, and the server can respond (if configured to do so) with either an error (if CORS is disabled, or unsupported) or with any requested data.
References:
CORS compatibility.
Cross-Origin Resource Sharing, at the W3.org.
Enable Cross-Origin Resource Sharing.

Resources