Part of our app allows users to input their SMTP server info for sending emails, and users are always coming up with combinations we aren't set up to test. Specifically, looking at these Java mail props: mail.smtp.auth, mail.smtp.starttls.enable, and mail.smtp.ssl.enable.
Are all 8 combinations valid? (Valid as in there could be some server somewhere that requires that combination -- I already know Java will let me set any of these) If not, which would not be valid combinations? Bonus points for links to where this is documented -- my googlefu has failed me on this.
Related
I'm developing a product that need to integrate with RADIUS server as an authentication method.
When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.
I did some research on how to do it,
My options are:
Send Access-Request message with fictional user name and password to the RADIUS server
Send Status-Server message to the RADIUS server
RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol.
This packet extension enabling clients to query the status of a RADIUS server.
The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC
My questions are:
Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
Are these vendors supporting Status-Server request - Do they implementing this packet type ?
If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?
Thanks a lot,
Yossi Zrahia
Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.
Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:
IP: 1.2.3.4
Port: 1812
Shared Secret: U7tr453cur3
Servercheck: [x] Status-Server
[ ] Access-Request
Ad 3) From RFC2865, section 5.18 (Reply-Message):
"[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."
There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:
"A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."
I have added International Domain Name support to an XMPP client as specified in RFC 6122. In the RFC it states:
Although XMPP applications do not communicate the output of the
ToASCII operation (called an "ACE label") over the wire, it MUST be
possible to apply that operation without failing to each
internationalized label.
However, with the domain I have available for testing (running Prosody 0.9.4; working on getting feedback from someone else about how Ejabberd handles this), sending a Unicode name in the "to" field of an XMPP stanza causes them to immediately return an XMPP error stanza and terminate the stream. If I apply the toASCII operation before sending the stanza, the connection succeedes, and I can begin authentication with the server.
So sending:
<somestanza to="éxample.net"/>
Would cause an error, while:
<somestanza to="xn--xample-9ua.net"/>
works fine.
Is it correct to send the ASCII representation (ACE label) of the domain like this? If so, what does the spec mean when it says that "XMPP applications do not communicate the output of the ToASCII operation ... over the wire"? If not, how can I ensure compatibility with misbehaving servers?
CentOS 6, Postfix, OpenDKIM
Have correct DNS records
Sending email using PHP mail() to appmaildev.com - returns auth-report:
SPF result: Pass
DKIM result: fail (wrong body hash: MpaYoPlKy8H4qX8syH3dOM1gPr6spBK5/INxl2X2uNs=)
Tried different solutions - no result
Any ideas?
There are several causes for these two errors: the message may have been modified (perhaps by a mailing list or forwarder) in transit; the signature or hash values may have been calculated or applied incorrectly by the signer; the wrong public key value may have been published in DNS; or the message may have been spoofed by an entity not in possession of the private key needed to calculate a correct signature.
Any way you can check your DKIM entry for your MAIL-FROM domain here
I know this is an older post but, I ran into this issue yesterday. If you are using MailScanner for anti-spam efforts, try disabling the watermarking feature. I found the added watermark headers were invalidating DKIM hashes. Disabling the watermarks allowed the DKIM hashes to be valid. Yahoo was bouncing mail due to this.
As the above poster mentioned, I also had this problem. We use a windows server as our mailserver and we have antivirus installed on it.
It was setup to scan each outgoing message, but this changed the hash / body of each mail, thus failing the DKIM check.
So if you have this wrong body hash error, make sure you don't scan outgoing mails :)
I want to implement a simple authentication in C++. For now I can initiate a stream, get supported mechanisms and chose one. It works fine, but now I can't read out (from http://xmpp.org/extensions/xep-0034.html#sect-id259287 ) what I have to write into the plaintext handshake. Decoding the string I get "robsecret". So how do I do it with username "user" and passsword "pass"?
PS: Response using "userpass" is "".
Thanks!
You do of course realize that this is a retracted XEP you are trying to find information in?
The relevant documents are RFC 6120 (XMPP Core) and RFC 4616 (SASL PLAIN).
Short version:
PLAIN requires you to send base64("authzid\0authcid\0password"), where authzid is usually empty and authcid is your username.
I'm trying to learn the XMPP spec (RFC 3920) by coding it in low-level Python. But I've been hung up for over an hour at step 4 of section 6.5, selecting an authentication mechanism. I'm sending: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'/>, and getting: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><incorrect-encoding/></failure> instead of a base64-encoded challenge.
The "incorrect-encoding" error is supposedly to be used for when I incorrectly base64-encode something, but there was no text to encode. I'm probably missing something really obvious. Anybody got a cluestick?
I'm using talk.google.com port 5222 as the server, if that matters. I doubt that it does; this is almost definitely due to my lack of understanding this section of the RFC. And the problem isn't likely my code, other than the way I'm sending this particular stanza, or it would be failing at the previous steps. But for what it's worth, here is the code I've got so far, and the complete log (transcript of the session). Thanks.
First off, RFC 6120 is often more clear than 3920. [updated to point to the RFC as released]
Since you're using SASL PLAIN (see RFC 4616), many servers expect you to send a SASL "initial response" in the auth element, consisting of:
base64(\x00 + utf8(saslprep(username)) + \x00 + utf8(saslprep(password)))
All together, then, your auth element needs to look like this:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
For the username "juliet" and the password "r0m30myr0m30".