Mail PTR Records
peter at farrows.org
Mon Mar 3 22:58:56 GMT 2008
Matt Kettler wrote:
> John Hinton wrote:
>> Richard Frovarp wrote:
>>> mikea wrote:
>>>> On Mon, Mar 03, 2008 at 01:15:21PM -0600, Nathan Olson wrote:
>>>>> It's not RFC-compliant.
>>>> As has been mentioned elsethread, a number of techniques which are
>>>> increasingly necessary for survival are not RFC-compliant.
>>>> Many RFCs were written when the Internet was kinder, gentler, and MUCH
>>>> less dangerous than it is now. They have not changed, though the 'Net
>>>> certainly has. Blind adherence to them in the face of evidence that
>>>> that adherence opens windows of vulnerability is not necessarily dood
>>>> or wise.
>>> The issue is you'll see people break the RFC's because they are
>>> upset someone else broke another part of the RFC's. Becomes a bit
>> I think this thread is a dead horse. Do you reject any email to any
>> address for which you should receive email? If so, what does that?
>> Perhaps you may be running spamhaus.zen at the smtp level? This is
>> not RFC compliant.
> Is it non compliant? There's nothing in the RFCs that prohibit
> blocking such email. Just because a RFC doesn't explicitly tell you
> you can, doesn't mean you MUST NOT.
> I see nowhere that any RFC says you must always accept email for a
> valid recipient. I see nowhere that says you must not refuse email
> from hosts of your choosing.
> RFC 2821 states:
> " From the Internet side, the gateway SHOULD accept all valid address
> formats in SMTP commands and in RFC 822 headers, and all valid RFC
> 822 messages."
> However, that's a SHOULD, not a MUST. It is not a standards violation
> to deviate from it.
>> Do you reject mail if it exceeds 100 GB? I know of no size limits
>> allowed within the RFCs.
> I know of nowhere where such limits are disallowed. Therefore, by
> default, they are acceptable.
Ah yes but you can legitimately reject big messages
> There's certainly examples in the RFC's of tempfailing mail due to
> lack of available storage. RFC 821 creates the 452 code explicitly for
> this purpose.
> I see nowhere that would prohibit a system from enforcing a size limit
> on email, either by 4xx or 5xx error code. Can you find one?
>> Is there a RFC that allows one to change the subject line of incoming
>> email, like adding SPAM to the front of it?
> RFC 2821 states that relay SMTP systems do not modify the message
> other than adding trace headers, however not all SMTP systems are
> relays. Gateways are allowed to modify. Normally gateways deal with
> clients, not server to server traffic.
> However, RFC 2821 explicitly addresses firewalls that rewrite headers
> in server to server transfers and says these should be considered
>> The bottom line is most of the huge ISPs, AOL, Comcast, Verizon, and
>> on and on and on, all reject if there is no reverse DNS. Call it what
>> you want, but if someone doesn't have a legit PTR, they have what
>> amounts to being a broken email system by today's standards.
>> Therefore, rejecting based on no PTR has become a standard. Just like
>> having to receive html email due to Micro$oft has become a standard.
> Personally, I have yet to see anyone, anywhere point out how this
> violates an RFC. I've found one informational RFC that suggests this
> practice is common and should be expected. (RFC 1912)
>> OK... I'm through beating this dead horse.
>> John Hinton
More information about the MailScanner