Re: rdns in received header
At 13:42 21-02-2013, Kevin A. McGrail wrote: Unless betting for minor sums such as a beer or a happy meal, I generally won't get into RFC compliance arguments with DFS. My reading was similar though there are some other RFCs that extend SMTP and say things like if you use ESMTP, you have to add with ESMTP to the received headers. The following is about ESMTP: For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. Regards, -sm
Re: rdns in received header
On 2/24/2013 12:58 PM, SM wrote: At 13:42 21-02-2013, Kevin A. McGrail wrote: Unless betting for minor sums such as a beer or a happy meal, I generally won't get into RFC compliance arguments with DFS. My reading was similar though there are some other RFCs that extend SMTP and say things like if you use ESMTP, you have to add with ESMTP to the received headers. The following is about ESMTP: For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. I'm referring to other RFCs such as 1651 which says: 7. Received: Header Field Annotation SMTP servers are required to add an appropriate Received: field to the headers of all messages they receive. A with ESMTP clause should be added to this field when any SMTP service extensions are used. My point being that I don't know if there are more RFCs that govern received header information. I've just happened to know that one. Regards, KAM
Re: rdns in received header
At 11:07 24-02-2013, Kevin A. McGrail wrote: I'm referring to other RFCs such as 1651 which says: That's an obsoleted RFC. It might be better to refer to RFC 5321 (Section 4.4) for information about the Received: header. Regards, -sm
Re: rdns in received header
On 2/20/2013 8:51 PM, Jeff Mincy wrote: ... This leads to various bad things (RDNS_NONE broken WHITELIST_FROM_RCVD) Is there anything in SpamAssassin that can deal more elegantly with this particular problem? Perhaps Some sort of please_fill_in_rcvd_rdns type option? Off the cuff, the point of trusted networks is to say you trust that network's headers. However, in this case, you don't... I don't really know a fix for this because we have enough issues parsing received headers, let alone re-writing them. How good is your perl and maybe you can solve it in MIMEDefang before it's sent to SA? Regards, KAM
Re: rdns in received header
From: Kevin A. McGrail kmcgr...@pccc.com Date: Thu, 21 Feb 2013 08:46:40 -0500 On 2/20/2013 8:51 PM, Jeff Mincy wrote: ... This leads to various bad things (RDNS_NONE broken WHITELIST_FROM_RCVD) Is there anything in SpamAssassin that can deal more elegantly with this particular problem? Perhaps Some sort of please_fill_in_rcvd_rdns type option? Off the cuff, the point of trusted networks is to say you trust that network's headers. However, in this case, you don't... I don't really know a fix for this because we have enough issues parsing received headers, let alone re-writing them. Well, I trust the network not to lie. This is more of an omission How good is your perl and maybe you can solve it in MIMEDefang before it's sent to SA? Yea, I expected this was going to be the answer. It would have to be a procmail filter that calls out to a script. Yuck. Thanks for confirming my suspicion. I could always whine to Rcn about it, maybe they'll fix it. -jeff
Re: rdns in received header
On 2/21/2013 9:03 AM, Jeff Mincy wrote: Well, I trust the network not to lie. This is more of an omission Your Clinton-esque logic likely doesn't apply here ;-). The land of RFC's works to avoid this type of logic in a language I call RFC-eeze. See http://www.ietf.org/rfc/rfc2119.txt which is an RFC about language in RFCs. How good is your perl and maybe you can solve it in MIMEDefang before it's sent to SA? Yea, I expected this was going to be the answer. It would have to be a procmail filter that calls out to a script. Yuck. Frightening indeed. Procmail still gives me nightmares. I could always whine to Rcn about it, maybe they'll fix it. I think that's a good move to at least try! It truly sounds more like a DNS error that they might know be are is occurring. Regards, KAM
Re: rdns in received header
On 20.02.13 20:51, Jeff Mincy wrote: My local ISP (rcn.com) reconfigured their email servers. The 69.168.97.77 hop does not seem to be doing rdns lookups on the previous hop. For example, I get these two received headers at the trust boundary: ... Received: from mx.rcn.com ([69.168.97.77]) by mx06.atw.mail.rcn.net with ESMTP; 20 Feb 2013 17:07:22 -0500 ...trust/internal boundary... Received: from [216.33.63.216] ([216.33.63.216:56326] helo=bigfootinteractive.com) by mx.rcn.com (envelope-from 1709130a2layfovcia3kqqzqabnxydzhs2jc2h4yaa...@mail.ameriprise.com) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 29/DB-26250-A1945215; Wed, 20 Feb 2013 17:07:22 -0500 This leads to various bad things (RDNS_NONE broken WHITELIST_FROM_RCVD) Try asking your provider to turn the reverse DNS lookups on and ask them why the hell did they turn it off at all... Is there anything in SpamAssassin that can deal more elegantly with this particular problem? Perhaps Some sort of please_fill_in_rcvd_rdns type option? SA does not do such lookups by itself, there's only one exception related to some buggy MTA. I don't think SA maintainers are willing to do such lookups in SA. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam is for losers who can't get business any other way.
[Somewhat OT] Procmail replacement (was Re: rdns in received header)
On Thu, 21 Feb 2013 10:26:32 -0500 Kevin A. McGrail kmcgr...@pccc.com wrote: Frightening indeed. Procmail still gives me nightmares. Yes. I replaced Procmail with Mail::Audit: http://search.cpan.org/~rjbs/Mail-Audit-2.227/lib/Mail/Audit.pm and now my local delivery agent filter is much easier to configure and the filtering rules are much more expressive. Regards, David.
Re: rdns in received header
On 2/21/2013 9:03 AM, Jeff Mincy wrote: Well, I trust the network not to lie. This is more of an omission On 21.02.13 10:26, Kevin A. McGrail wrote: Your Clinton-esque logic likely doesn't apply here ;-). The land of RFC's works to avoid this type of logic in a language I call RFC-eeze. as long as I understan Jeff's original mail, the issue is that his ISP stopped providing DNS information in the Received: headers. SA does not do lookups on the IPs in Received: (there's iirc one exemption related to a buggy software) and if it's not there, it assumes the rDNS does not exist, while it does. See http://www.ietf.org/rfc/rfc2119.txt which is an RFC about language in RFCs. And how is this ISP's issue related to RFCs? The RFC does not mention word trusted I could always whine to Rcn about it, maybe they'll fix it. I think that's a good move to at least try! It truly sounds more like a DNS error that they might know be are is occurring. if the error repeats, I assume Jeff's guess is correct and the ISP just turned rDNS lookups off. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor.
Re: rdns in received header
On 2/21/2013 10:36 AM, Matus UHLAR - fantomas wrote: And how is this ISP's issue related to RFCs? The RFC does not mention word "trusted" A fair point that I didn't explain clearly enough. The RFCs cover received headers for SMTP and RFCs strive to be black and white. Discussing things as gray area is an argument that Bill Clinton was famous for but doesn't really hold a place in discussing technology covered by The point of SA's trusted configuration is that you "trust" the headers. In this case, he's saying he doesn't trust the headers because they are omitting important information but that they aren't lying, just lying by ommissions. To me, this says "I can't trust those headers" and you need to pull back your trust circle which in this case will ruin much of the rules SA uses for pathway analysis (RBLs, rDNS, etc.) Fixing those headers outside SA or fixing the ISP creating those headers are the real solutions. regards, KAM -- Kevin A. McGrail President Peregrine Computer Consultants Corporation 3927 Old Lee Highway, Suite 102-C Fairfax, VA 22030-2422 http://www.pccc.com/ 703-359-9700 x50 / 800-823-8402 (Toll-Free) 703-359-8451 (fax) kmcgr...@pccc.com
Re: rdns in received header
From: Kevin A. McGrail kmcgr...@pccc.com Date: Thu, 21 Feb 2013 11:07:20 -0500 On 2/21/2013 10:36 AM, Matus UHLAR - fantomas wrote: And how is this ISP's issue related to RFCs? The RFC does not mention word trusted A fair point that I didn't explain clearly enough. The RFCs cover received headers for SMTP and RFCs strive to be black and white. Discussing things as gray area is an argument that Bill Clinton was famous for but doesn't really hold a place in discussing technology covered by Which RFC talks about Received headers having rDNS or what information is supposed to be in the received header? The point of SA's trusted configuration is that you trust the headers. In this case, he's saying he doesn't trust the headers because they are omitting important information but that they aren't lying, just lying by ommissions. To me, this says I can't trust those headers and you need to pull back your trust circle which in this case will ruin much of the rules SA uses for pathway analysis (RBLs, rDNS, etc.) Fixing those headers outside SA or fixing the ISP creating those headers are the real solutions. There is of course a third option for me - I could turn off the spam filtering on Rcn email. Most of the spam is blocked by Rcn, there's almost no point in trying to filter what little spam is left. -jeff
Re: rdns in received header
From: Matus UHLAR - fantomas uh...@fantomas.sk Date: Thu, 21 Feb 2013 16:36:18 +0100 On 2/21/2013 9:03 AM, Jeff Mincy wrote: Well, I trust the network not to lie. This is more of an omission On 21.02.13 10:26, Kevin A. McGrail wrote: Your Clinton-esque logic likely doesn't apply here ;-). The land of RFC's works to avoid this type of logic in a language I call RFC-eeze. as long as I understan Jeff's original mail, the issue is that his ISP stopped providing DNS information in the Received: headers. SA does not do lookups on the IPs in Received: (there's iirc one exemption related to a buggy software) and if it's not there, it assumes the rDNS does not exist, while it does. Actually the ISP added a completely new hop, and that hop is not adding rDNS to the received header. I had to add the new hop to trusted_networks and internal_networks. The new hop looks like it is scanning the messages using Cloudmark: X_CMAE_Category: ... X-CNFS-Analysis: ... X-CM-Score: ... X-Scanned-by: Cloudmark Authority Engine I could always whine to Rcn about it, maybe they'll fix it. I think that's a good move to at least try! It truly sounds more like a DNS error that they might know be are is occurring. if the error repeats, I assume Jeff's guess is correct and the ISP just turned rDNS lookups off. Or neglected to turn on the lookups in the first place... -jeff
Re: rdns in received header
On 2/21/2013 2:51 PM, Jeff Mincy wrote: From: Kevin A. McGrail kmcgr...@pccc.com Date: Thu, 21 Feb 2013 11:07:20 -0500 On 2/21/2013 10:36 AM, Matus UHLAR - fantomas wrote: And how is this ISP's issue related to RFCs? The RFC does not mention word trusted A fair point that I didn't explain clearly enough. The RFCs cover received headers for SMTP and RFCs strive to be black and white. Discussing things as gray area is an argument that Bill Clinton was famous for but doesn't really hold a place in discussing technology covered by Which RFC talks about Received headers having rDNS or what information is supposed to be in the received header? Off-hand, I don't know that any specific RFC spells out that exact requirement. For SMTP, it's http://tools.ietf.org/html/rfc5321#section-3.7.2 along with some others that add requirements for the received header (1651, I think adds ESMTP requirements). Overall, though Received is considered debug/trace information and pre-existing headers shouldn't be modified when received. But I do believe it's generally accepted that one of the primary original uses for rDNS was for received headers in SMTP. I don't think anything requires it. Someone on this list will know for sure. The point of SA's trusted configuration is that you trust the headers. In this case, he's saying he doesn't trust the headers because they are omitting important information but that they aren't lying, just lying by ommissions. To me, this says I can't trust those headers and you need to pull back your trust circle which in this case will ruin much of the rules SA uses for pathway analysis (RBLs, rDNS, etc.) Fixing those headers outside SA or fixing the ISP creating those headers are the real solutions. There is of course a third option for me - I could turn off the spam filtering on Rcn email. Most of the spam is blocked by Rcn, there's almost no point in trying to filter what little spam is left. Agreed. It's unusual these days to have to improve on the upstream provider much more than the junk filters built into MUAs like Thunderbird and Outlook. regards, KAM
Re: rdns in received header
On Thu, 21 Feb 2013 16:26:46 -0500 Kevin A. McGrail kmcgr...@pccc.com wrote: But I do believe it's generally accepted that one of the primary original uses for rDNS was for received headers in SMTP. I don't think anything requires it. Someone on this list will know for sure. My reading of RFC 5321 is that reverse-DNS is not required. Indeed, I don't think an implementation is even obligated to put the actual IP address of the SMTP client. The RFC says this about the FROM clause: From-domain= FROM FWS Extended-Domain Extended-Domain = Domain / ( Domain FWS ( TCP-info ) ) / ( address-literal FWS ( TCP-info ) ) By my reading, Extended-Domain doesn't have to include TCP-info; it can just be whatever the other end said in its HELO. So: Received: from what-i-said-in-helo.example by foo.example.com; Sat, 16 Mar 2002 02:22:28 -0800 is a valid received line according to my reading of the RFC. You could complain about the quality of an implementation that produces such a line, but not about whether it adheres to the RFC. Regards, David.
Re: rdns in received header
On 2/21/2013 4:36 PM, David F. Skoll wrote: On Thu, 21 Feb 2013 16:26:46 -0500 Kevin A. McGrail kmcgr...@pccc.com wrote: But I do believe it's generally accepted that one of the primary original uses for rDNS was for received headers in SMTP. I don't think anything requires it. Someone on this list will know for sure. My reading of RFC 5321 is that reverse-DNS is not required. Indeed, I don't think an implementation is even obligated to put the actual IP address of the SMTP client. The RFC says this about the FROM clause: From-domain= FROM FWS Extended-Domain Extended-Domain = Domain / ( Domain FWS ( TCP-info ) ) / ( address-literal FWS ( TCP-info ) ) By my reading, Extended-Domain doesn't have to include TCP-info; it can just be whatever the other end said in its HELO. So: Received: from what-i-said-in-helo.example by foo.example.com; Sat, 16 Mar 2002 02:22:28 -0800 is a valid received line according to my reading of the RFC. You could complain about the quality of an implementation that produces such a line, but not about whether it adheres to the RFC. Unless betting for minor sums such as a beer or a happy meal, I generally won't get into RFC compliance arguments with DFS. My reading was similar though there are some other RFCs that extend SMTP and say things like if you use ESMTP, you have to add with ESMTP to the received headers. But as for having to add reverse DNS information, it likely would come under an if available, it should be added type of clause. regards, KAM
rdns in received header
My local ISP (rcn.com) reconfigured their email servers. The 69.168.97.77 hop does not seem to be doing rdns lookups on the previous hop. For example, I get these two received headers at the trust boundary: ... Received: from mx.rcn.com ([69.168.97.77]) by mx06.atw.mail.rcn.net with ESMTP; 20 Feb 2013 17:07:22 -0500 ...trust/internal boundary... Received: from [216.33.63.216] ([216.33.63.216:56326] helo=bigfootinteractive.com) by mx.rcn.com (envelope-from 1709130a2layfovcia3kqqzqabnxydzhs2jc2h4yaa...@mail.ameriprise.com) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 29/DB-26250-A1945215; Wed, 20 Feb 2013 17:07:22 -0500 ... and the relays are parsed as X-Spam-Relay: Trusted= ...[ ip=69.168.97.77 rdns=mx.rcn.com helo=mx.rcn.com by=mx06.atw.mail.rcn.net ident= envfrom= intl=1 id= auth= msa=0 ] Untrusted=[ ip=216.33.63.216 rdns= helo=bigfootinteractive.com by=mx.rcn.com ident= envfrom=1709130a2layfovcia3kqqzqabnxydzhs2jc2h4yaa...@mail.ameriprise.com intl=0 id=29/DB-26250-A1945215 auth= msa=0 ] ... This leads to various bad things (RDNS_NONE broken WHITELIST_FROM_RCVD) Is there anything in SpamAssassin that can deal more elegantly with this particular problem? Perhaps Some sort of please_fill_in_rcvd_rdns type option? I'm still on 3.2.5 (yes I know it is old). -jeff
