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
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 lik
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 a
On 2/21/2013 4:36 PM, David F. Skoll wrote:
On Thu, 21 Feb 2013 16:26:46 -0500
"Kevin A. McGrail" 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 kno
On Thu, 21 Feb 2013 16:26:46 -0500
"Kevin A. McGrail" 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 t
On 2/21/2013 2:51 PM, Jeff Mincy wrote:
From: "Kevin A. McGrail"
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 th
From: Matus UHLAR - fantomas
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 h
From: "Kevin A. McGrail"
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 RFC
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
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.
On Thu, 21 Feb 2013 10:26:32 -0500
"Kevin A. McGrail" 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
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.
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 whi
From: "Kevin A. McGrail"
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 p
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
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 w
16 matches
Mail list logo
