Bret,
> I'm trying to get received headers to parse correctly because the ones from
> CommuniGate Pro don't always. And, since I'm already modifying the headers
> in my connector due to the MTA not being able to do RDNS without rejecting
> based on it, I'm not aware that certain types of headers don't parse
> correctly. My current problem is this one:
> ...
> My RDNS lookup was modifying the header to read:
Since you are already fixing broken Received header fields,
I suggest you do it by the book. The syntax is prescribed
by RFC 2821 (4.4 Trace Information):
...
This line MUST be structured as follows:
- The FROM field, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.
...
From-domain = "FROM" FWS Extended-Domain CFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
TCP-info = Address-literal / ( Domain FWS Address-literal )
; Information derived by server from TCP connection
; not client EHLO.
Domain = (sub-domain 1*("." sub-domain)) / address-literal
John Rudd writes:
> That's correct. CommuniGate puts the DNS based information before the
> parentheses, and puts non-DNS based information inside the parentheses
> (for authenticated email, it puts the authenticated user account instead
> of the HELO info, for non-authenticated it puts the HELO string, but
> there's also a third case which I'm not recalling at the moment).
Someone with a CommuniGate maintenance contract should open a bug report.
They are implementing a SMTP-based mailer and did not care to read the
basic RFC.
Mark
