Re: From email address Validation
Hi Pratap, In smtpserver.conf, set the verifyIdentity tag to true. Thx, Eric On 14/12/2012 14:03, Pratap Kale wrote: Dear All, In apache james we are able to send the emails within same domain (ex. from us...@example.com to us...@example.com) wherein user1@example doesn't exist. Is there any configuration setting within apache james to validate for from address or has to be done manually within our application? ThanksRegards Pratap Kumar Kale - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
RE: From email address validation
In order to better understand the situation of MUAs and SMIME, I think it would be worth to know the behaviour of the various MUAs around. Right now we know that: 1) Outlook 2000 SP-3 9.0.0.6627 is OK (doesn't check the From header) 2) Outlook Express 6.00.2800.1123 is KO (checks the From header) I will send shortly to this same thread a probe message with a server side signature done by my mailet (so you can also see how it looks like). Please send a feedback about how your other different MUAs (Netscape, Eudora, Lotus Notes etc.) behave: is the message reported as being OK as for integrity, trust and everything else or not? This is the server signed message probe. Have a look on this message (the smime signature icon, the Signature.txt attachment etc.) and please report. Obviously, as I imagine that the replies will not come back at the speed of light, each one of us may see if somebody else has already replied a feedback related to a particular MUA product/version, in order to avoid jamming this list with duplicated reports. Next week I will summarize the results in this list. Thanks, Vincenzo The message this file is attached to has been signed on the server by Trusted Server [EMAIL PROTECTED] to certify that the sender truly has the following address (reverse-path): [EMAIL PROTECTED] and that the message has the following message headers: Subject: RE: From email address validation From: Vincenzo Gianferrari Pini [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Cc: null Reply-To: null Date: Thu, 25 Sep 2003 18:23:22 +0200 The signature envelopes this attachment too. Please check the signature integrity. Trusted Server [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: From email address validation
This is the server signed message probe. Have a look on this message (the smime signature icon, the Signature.txt attachment etc.) and please report. Obviously, as I imagine that the replies will not come back at the speed of light, each one of us may see if somebody else has already replied a feedback related to a particular MUA product/version, in order to avoid jamming this list with duplicated reports. Next week I will summarize the results in this list. Mozilla Thunderbird sees this as a valid signature. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From email address validation
On Thu, 25 Sep 2003 18:23:22 +0200 This is the server signed message probe. Have a look on this message (the smime signature icon, the Signature.txt attachment etc.) and please report. Obviously, as I imagine that the replies will not come back at the speed of light, each one of us may see if somebody else has already replied a feedback related to a particular MUA product/version, in order to avoid jamming this list with duplicated reports. Webmail from CommunigatePro 4.1.3 sees it as properly signed. -- Matt Pangaro Lokitech software . strategy . design http://www.lokitech.com p. 1.301.656.5501 m. 1.301.728.6906 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: From email address validation
Serge Knystautas provided the following straight lines: Noel J. Bergman wrote: We would want broad support. I don't know anything broader than S/MIME. I would differ with that, or at least put a spin on it... S/MIME is the John Malkovich of the email world... everyone has heard and has respect for it, but can you name a time you used it? Actually, yes. :-) And John sends his regards. ;-) Let me know when you're ready to have an email address that you can't send to mailing lists or check via webmail. If you want to authenticate, you can't use brain-dead clients. If you just want a limited justification, you can do more to support them. For example, on one list to which I am subscribed, someone is running a TMDA-type server. So the first time I sent e-mail to the list, I received a challenge from his server requiring a response in order to release the message. That helps, but if I were a spammer, I would simply use the sender addresses for people who are already subscribed to the list. I could generate sender-specific aliases, so that I can filter out senders who use the wrong address. But as soon as that technique catches on, the spammers will just start to pair up such addresses in their database. It would prevent long RCPT TO lists, but otherwise it is handleable in their databases. Unlike Evil Warlords, many spammers are simply immoral, not terminally stupid. Anything you send in the clear that they can see they can use. You are correct to view this as an identity theft issue. The problem is how to verify the identity of the sender. The reason that public key encryption works is because of asymmetric encryption. There is a secret that only one party knows, others doen't need to know it in order to operate, but it would need to be known to forge the identity. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: From email address validation
Guys, With respect to verifying that the sender is really the sender, there are two basic means. One is a digital signature, the other is MAIL FROM AUTH=, which is part of SMTP AUTH. In something of an ironic coincidence, I just heard back from Bill Shannon regarding JavaMail support for MAIL FROM AUTH=, and will CC the mailing list on my response. MAIL FROM AUTH= is used to pass on the identity of the authenticated sender in a chain of authenticated trust. Unfortunately, not only does JavaMail not support this now, but we have missed the window to get it into J2EE 1.4. We can try fixing this on our end by extending the MimeMessage and replacing the SMTP transport. The other caveat is that it requires an unbroken chain of authentication, so it has limited applicability on the Internet at large. Vincenzo has proposed that if SMTP AUTH is used the server could use a server certificate to sign the message, verifying that the server believes the sender to be authentic: if (i) SMTPAuth is on, and (ii) the From user is the same as the SMTPAuth-enticated user, a Sign mailet could sign the message using a single common server certificate, certifying that the sender email address was not forged. One of the checks performed on digitally signed e-mail is that the sender address be one of the authorized addresses within the public certificate. So it seems to me that in order to properly use a server signed certificate approach, we need to have the signing mailet set the RFC 2822 Sender: header to the address for the server certificate. So what I might get would be e-mail from Vincenzo, but sent (and signed) by [EMAIL PROTECTED] The RFC 2822 headers would then include: Sender: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Neither of which should be confused with the reverse-path provided to MAIL FROM. This seems roughly right from my quick reading of the RFCs. RFC 2633, section 3.1 says A MIME entity that is the whole message includes only the MIME headers and MIME body, and does not include the RFC-822 headers. A practical suggestion within the WG was that as a way to protect the headers the full 822 messsage is wrapped and protected in S/MIME. Then, outer headers for the S/MIME message are added that suffice for message delivery. This may be why most products of this nature are paired; at each end of the transfer are agents that employ S/MIME encoding, hiding it from an MUA. One benefit of doing this should be that we not only provide the server's warrant of trust in the sender's indentity, but can also certify that the message content has not changed since it left the server. But I haven't gone too deep into the details. S/MIME is pretty involved. If we're going add S/MIME support to James, I suggest that we get in touch with http://www.bouncycastle.org/, and ask them to help out. They have both code we can use (perfectly compatible license) and expertise in the domain. --- Noel ref: S/MIME Working Group http://www.ietf.org/html.charters/smime-charter.html RFC 2633 (S/MIME v3) http://www.ietf.org/rfc/rfc2633.txt Interet Mail Consortium on S/MIME: http://www.imc.org/smime-pgpmime.html RSA S/MIME FAQ: http://www.rsasecurity.com/standards/smime/faq.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From email address validation
Noel J. Bergman wrote: Guys, With respect to verifying that the sender is really the sender, there are two basic means. One is a digital signature, the other is MAIL FROM AUTH=, which is part of SMTP AUTH. In something of an ironic coincidence, I just heard back from Bill Shannon regarding JavaMail support for MAIL FROM AUTH=, and will CC the mailing list on my response. Yeah Noel, don't take this the wrong way, but I think cow's will fly before this approach. You've enumerated a string of unimplemented RFCs, libraries that don't support them, and have complex behavior that would be an inconvenience for non-adopters. Here are some thoughts about what is needed for trusted email approach (whatever form you're talking) needs to obey to take off: 1. Does not create multi-part content Developers and users alike would rather not deal with multipart content if they didn't have to. Not to mention CPUs and disk space. 2. Cannot rely on network effect You cannot necessitate getting a critical mass of users before it becomes useful. It needs to be useful to someone from the beginning and/or extremely trivial to add (gets into 3) 3. Simple enough for a Perl developer to hack together Whatever approach should be easy enough for a Perl developer to mimic. Probably others... those are just some I've seen from looking at what email add-ons have taken off. Here are some attempts with theories on why they failed: Message integrity is great, until you have to send an email from a company that attaches a disclaimer or you send to a mailing list that adds an advertisement or sign-off instructions. Client certs are great until you realize you need to support a person read/sending email from webmail as well as their desktop. Server call-backs would be great until you see how many servers would have to agree to this approach for it to be worth anything. Anyway, I have no idea who or how this is going to get figured out... hopefully as the VC market starts spending on IT again, a bunch of new untested ideas will get tested and we may get something that sticks for a change. Spam and identity theft can probably scare a lot more money out of a VCs wallets these days... -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: From email address validation
Serge wrote: With respect to verifying that the sender is really the sender, there are two basic means. One is a digital signature, the other is MAIL FROM AUTH=, which is part of SMTP AUTH. In something of an ironic coincidence, I just heard back from Bill Shannon regarding JavaMail support for MAIL FROM AUTH=, and will CC the mailing list on my response. Yeah Noel, don't take this the wrong way, but I think cow's will fly before this approach. You've enumerated a string of unimplemented RFCs, libraries that don't support them, and have complex behavior that would be an inconvenience for non-adopters. Are you referring to MAIL FROM AUTH= as the approach that would come in second to airborne bovines in an aerodynamics contest? It is implemented (albeit not by JavaMail), but it won't solve your general Internet desires, and I wasn't proposing it as the ultimate approach. Spam and identity theft can probably scare a lot more money out of a VCs wallets these days... It would be great to come up with something as elegantly simple as VERP for authentication. We would want broad support. I don't know anything broader than S/MIME. One thing that I have seen is that the first time you send me mail, my MTA will respond with an bounce message containing a unique URL. Using that URL you can install a public key for me. That public key is generated by me, and encoded for your e-mail address. I am a CA, but instead of providing you with your own private key, from your perspective the key is my public key. Most mailers make sending encrypted e-mail pretty easy. The key tells me which address had received the key, and is thus eligible to use it. Revocation and filtering are trivial, and handled by my MTA, requiring no assistance from my MUA. That is something we could build fairly readily. It does not handle mailing lists, nor would it work with most web-mail providers. It is strictly 1:1, and requires the sender to have an S/MIME capable MUA. The closest I have seen so far that would handle a mailing list are some of the TMDA techniques. On the other hand, you could expect a good list to be filtered, and filter messages purporting to come from a list based upon known servers for that list. Raining milk yet? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From email address validation
Noel J. Bergman wrote: We would want broad support. I don't know anything broader than S/MIME. I would differ with that, or at least put a spin on it... S/MIME is the John Malkovich of the email world... everyone has heard and has respect for it, but can you name a time you used it? That is something we could build fairly readily. It does not handle mailing lists, nor would it work with most web-mail providers. It is strictly 1:1, and requires the sender to have an S/MIME capable MUA. The closest I have seen so far that would handle a mailing list are some of the TMDA techniques. On the other hand, you could expect a good list to be filtered, and filter messages purporting to come from a list based upon known servers for that list. Raining milk yet? Let me know when you're ready to have an email address that you can't send to mailing lists or check via webmail. Then I'll put the cups outside to catch the milk. :) -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
