Re: [rt.amsl.com #7269] ietf.org mail blocking?

["Eric Rescorla" <ekr at rtfm.com>]

On Fri, May 9, 2008 at 6:49 PM, James M Galvin <galvin at elistx.com> wrote:
> A short answer to you is the following.
>
> RFC 2821 clearly states in Section 3.6 that:
>
>   Only resolvable, fully-qualified, domain names (FQDNs)
>   are permitted when domain names are used in SMTP.
>
>
> However, perhaps we (the IETF) want to be a bit more generous in what we
> accept, so I've commented more fully inline.  As always, "rules" can be
> changed.

OK. That's fair. I'd quibble with the argument that the server should
be blocking
mail that doesn't conform to this (be liberal in what you accept,
etc.) but I've added the appropriate
record for romeo.rtfm.com. It doesn't seem to help.




>> > Have you always done this?
>>
>> Not always, but there hasn't been an A record for
>> "romeo.rtfm.com" for over a year
>> and it worked fine till at least 5/5 (which was the last time
>> before today that I tried to send mail through ietf.org).
>
> When you say "no A record", do you mean it was not listed in the DNS or just
> that it did not have an A record?

I mean that it's not been listed in the DNS at all. Not that it really matters,
since S 3.6 quite clearly
states that names appearing in EHLO must resolve to A records:

  -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1

So, I believe this is some new behavior we're observing.

As noted above, I believe my domain is now configured to pass the test
you say this system is enforcing, but mail.ietf.org still seems to be
rejecting my email. What now?


The rest of this message is me arguing that this test isn't appropriate,
but that's no longer the high order bit.


>> > It should be the case that the IETF servers do not take
>> > messages from hosts that do not exist.
>>
>> 1. The host does exist. It just doesn't have a DNS entry.
>> 2. Why should this be the case?
>
> While the host may certainly exist, presence in the DNS is commonly used as
> a weak authoritative existence test.  The assumption is that a process,
> albeit a weak one, was exercised to approve the presence in the DNS.
>
> The obvious counter-argument is that a SPAMMER could own the domain they're
> using and put anything they want in the DNS.  The argument is valid to the
> extent that SPAMMERS are not taking steps to hide their existence or
> identity.  While there are many ways to slice the "email pie" to find the
> bad parts (the SPAMMERS), I think we can at least agree that connection
> sources who are attempting to hide their existence or identity are SPAMMERS.

Well, I'm not a spammer, so either this assertion is wrong or people not
representing correct identities is a lousy test for people attempting to
hide their existence. Take your pick.


>  For those cases, this test is just one mechanism among many that is helpful
> in the fight against SPAM.

Huh? Why is this so? Say I do "EHLO mail.ietf.org"? That's a perfectly
valid domain
name and it maps to an IP address. It just doesn't happen to be mine. This
only becomes a useful check when you compare it to the address that I'm
actually coming from.



>> > The IETF does not apply strict connection controls but it seems
>> > reasonable to me to reject apparently "anonymous" messages.
>>
>> What makes the message anonymous? I'm advertising "ekr at rtfm.com"
>> in my MAILTO.
>
> I'm using "anonymous" to mean that the origin of the connection is not
> clearly identifying itself.  Yes, it could "lie" to get past this particular
> check but that's exactly the point.  It's not even trying to "do the right
> thing".

I don't find this particularly convincing. It's identifying itself by
IP address.
Given that that's a lot harder to spoof than domain name, I wouldn't
use the term anonymous...



>> Because of point (2) you can't check that value (2) matches value
>> (3) or value (4). At best you can check that the reverse mapping
>> exists and that the forward mapping exists. However, the problem
>> here is that because of point (0), this causes spurious
>> rejections, and therefore only makes sense if it's significantly
>> harder for spammers to get the reverse/forward parts of the tree
>> in shape than it is for ordinary users. Why would this be so?
>
> It is true that people can "lie" and this is checked in SpamAssassin and
> contributes to the SPAM score of a message.  The only mechanism employed at
> connection time is the most basic configuration check.  If the origin of a
> connection can not make any attempt to identify itself in a way that can be
> verified, even weakly, then that origin is summarily suspicious.

As noted above, I question that claim.

-Ekr