[
https://issues.apache.org/jira/browse/JAMES-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-632.
Resolution: Won't Fix
> RFCs for SMIME and Open
MAILET-144 Use the same certificate in all SMIME tests (end of validity in 2044)
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/bc0d0a30
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree
Repository: james-project
Updated Branches:
refs/heads/master b3a30c1e5 -> 17c79db46
JAMES-1856 Write integration tests for SMIME Sign
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/17c79db4
Tree: h
Hi,
If the header is in the smime message (see
http://www.ietf.org/rfc/rfc3851.txt), and is not a regular mail header,
there is no way for the mailet to read it (unless the mailet has acess
to the recipient certificate, but you don't want this I guess).
Thx, Eric
On 21/03/2013 15:51
webmail
client to distinguish whether the user is using the webmail client or
something like microsoft outlook.
I have written my custom mailet which is working fine and can get
value for Client-Type header for normal message(IMF). This is failing
when the message comes in as SMIME. How can I read
for Client-Type header for normal message(IMF). This is failing
when the message comes in as SMIME. How can I read this customer
header from the SMIME message?
Appreciate your help.
Thank you,
Regards,
Rajender
in as SMIME. How can I read this customer
header from the SMIME message?
Appreciate your help.
Thank you,
Regards,
Rajender
--**--**
-
To unsubscribe, e-mail:
server-dev-unsubscribe@james.**apache.orgserver-dev-unsubscr...@james.apache.org
for Client-Type header for normal message(IMF). This is failing
when the message comes in as SMIME. How can I read this customer
header from the SMIME message?
Appreciate your help.
Thank you,
Regards,
Rajender
-
To unsubscribe, e
/mailets/smime/AbstractSign.java
james/mailet/crypto/trunk/src/main/java/org/apache/james/mailet/crypto/mailet/SMIMECheckSignature.java
(contents, props changed)
- copied, changed from r721861,
james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/mailets/smime
-mailet-base-1.0-SNAPSHOT.jar
Modified:
james/mailet/crypto/trunk/include.properties
james/mailet/crypto/trunk/pom.xml
james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/mailets/smime/AbstractSign.java
james/mailet/crypto/trunk/src/main/java/org/apache/james/transport
/MailetLoaderTestMailet.java
james/server/trunk/spoolmanager-function/src/test/java/org/apache/james/transport/mailets/smime/
james/server/trunk/spoolmanager-function/src/test/java/org/apache/james/transport/mailets/smime/MailetLoaderTestSMIMEMailet.java
(contents, props changed)
- copied
/apache/james/test/util/
james/server/trunk/phoenix-deployment/src/test/org/apache/james/transport/mailets/smime/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Author: rdonkin
Date: Thu Apr 24 23:32:10 2008
New Revision: 651501
URL: http://svn.apache.org/viewvc?rev=651501view=rev
Log:
SMIME has been moved to crypto-mailets
Removed:
james/server/trunk/spoolmanager-function/src/main/java/org/apache/james/transport/mailets/smime
/trunk/src/main/java/org/apache/james/transport/matchers/SenderInFakeDomain.java
james/mailet/standard/trunk/src/main/java/org/apache/james/transport/matchers/SenderIsRegex.java
james/mailet/standard/trunk/src/main/java/org/apache/james/transport/matchers/smime/
Modified:
james/mailet
Author: rdonkin
Date: Thu Apr 24 14:41:57 2008
New Revision: 651434
URL: http://svn.apache.org/viewvc?rev=651434view=rev
Log:
Move over cryptography mailets
Added:
james/mailet/crypto/trunk/src/main/java/org/apache/james/transport/matchers/smime/
- copied from r651433,
james/server
my work on the OpenPGP/SMIME implementation has stalled and i'm not
sure when i'll be able to find the three or fours dedicated days i
need to finish it off. i was wondering whether it would be a good idea
for me to take a branch so that the code is in version control (rather
than on my hard disc
Just go ahead and create a sandbox.. Even if it will get out of sync
soon with current trunk .
bye
Norman
robert burrell donkin schrieb:
my work on the OpenPGP/SMIME implementation has stalled and i'm not
sure when i'll be able to find the three or fours dedicated days i
need to finish it off
+1
On 1/8/07, robert burrell donkin [EMAIL PROTECTED] wrote:
my work on the OpenPGP/SMIME implementation has stalled and i'm not
sure when i'll be able to find the three or fours dedicated days i
need to finish it off. i was wondering whether it would be a good idea
for me to take a branch so
robert burrell donkin wrote:
my work on the OpenPGP/SMIME implementation has stalled and i'm not
sure when i'll be able to find the three or fours dedicated days i
need to finish it off. i was wondering whether it would be a good idea
for me to take a branch so that the code is in version
[
http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437191 ]
Robert Burrell Donkin commented on JAMES-596:
-
JAMES-525 also covers OpenPGP
Reorganize SMIME crypto support code to share it with future new PGP
and with implementations on some older clients (such outlook).
This approach has many significant differences from SMIME.
RFC 3156 OpenPGP/MIME describes a cleaner, modern approach using MIME. It
builds on the work done using certificates using SMIME and is congruent with
it.
I propose to add only RFC
appropriate DataContentHandler implementations for the
necessary (pgp-*) MIME types. I also assume that the right way to do this in
JAMES is to add the implementation classes to src/meta-inf/mailcap. Let me know
if any of these assumptions are wide of the mark.
Reorganize SMIME crypto support code
() I would return a nice toString of the PGP
key, and why not a string like [EMAIL PROTECTED], CN=The Primary Name,
consistent with the string returned by
X509Certificate.getSubjectDN().toString()?
Reorganize SMIME crypto support code to share it with future new PGP support
code
judgement; but what is the client support for it? The Classic
inline PGP is always available to anyone having PGP or GPG installed, so isn't
it a pity to miss its support?
Reorganize SMIME crypto support code to share it with future new PGP support
code
; perhaps someone else of the committers can. Post the
question to server-dev.
Reorganize SMIME crypto support code to share it with future new PGP support
code
-
Key: JAMES-596
/MIME fits well into the design structure in JAMES created for SMIME.
Classic inline PGP is too different and would benefit from a different design.
2 Good support for older PGP versions requires full parsing of every part of
every message part. The presence of an OpenPGP/MIME signature can
RFCs for SMIME and OpenPGP
--
Key: JAMES-632
URL: http://issues.apache.org/jira/browse/JAMES-632
Project: James
Issue Type: Improvement
Components: Documentation
Affects Versions: Trunk
[ http://issues.apache.org/jira/browse/JAMES-632?page=all ]
Robert Burrell Donkin updated JAMES-632:
Attachment: james-rfcs.patch
RFCs related to OpenPGP and SMIME
RFCs for SMIME and OpenPGP
--
Key
getSignerCN();
which have no obvious analogues in OpenPGP. These do not seem to be used very
often.
Reorganize SMIME crypto support code to share it with future new PGP support
code
-
Key: JAMES-596
/security/SMIMEKeyHolder.java
james/server/trunk/src/java/org/apache/james/transport/mailets/smime/SMIMESign.java
james/server/trunk/src/site/xdoc/provided_mailets_2_3.xml
Modified: james/server/trunk/src/java/org/apache/james/security/KeyHolder.java
URL:
http://svn.apache.org/viewvc/james
The reorganization of the SMIME crypto code for future new PGP support
is a different issue than the new features you are coming out with,
though may be considered a preliminary step.
Noel J. Bergman wrote:
Vincenzo,
To reiterate from previous postings, here are some use cases that I would
Vincenzo,
To reiterate from previous postings, here are some use cases that I would
really like to see:
1) Accept e-mail that is properly signed.
We would want to be able to distinguish between properly signed, which
we could accept for local delivery, and properly signed by
Reorganize SMIME crypto support code to share it with future new PGP support
code
-
Key: JAMES-596
URL: http://issues.apache.org/jira/browse/JAMES-596
Project: James
/smime/SMIMECheckSignature.java
(props changed)
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/smime/SMIMEDecrypt.java
(props changed)
james/server/branches/v2.3/src/java/org/apache/james/transport/matchers/IsInWhiteList.java
(props changed)
james/server
/mailets/DSNBounce.java
james/server/trunk/src/java/org/apache/james/transport/mailets/smime/SMIMEAbstractSign.java
james/server/trunk/src/java/org/apache/mailet/GenericMailet.java
Modified:
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractRedirect.java
URL:
http
] wrote:
Cryptography libraries have redistribution limit in some contry.
Stefano
Norman Maurer wrote:
Hi guys,
after configure james i notice that we need to manualy download the
bouncycastle JCE for using SMIME.. Why we not include it .. Isn'T it a
standard BSD License ?
http
Hi guys,
after configure james i notice that we need to manualy download the
bouncycastle JCE for using SMIME.. Why we not include it .. Isn'T it a
standard BSD License ?
http://www.bouncycastle.org/licence.html
bye
Norman
signature.asc
Description: Dies ist ein digital signierter
Cryptography libraries have redistribution limit in some contry.
Stefano
Norman Maurer wrote:
Hi guys,
after configure james i notice that we need to manualy download the
bouncycastle JCE for using SMIME.. Why we not include it .. Isn'T it a
standard BSD License ?
http://www.bouncycastle.org
SMIME.. Why we not include it .. Isn'T it a
standard BSD License ?
http://www.bouncycastle.org/licence.html
bye
Norman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Author: bago
Date: Fri Aug 12 01:01:09 2005
New Revision: 232229
URL: http://svn.apache.org/viewcvs?rev=232229view=rev
Log:
Moved SMIMESign and its Abstract to the new smime subpackages (JAMES-400).
Also updated ASF copyright to 2005 and cleaned imports.
Added:
james/server/trunk/src/java
Add SMIME mailets for signature verification and message decrypt
Key: JAMES-398
URL: http://issues.apache.org/jira/browse/JAMES-398
Project: James
Type: Improvement
Components: Mailet API
Author: bago
Date: Thu Aug 11 11:19:45 2005
New Revision: 231496
URL: http://svn.apache.org/viewcvs?rev=231496view=rev
Log:
Upgraded Bouncycastle to 129 and java 1.4+ only (no more java 1.3 compatible)
(JAMES-399)
Added SMIME mailets for signature verification and message decrypt (JAMES-398
Author: bago
Date: Thu Aug 11 11:19:52 2005
New Revision: 231497
URL: http://svn.apache.org/viewcvs?rev=231497view=rev
Log:
Upgraded Bouncycastle to 129 and java 1.4+ only (no more java 1.3 compatible)
(JAMES-399)
Added SMIME mailets for signature verification and message decrypt (JAMES-398
Move previous SMIME matcher/mailets to the new smime subpackages
--
Key: JAMES-400
URL: http://issues.apache.org/jira/browse/JAMES-400
Project: James
Type: Improvement
Components: Matchers/Mailets
[ http://issues.apache.org/jira/browse/JAMES-398?page=all ]
Stefano Bagnara resolved JAMES-398:
---
Resolution: Fixed
Should works now with PKS12 and JKS keystores
Add SMIME mailets for signature verification and message decrypt
[ http://issues.apache.org/jira/browse/JAMES-400?page=all ]
Stefano Bagnara updated JAMES-400:
--
type: Task (was: Improvement)
Move previous SMIME matcher/mailets to the new smime subpackages
- Original Message -
From: Stefano Bagnara (JIRA) server-dev@james.apache.org
To: server-dev@james.apache.org
Sent: Thursday, August 11, 2005 8:31 PM
Subject: [jira] Resolved: (JAMES-398) Add SMIME mailets for signature
verification and message decrypt
[ http
I think we've encountered the same problems already found by Vincenzo in
trying to make smime mailets java 1.3 compatible.
If I understand correctly we can create a similar source file for java 1.4
and java 1.3 but not equal!. We can use for sure the java 1.3 version with
newer VM
Noel J. Bergman wrote:
Let's do another survey of server-user, and see if there is
still any need
for JDK 1.3 support. I'd love to be able to move forward.
Beat me to it!
As I remember, the last time we did this the major drawback was that some
were wedded to 1.3 as their primary solutions
On Wednesday 10 August 2005 23:08, Noel J. Bergman wrote:
Let's do another survey of server-user, and see if there is still any need
for JDK 1.3 support. I'd love to be able to move forward.
Hi all.
I was looking into the James source to see what whould be needed to add IPv6
support (will
and SMIME
Noel J. Bergman wrote:
Let's do another survey of server-user, and see if there is
still any
need for JDK 1.3 support. I'd love to be able to move forward.
Beat me to it!
As I remember, the last time we did this the major drawback
was that some were wedded to 1.3
/mailets are not yet in production because we need to do more
tests.
If you agree I will commit them later in august.
Should I add them to the current mailets/matchers packages or create a new
subpackage smime?
Stefano
smime?
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED
mailets/matchers packages or
create a new
subpackage smime?
IMHO, creating subpackages of .mailet, .matcher and .utils for functional
areas, such as SMIME is a good idea.
config.xml will need updating to include the subpackages in
mailetpackages/ and matcherpackages/. Better to have them
54 matches
Mail list logo
