RE: Parsing Received Headers

> > 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

As for reporting this to the CommuniGate people, I doubt they have any interest in fixing it. After all, they still use the domain name instead of the machine name for their own EHLO/HELO command and provide no way of overriding it for RFC compliance. We got around it by (against their recommendation) licensing our copy to the machine instead of the domain.

Anyway, the above doesn't make any more sense to me than reading examples in the mail I receive. So far, I haven't come up with a format that works for SA. So, please correct:

HELO bretspc, IP 192.168.1.125, RDNS bretspc.example.com Received: from bretspc (bretspc.example.com 192.168.1.125)...

HELO [192.168.1.125], IP 192.168.1.125, RDNS none Received: from [192.168.1.125] (unknown 192.168.1.125)...

HELO 192.168.1.125, IP 192.168.1.125, RDNS 192.168.1.125 (yeah, I've seen ones like this)
Received: from 192.168.1.125 (192.168.1.125 192.168.1.125)...

And then there's the matter of adding whether the sender was authenticated, and what was supplied as "mail from".

Perhaps the better way to do this would be to fix SA to read the CGPro headers, do it's own RDNS lookup if necessary. The problem is that not all the information is available to SA at that point, so I have to supply some of it, and I suppose there would be concerns as to whether SA should be doing the RDNS lookup itself too.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related spamassassin.apache.org Links users Request more information about Pantek

Maybe a plugin? But can a plugin get control early enough to re-write the received header info so that it's correct for all the other places in SA it gets used?

So I guess my choices are there-- rewrite the received header to make it readable, patch SA to read the information correct (this doesn't solve my missing RDNS info problem unless I add the lookup to SA too), or add a plugin if it's possible to do what needs to be done with it.

Honestly, rewriting the header is probably the easiest, which is why I chose to do that. Now it's just a matter of rewriting it so that SA can actually read it properly. I guess another problem is that I might have to say I'm NOT running CommuniGate Pro so that SA doesn't try it's custom code on it...

Bret