[jira] [Commented] (JSPF-55) Add helper classes for supporting SRS
[ https://issues.apache.org/jira/browse/JSPF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293937#comment-13293937 ] Hontvari Jozsef commented on JSPF-55: - I have implemented SRS in Mireka a while ago, maybe you can borrow the code. The public interface is not compatible with JAMES, because I am using Recipient, ReversePath etc. interfaces, specific to Mireka, but I guess these can be replaced without deep changes. The whole implementation is in a single top level class + four nested classes: http://code.google.com/p/mireka/source/browse/trunk/src/mireka/forward/Srs.java Add helper classes for supporting SRS - Key: JSPF-55 URL: https://issues.apache.org/jira/browse/JSPF-55 Project: JAMES jSPF Issue Type: New Feature Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 1.0.1 It whould be cool to add some helper classes for supporting SRS: http://www.openspf.org/SRS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-901) build error
[
https://issues.apache.org/jira/browse/JAMES-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707277#action_12707277
]
Hontvari Jozsef commented on JAMES-901:
---
I met the same problem 1-2 years ago and if I remember well I finally simply
removed this code (mordred).
See this thread:
http://markmail.org/message/doq7blvf2jjzjdzp#query:mordred%20hontvari%20james+page:1+mid:doq7blvf2jjzjdzp+state:results
build error
---
Key: JAMES-901
URL: https://issues.apache.org/jira/browse/JAMES-901
Project: JAMES Server
Issue Type: Bug
Components: Build System
Affects Versions: 2.3.1
Environment: winXP SP3, JDK1.6.0_07-b06
Reporter: Amichai Rothman
downloaded and extracted james-2.3.1-src.zip, and ran build.bat, and the
build failed with the error below:
C:\temp\james-2.3.1-src\src\java\org\apache\james\util\mordred\PoolConnEntry.java:37:
org.apache.james.util.mordred.PoolConnEntry is not abstract and does not
override abstract method createStruct(java.lang.String,java.lang.Object[]) in
java.sql.Connection
public class PoolConnEntry implements java.sql.Connection{
^
1 error
BUILD FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
compile 2.3.1
The current 2.3.1 cannot be compiled using ant compile-main, because mordred PoolConnEntry assumes a very old version of java.sql.Connection. Is this correct? compile-main: [javac] ...\src\java\org\apache\james\util\mordred\PoolConnEntry.java:37 : org.apache.james.util.mordred.PoolConnEntry is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Road Forward
Robert Burrell Donkin írta: 1. i know that quite a lot of the IMAP/mailbox stuff is junk (both mine code and the old stuff). IMAP/mailbox is most of trunk. so yes, a substantial quantity of code in trunk is junk. a more important issue is that it's difficult to gain consensus on the production quality of the remaining code on trunk or make rational judgments about what's basically sound but needs testing in production. i've only reviewed a small proportion and some looks ok, some looks questionable but i'm not enough of an expert to judge. 2. i want people to innovate on trunk rather than on their own branches. innovating on branches is harmful to the community since it's much harder to collaborate and entropy makes it difficult to merge changes into trunk. we need to allow new ideas and we need to allow it on trunk. IMHO modularisation is an inevitable consequence of this approach. noel prefers to see this process as allowing anyone to dump junk in trunk and i have no probably about that language but that's not the way i see things. - robert First of all, I don't want to take your time, so this will be my last post in this subject. I feel the workflow above would require development capacity which is rarely available in the James project. Somebody must have the authority and long term commitment to decide what can be used from the playing ground trunk and extract those and create a production quality version himself. Unfortunately, because it is a playing ground, nobody trusts in trunk. By consequence it is not used on many production like servers. Therefore nobody has reliable information about what is useable in trunk. Moreover, even committers don't develop against trunk, because they cannot use the result on their production machines. The function of this developer is more like a paying job and not like the ad-hoc volunteer work, which is avalible for James. Regarding modularized code, I had a glance at the trunk, it was nice and easy to understand. But if you have 20 smaller playing grounds instead of one larger playing ground that doesn't really help on the trust problem above. Actually, if the modules indeed start to be developed independently - but they will never be completely independent - then you get a new, difficult task: coordinate the release of 20 modules at the same time. It seems that while the goal was to avoid innovation in long-term branches, the current approach lead to the exactly opposite result: everybody has his own long-term custom build. I haven't seen any change which make the result different next time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Road Forward
Considering the low frequency of releases and the small number of new features, the version management structure of James seems to be an overkill. (Or maybe I just don't understand the system.) Although I don't think this is new for anybody here is the simplest procedure: The trunk receives all changes. It must always be in a useable state. Compatibility doesn't matter at all, you don't release more then once a year anyway now. Moreover James is a mature product, nobody is forced to upgrade. I am using the same custom version for about 3 years if not more. If there are enough features or a few months elapsed, release a beta version from the trunk. The beta can be put into a new branch if a serious bug is found. Leave it in beta for a few months, and if nobody reports serious bugs declare it stable. The version number should reflect the actual backward compatibility of the beta, there is no need to plan it in advance. Noel J. Bergman írta: After discussion of various technical and non-technical things at ApacheCon by Robert, Bernd, Norman and myself, here's a road forward. When I get a moment (right now, I am in the planning meeting for ApacheCon US New Orleans), I am going to branch from v2.3.1. I am going to re-review the diff between v2.3.0 and v2.3.1, and welcome others to do the same. It is not that I don't want some of the code from trunk, but this is just part of the process. The production branch is not necessarily intended to be config.xml and DB-format compatible with v2.x. The purpose is to start from a production stable codebase, and maintain a production stable code base, while incrementally incorporating stable parts pulled from and shared with trunk, or developed in a temporary sandbox. As another part of the process, Robert is going to work on refactoring and splitting from trunk. To illustrate the overall process, one of the things that Robert is going to do is pull out all of the portable Matchers and Mailets into a separate releasable. Once that's clean, we compare them against the same set in the production branch, and after approving, we delete them from the production branch, and reference the new package. Trunk will also share that same releasable, so in that manner, we will effectively merge production and trunk incrementally over time. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-52) 8bitmime capabilities missing
[ http://issues.apache.org/jira/browse/JAMES-52?page=comments#action_12313376 ] Hontvari Jozsef commented on JAMES-52: -- I think this is simply a bug in IIS. If IIS supports 8bitmime then it must be able to forward (and convert) it to non-8bitmime mail servers. If it can't convert it to 7-bit, then it doesn't really support 8bitmime even if it falsely announce support. The same is true for James, it is not enough to announce accepting 8bitmime, James must also be able to convert it to 7 bit for other servers if it is necessary. 8bitmime capabilities missing - Key: JAMES-52 URL: http://issues.apache.org/jira/browse/JAMES-52 Project: James Type: Improvement Components: SMTPServer Versions: 2.0a3, 2.1.3, 2.2.0 Environment: Operating System: All Platform: All Reporter: brady moritz I am using an IIS front end server which forwards email to the james backend server. The front server accepts 8bitmime messages but then cannot forward them to the james server, resulting in an error message being sent to the admininstrator(me). It should be a simple matter to add support for 8 bit and it may even be supported intrinsicly, but the james server does nont advertise it via the EHLO commannd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short term, but immediate, solution to spam volume.
I forgot to mention: It doesn't check for abuse@, only postmaster@ and
the email address used in the error message is hard coded.
Hontvari Jozsef wrote:
Maybe it helps, I have attached the source which we use for about a
year. I cannot create a standard patch because my last workspace is
based on the now non-existent cvs repository.
The code must be inserted before these lines into the SMTPHandler.java
file:
if (authRequired) {
// Make sure the mail is being sent locally if not
// authenticated else reject.
Noel J. Bergman wrote:
Do to the incredibly high volume generated by Microsoft Windows
spambots, I
feel that we need to allow somewhat more aggressive measures in the near
term, as in *NOW*.
I propose an interm measure to add support for a DNSRBL in the SMTP
handler,
which will set a flag such that RCPT TO will fail except for postmaster
(RFC2821) and abuse (RFC2142). Once a single message to has been
accepted
for that connection, we might even terminate the connection.
This would not be a permanent measure, and would be replaced when we add
more flexible fast-fail, but it would provide relief today from the
spambots.
Thoughts?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
// black list check HJ
// don't check if the user is authenticated or if he is sending to
// postmaster
if (getUser() == null
!recipientAddress.getUser()
.equalsIgnoreCase(postmaster)) {
String host = remoteIP;
//Have to reverse the octets first
StringBuffer sb = new StringBuffer();
StringTokenizer st = new StringTokenizer(host, ., false);
while (st.hasMoreTokens()) {
sb.insert(0, st.nextToken() + .);
}
String reversedOctets = sb.toString();
String blackListMessage = null;
try {
//Try to look it up
InetAddress.getByName(
reversedOctets + combined.njabl.org);
//If we got here, that's bad... it means the host
// was found in the blacklist
//blackListMessage = Dynamic/Residential IP range listed by
NJABL dynablock - http://njabl.org/dynablock.html;;
blackListMessage = combined.njabl.org BLACKLIST;
} catch (UnknownHostException uhe) {
//This is good... it's not on the list
}
if (blackListMessage != null) {
responseString = 550 Rejected: contact [EMAIL PROTECTED] for
details;
writeLoggedFlushedResponse(responseString);
getLogger().error(Message rejected - + blackListMessage);
return;
}
try {
//Try to look it up
InetAddress.getByName(
reversedOctets + sbl-xbl.spamhaus.org);
//If we got here, that's bad... it means the host
// was found in the blacklist
blackListMessage = Spamhaus BLACKLIST;
} catch (UnknownHostException uhe) {
//This is good... it's not on the list
}
if (blackListMessage != null) {
responseString = 550 Rejected: contact [EMAIL PROTECTED] for
details;
writeLoggedFlushedResponse(responseString);
getLogger().error(Message rejected - + blackListMessage);
return;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POJO pattern
the merging process, which took almost 2 years (until now) will kill James, if it hasn't killed it already. Nobody knows which is the real head branch, etc. It would be better if you rename 2.1(?), which is the production version (almost), and officially abandon the current head. If somebody wants something from the head he can create a new patch. But this assumes that there is somebody who knows what is in the head and have time for the project, and I guess there is no such person. There is nothing to lose, we don't use anything from the head anyway. - Original Message - From: [EMAIL PROTECTED] To: 'James Developers List' server-dev@james.apache.org Sent: Monday, April 11, 2005 3:33 PM Subject: Re: [VOTE] POJO pattern For example: SMTPHandler - CDISMTPHandler - SpringSMTPHandler - JCASMTPHandler - AvalonSMTPHandler Please indicate your prefrence: [ ] +1 I agree that Agnostic SDI style POJO's are an effective first step and will participate in the development work The first step would be to remove Phoenix specific stuff and replace it with Avalon stuff. I don't understand wether we should wait for the merge (Noel?) or the POJOification can start anyway (AFAIK: 2_1_fcs is the branch having more features and more tested while trunk is the branch with Services instead of deprecated Components) Probably the bigger difference between trunk and 2_1_fcs would be moved in the AvalonComponentName specific classes so the POJOification work would also simplify the merging operations, isn't it? Noel, can you, please, reply to this email I sent a few days ago in the branch differences? - Intentional differences: - trunk has a released and updated version of Phoenix, which meant changes to lifecycle interfaces. Will the new version run under Loom? - trunk has some experimental changes that won't be kept. What changes will not be kept? I've seen there is a lot of code change to move from avalon Components (Deprecated) to avalon Services: will this be kept? I see there are still 3 references to avalon components: core/AvalonMailStore, core/AvalonUserStore, mailrepository/filepair/RepositoryManager. - Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Build posted - JAMES-264 mail loop
If someone would try to use the email list mailets with non-local users then he will very soon change his mind because of the catastrophic JAMES-264 UNRESOLVED mail list loop caused by using Return-Path bug. In the description of the issue I included a quick fix, which consists of about 5 lines. It is in my James version for about half a year and it is working. As I wrote in the referenced email I didn't make a patch, because I couldn't follow the status of the different James versions in the CVS, but inserting these lines is quite easy. If this issue will be closed maybe a new one with lower priority should be opened, because the root of the problem, the usage of Return-Path header will still be in the code, the fix is just a workaround for a specific problem. - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James-Dev Mailing List [EMAIL PROTECTED] Sent: Sunday, August 15, 2004 1:50 AM Subject: Test Build posted Guys, I've posted a test build. It has in it everything that has been committed since JAMES 2.2.0, which means: http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10411report=road map. Please take a look (http://cvs.apache.org/dist/james/). Anything else we want to do before I put together an RC? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Build posted - JAMES-264 mail loop
There are is reference to an email in the first (and also in the last) sentence of the description, that email includes both the fix and the analysis, which may answer your question. Related email thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=11183 - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Monday, August 16, 2004 1:33 AM Subject: RE: Test Build posted - JAMES-264 mail loop If someone would try to use the email list mailets with non-local users then he will very soon change his mind because of the catastrophic JAMES-264 UNRESOLVED mail list loop caused by using Return-Path bug. I use the listserv without any such catastrophic problems, or any loops at all. Curious as to how you are handling bounces that you do. In the description of the issue I included a quick fix, which consists of about 5 lines. There is no such fix in http://issues.apache.org/jira/browse/JAMES-264. I do have a separate patch you wrote for GenericListserv, which I'm looking at now. If this issue will be closed maybe a new one with lower priority should be opened, because the root of the problem, the usage of Return-Path header will still be in the code, the fix is just a workaround for a specific problem. That is what I've been looking at today. It is a riskier change to make on a point release, but might be worthwhile. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
InaccurateTimeoutWatchdog
It seems to me that this line is not correct:
if (timeToSleep 0) {
I think it should be =. Otherwise if timeToSleep is (accidentally) 0, the
following wait() will wait undefinitely, according to its specification.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 8BITMIME support
I was thinking about this too, I guess most of the work comes from the requirement, that if you accept 8bitmime, then you have to be able to convert it to 7bit, because a recipient server may not support 8bitmime. - Original Message - From: Craig Raw [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 20, 2004 10:51 AM Subject: 8BITMIME support Hi, I am curious as to the status of james supporting ESMTP 8BITMIME. Following a discussion on the mailing list 2 years back, a bug was filed under http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JAMES-52 noting that 8BITMIME was not supported (and therefore correctly not advertised in response to EHLO). I am curious because I have found no problems with 8bit messages passing through my James 2.20a15, which is running on a Linux box with a default character set of ASCII. I am using db repositories in all cases. Is the problem something like support in file repositories, or perhaps something more fundamental? Thanks, Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery multiple delay times
I am not against this patch, actually this was one of the most important missing features for me. The current configuration is better in one (and only one) issue, it does provide feedback after about a day to the sender. I have no idea about the implementation of DSN, but sending bounces to a processos with some mail attributes was a nice idea, I don't remember who wrote it. I would be happy if RemoteDelivery doesn't bounce back to the _from_ address, instead of the reverse path. If I have a few hours I will fix this. - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 8:58 PM Subject: RE: [PATCH] RemoteDelivery multiple delay times I think it causes more trouble then benefit if it delays a mail for not less then 5 days _without_ notifying the sender after 24 hours, saying that I am James, your email is delayed, but I am still trying to deliver. I understand your thought about DSN (something still pending to be done), but how does the current state differ from what we'll have after merging this change? As it currently stands, James will iterate for a certain number of times, delaying 6 hours between. RemoteDelivery is an area with room for enhancement in many ways. DSN is one of them. Do you have any ideas for how you would like the problem of sending a DSN within the delivery process addressed? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery multiple delay times
(on bounces I also mean failed attempts, before the configured retry attemps ended, this event could be used for such a notification) - Original Message - From: Hontvari Jozsef [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 9:43 PM Subject: Re: [PATCH] RemoteDelivery multiple delay times I am not against this patch, actually this was one of the most important missing features for me. The current configuration is better in one (and only one) issue, it does provide feedback after about a day to the sender. I have no idea about the implementation of DSN, but sending bounces to a processos with some mail attributes was a nice idea, I don't remember who wrote it. I would be happy if RemoteDelivery doesn't bounce back to the _from_ address, instead of the reverse path. If I have a few hours I will fix this. - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 8:58 PM Subject: RE: [PATCH] RemoteDelivery multiple delay times I think it causes more trouble then benefit if it delays a mail for not less then 5 days _without_ notifying the sender after 24 hours, saying that I am James, your email is delayed, but I am still trying to deliver. I understand your thought about DSN (something still pending to be done), but how does the current state differ from what we'll have after merging this change? As it currently stands, James will iterate for a certain number of times, delaying 6 hours between. RemoteDelivery is an area with room for enhancement in many ways. DSN is one of them. Do you have any ideas for how you would like the problem of sending a DSN within the delivery process addressed? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] GenericListServ, reversePath can be specified
This is a small patch which makes possible to specify a reversePath in descendant classes. Until now postmaster was used always and the bounces got on my nerves :) It is against the 2.1 branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] GenericListServ, reversePath can be specified
Now again in zip. - Original Message - From: Hontvari Jozsef [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 10:38 PM Subject: [PATCH] GenericListServ, reversePath can be specified This is a small patch which makes possible to specify a reversePath in descendant classes. Until now postmaster was used always and the bounces got on my nerves :) It is against the 2.1 branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] GenericListserv4.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
default log configuration
James has about 10 log files now, and I usually have no idea in which one should I look for a specific entry - even after using james for a few moths and having some practice with the source code. The mail software I used before only had one log file, and I found that better. Finally I changed James config to use only one log file. Likely people starting to use james have the same problem, so I'd propose to change the default configuration in this way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
