RE: mail list loop, reverse path <-> Return-Path header
Generally speaking, you are correct. I'm not sure why parts of the code depend upon the Return-Path Header. Possibly some author in the distant past did not understand, and the effect has been propogated, even to new places as code was copied. It has been on my list of things to cleanup. Please feel free to file a bug report on it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mail list loop, reverse path <-> Return-Path header
I had some difficulty with the way James handles Return-Path headers,
while developing my mail service which borrows much code from James
but which also has significant architectural changes.
As Hontvari reports, the SMTPHandler in the version of James with
which I started (about 18-24 months ago) added a return-path header to
each message which came in. At first I copied that. Then I was
incorrectly forwarding SMTP messages with the Return-path header still
in place. Now my code adds a Return-path header only when it places a
message in a POP3 mailbox.
The James MailImpl class seems to keep the return path, since it has
the method getSender(). With the return path thus accessible in
James, addition of a Return-Path header might be moved to those places
where the message is leaving the SMTP environment.
Hope this helps,
Rich Hammer
mailscreen.net
Hontvari Jozsef wrote:
(I am not sure what is the status of the merge, so I don't send a patch now,
and anyway, you may not agree on my evaluation)
org.apache.james.James class has a bounce method, which is intended to be
used for bouncing invalid emails to the reverse path (i.e. the email address
supplied in the SMTP MAIL FROM command). RemoteDelivery mailet does use this
method.
This method tries to determine the reverse path from the Return-Path header
(which is stored _within_ the email) instead of using the reverse path
stored along the email in the Mail class. According to the mail RFCs, the
Return-Path header is not indeded to be used by an smtp service, it should
only be used when final delivery occurs, e.g. when storing the mail in a
mailstore used by a pop service. I consider this as a hack, and really don't
like it in James, but because the James smtp handler always inserts the
Return-Path header it seems to be working.
However, the GenericListserv mailet removes the Return-Path header. I think
that is quote correct, on the other hand it breaks the above, not so correct
assumption about the Reverse-Path header. The bounce method in these cases
defaults to the Reply-To, i.e the mail list itself, so you get a mail loop
involving as many people as you have on the list... It happened to me
several times.
In my oppininon the correct solution would be to enirely remove the
dependency on the Return-Path header, but I don't have enough time and
understanding of James. So I only implemented a fallback specifically for
the case when the Return-Path header is not present, which eliminates this
type of loop in my case:
I replaced the
getLogger().warn("Mail to be bounced does not contain a
Return-Path header.");
line with this code:
MailAddress reversePath = mail.getSender();
if (reversePath == null) {
getLogger().warn("Mail to be bounced does not contain a
Return-Path header and reverse path is null too, sending to postmaster.");
reply.setRecipient(MimeMessage.RecipientType.TO,
getPostmaster().toInternetAddress());
} else {
getLogger().warn("Mail to be bounced does not contain a " +
"Return-Path header although expected (wrongly!), "
+
"reverse path used (it should be used always): " +
reversePath.toString());
reply.setRecipient(MimeMessage.RecipientType.TO,
reversePath.toInternetAddress());
}
(I copied this code directly from my source, maybe the log message isn't
suitable for a release)
-
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] Created: (JAMES-240) LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/JAMES-240 Here is an overview of the issue: - Key: JAMES-240 Summary: LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException Type: Bug Status: Unassigned Priority: Major Project: James Components: SpoolManager & Processors Versions: 2.2.0a17 Assignee: Reporter: Angel Angelov Created: Wed, 31 Mar 2004 7:19 AM Updated: Wed, 31 Mar 2004 7:19 AM Description: From: "Noel J. Bergman" <[EMAIL PROTECTED]> Save Address To: "James Users List" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> CC: Date: Wed, 31 Mar 2004 09:32:20 -0500 Subject: RE: using MailetContext.sendMail > java.lang.ClassCastException > at org.apache.mailet.GenericRecipientMatcher.match(GenericRecipientMatcher.java :89) 89 MailAddress rec = (MailAddress) i.next(); Looks like something was put into the Collection that doesn't belong there. This is later confirmed by: > java.lang.ArrayStoreException > at java.lang.System.arraycopy(Native Method) > at java.util.ArrayList.toArray(ArrayList.java:305) > at org.apache.james.transport.LinearProcessor.verifyMailAddresses(LinearProcess or.java:515) 515 MailAddress addresses[] = (MailAddress[])col.toArray(new MailAddress[0]); Please submit a JIRA issue that .LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException The purpose of that method is to verify the contents of the Collection, and it should not leak the exception. --- Noel - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mail list loop, reverse path <-> Return-Path header
(I am not sure what is the status of the merge, so I don't send a patch now,
and anyway, you may not agree on my evaluation)
org.apache.james.James class has a bounce method, which is intended to be
used for bouncing invalid emails to the reverse path (i.e. the email address
supplied in the SMTP MAIL FROM command). RemoteDelivery mailet does use this
method.
This method tries to determine the reverse path from the Return-Path header
(which is stored _within_ the email) instead of using the reverse path
stored along the email in the Mail class. According to the mail RFCs, the
Return-Path header is not indeded to be used by an smtp service, it should
only be used when final delivery occurs, e.g. when storing the mail in a
mailstore used by a pop service. I consider this as a hack, and really don't
like it in James, but because the James smtp handler always inserts the
Return-Path header it seems to be working.
However, the GenericListserv mailet removes the Return-Path header. I think
that is quote correct, on the other hand it breaks the above, not so correct
assumption about the Reverse-Path header. The bounce method in these cases
defaults to the Reply-To, i.e the mail list itself, so you get a mail loop
involving as many people as you have on the list... It happened to me
several times.
In my oppininon the correct solution would be to enirely remove the
dependency on the Return-Path header, but I don't have enough time and
understanding of James. So I only implemented a fallback specifically for
the case when the Return-Path header is not present, which eliminates this
type of loop in my case:
I replaced the
getLogger().warn("Mail to be bounced does not contain a
Return-Path header.");
line with this code:
MailAddress reversePath = mail.getSender();
if (reversePath == null) {
getLogger().warn("Mail to be bounced does not contain a
Return-Path header and reverse path is null too, sending to postmaster.");
reply.setRecipient(MimeMessage.RecipientType.TO,
getPostmaster().toInternetAddress());
} else {
getLogger().warn("Mail to be bounced does not contain a " +
"Return-Path header although expected (wrongly!), "
+
"reverse path used (it should be used always): " +
reversePath.toString());
reply.setRecipient(MimeMessage.RecipientType.TO,
reversePath.toInternetAddress());
}
(I copied this code directly from my source, maybe the log message isn't
suitable for a release)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
