james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [Proposal] FetchPOP configuration change
Date Fri, 03 Jan 2003 19:06:19 GMT

That is what I asked about the Received header.  It didn't appear to be a
guarantee, and relying upon the other address headers looks like an
opportunity for addressing errors.

It sounds as if the current proposal becomes:

  1. Enhance FetchPOP to use the Received header.
  2. Add an address field to the configuration to
     be used if the Received header does not have
     a valid address.

Is that your understanding?

	--- Noel

-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Friday, January 03, 2003 6:37
To: James Developers List
Subject: Re: [Proposal] FetchPOP configuration change

Hi Danny,

I agree here that information in the Received header is very ify.
The info can be wrong or possibly be missing all together (this breaks
RFC822 but still seems to be done by some firewalls and mail servers)
It also seems that sometimes Firewalls and Relays can remove/change portions
of the Received header to obscure certain information that could be used to
mount an attack.

I found nothing in RFC 822 that says RCPT TO: must be exposed, NOTE that
this translates to the "for" parameter
Quote from RFC 822: "the receiving host  may  wish  to record  the original
specification, using the "for" parameter."

The Received header appears once for each relay the mail goes through with
the most recent email server first, and the first mail server that relayed
this email last.

I am still wondering if it is not just easier to add the option in the
FetchPOP block to say who the fetched mail is for.
There seems to be a fair amount of "if's" which in my opinion don't make
things simple and could lead to strange results.
I can already see the questions coming when the FetchPOP behavior is not
understood by someone using JAMES and we
have to explain how we try and decide who the FetchPOP'd mail is for.

Serge or maybe Sergei and then I don't get mixed up with the other Serge :-)

----- Original Message -----
From: "Danny Angus" <danny@apache.org>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Friday, January 03, 2003 11:50 AM
Subject: RE: [Proposal] FetchPOP configuration change

> > Is there any concern regarding whether or not the the Received
> > header might
> > not have the proper information?
> Yes some, I'm not 100% sure that a "Received" header MUST expose the "RCPT
> TO:" address in a "for" line, nor that this would necessarily be a
> legitimate mail address of any kind.
> Can we reasonably infer that SMTP headers exist simply because mail is
> available for download via POP3?
> If not, we can read the message "To" & "Cc" headers, if this fails to help
> (perhaps it was a bcc) we should catch this in FetchPOP and take some
> default action, perhaps indeed have a default alias for unidentifiable
> fetched mail.
> If, sorry _when_ we get mail parameters we can (possibly, if we can have a
> mail object without a recipient) set a parameter to indicate an
> attempt to parse a recipient address, this can be used in the general
> pipeline to filter this mail so that the user controls what happens,
> than have us impose some arbitrary behaviour. I worry about null pointer
> recipients) exceptions in this case though.
> d.
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message