You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Sozonoff <se...@globalbeach.com> on 2002/10/20 20:25:13 UTC
phoenix-bin\bin\phoenix.sh in crlf
Hi All,
It seem that the phoenix.sh script is checked in with crlf end-of-lines
instead of lf so it won't run out-of-the-box on unix like it should.
Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: phoenix-bin\bin\phoenix.sh in crlf
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
Interesting. This was recently noted on the IMAP build. I suspect this
happened with the Phoenix 4.0 release upgrade. I'll fix it, as well as
adding an appropriate entry into build.xml to ensure it remains LF.
--Peter
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: Sunday, October 20, 2002 11:25 AM
> To: James Developers List
> Subject: phoenix-bin\bin\phoenix.sh in crlf
>
> Hi All,
>
> It seem that the phoenix.sh script is checked in with crlf
end-of-lines
> instead of lf so it won't run out-of-the-box on unix like it should.
>
> Serge
>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: phoenix-bin\bin\phoenix.sh in crlf
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
Didn't see the CRLF problem, but I did see an issue with phoenix.sh not
being set to executable. I changed the build so it forces the file to
LF and I added a line to make phoenix.sh executable.
--Peter
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: Sunday, October 20, 2002 11:25 AM
> To: James Developers List
> Subject: phoenix-bin\bin\phoenix.sh in crlf
>
> Hi All,
>
> It seem that the phoenix.sh script is checked in with crlf
end-of-lines
> instead of lf so it won't run out-of-the-box on unix like it should.
>
> Serge
>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal .. error messages
Posted by Serge Knystautas <se...@lokitech.com>.
I think that might be useful as an attachment, but really needs to be
buried. From my experience, most users won't read past the second
paragraph in the email (if that), so this would be useful only to the
admin who the bounce gets forwarded to.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Danny Angus wrote:
> I'd like to see what everyone thinks of this idea..
> to construct more meaningful error trails for bounce and other failed messages we should append lines to the error message of a Mail, rather than replace the message with a new one, so an error might end up reading..
>
> "sent for transport
> attempt failed because '400 service unavailable'
> retrying 1
> attempt failed because '400 service unavailable'
> given up after 2 trys"
>
>
> I did this to a version I was hacking, but never got round to comitting it.
> is it a good idea, or is there a good reason not to do this?
>
> d.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal .. error messages
Posted by Danny Angus <da...@apache.org>.
> Were your messages in short hand, or did you mean them literally?
literally, I get messages like that from time to time from other MTA's
> If you do
> it, wouldn't it make sense to add the timestamp for each attempt? What
> about the mail server(s) tried, e.g., for a service like Hotmail,
> which has
> multiple servers?
hostnames would appear where relevant.
timestamp is a nice idea, james' usp ;-)
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal .. error messages
Posted by "Noel J. Bergman" <no...@devtech.com>.
I'm ambivalent. Maybe because I don't tend to get bounces like that from
other mail servers. Generally, when there is a transient error I would one
that says there is a temporary failure, and if it didn't clear up within a
week or so, I'd get one saying that it still couldn't deliver the e-mail, so
it was giving up. I don't recall getting a log of each attempt. The more I
think about it, the more I think it might be nice.
Were your messages in short hand, or did you mean them literally? If you do
it, wouldn't it make sense to add the timestamp for each attempt? What
about the mail server(s) tried, e.g., for a service like Hotmail, which has
multiple servers?
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Monday, October 21, 2002 6:41
To: James Developers List
Subject: Proposal .. error messages
I'd like to see what everyone thinks of this idea..
to construct more meaningful error trails for bounce and other failed
messages we should append lines to the error message of a Mail, rather than
replace the message with a new one, so an error might end up reading..
"sent for transport
attempt failed because '400 service unavailable'
retrying 1
attempt failed because '400 service unavailable'
given up after 2 trys"
I did this to a version I was hacking, but never got round to comitting it.
is it a good idea, or is there a good reason not to do this?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal .. error messages
Posted by Danny Angus <da...@apache.org>.
> I do think such a feature would be useful, although I'm far more
> interested in seeing the bounce logic being un-hard coded from the
> server.
Yeah me too.
> IMHO, a bounce should result in a mail being directed to
> another processor, allowing full custom handling of the bounce
> condition. This would allow the logic you propose to be implemented as
> a mailet. As long as the bounce behavior is flexible, either the
> behavior you specify or the current behavior could be valuable,
> depending on the needs and desires of the administrator. Personally,
> I'd like to see our bounce handling in general discussed in the rev++
> discussion.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal .. error messages
Posted by "Noel J. Bergman" <no...@devtech.com>.
> interested in seeing the bounce logic being un-hard coded from the
> server
Agreed. There is some prior discussion of this in the archives, and it
would be a good v3 discussion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Proposal .. error messages
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
I do think such a feature would be useful, although I'm far more
interested in seeing the bounce logic being un-hard coded from the
server. IMHO, a bounce should result in a mail being directed to
another processor, allowing full custom handling of the bounce
condition. This would allow the logic you propose to be implemented as
a mailet. As long as the bounce behavior is flexible, either the
behavior you specify or the current behavior could be valuable,
depending on the needs and desires of the administrator. Personally,
I'd like to see our bounce handling in general discussed in the rev++
discussion.
--Peter
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Monday, October 21, 2002 3:41 AM
> To: James Developers List
> Subject: Proposal .. error messages
>
> I'd like to see what everyone thinks of this idea..
> to construct more meaningful error trails for bounce and other failed
> messages we should append lines to the error message of a Mail, rather
> than replace the message with a new one, so an error might end up
> reading..
>
> "sent for transport
> attempt failed because '400 service unavailable'
> retrying 1
> attempt failed because '400 service unavailable'
> given up after 2 trys"
>
>
> I did this to a version I was hacking, but never got round to
comitting
> it.
> is it a good idea, or is there a good reason not to do this?
>
> d.
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Proposal .. error messages
Posted by Danny Angus <da...@apache.org>.
I'd like to see what everyone thinks of this idea..
to construct more meaningful error trails for bounce and other failed messages we should append lines to the error message of a Mail, rather than replace the message with a new one, so an error might end up reading..
"sent for transport
attempt failed because '400 service unavailable'
retrying 1
attempt failed because '400 service unavailable'
given up after 2 trys"
I did this to a version I was hacking, but never got round to comitting it.
is it a good idea, or is there a good reason not to do this?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: phoenix-bin\bin\phoenix.sh in crlf
Posted by Danny Angus <da...@apache.org>.
I think it is the permission on the file that is not being stored correctly in cvs, as its r--r--r-- I've had to ask root to chmod it to r-xr-xr-x
d.
> -----Original Message-----
> From: Serge Sozonoff [mailto:serge@globalbeach.com]
> Sent: 20 October 2002 19:25
> To: James Developers List
> Subject: phoenix-bin\bin\phoenix.sh in crlf
>
>
> Hi All,
>
> It seem that the phoenix.sh script is checked in with crlf end-of-lines
> instead of lf so it won't run out-of-the-box on unix like it should.
>
> Serge
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>