ietf-smtp
[Top] [All Lists]

Re: Submission identifiers

2009-01-27 09:09:59

David MacQuigg <david_macquigg(_at_)yahoo(_dot_)com> wrote:

We've narrowed the question to just whether SMTP should drop the
requirement that receivers MUST NOT reject apparently forged helonames.

   I disagree that any such requirement exists: the prohibition is much
narrower than that.

   For nearly five years I have been rejecting _clearly_ forged EHLOs
according to:

http://www.bbiw.net/CSV/draft-ietf-marid-csv-intro-01.html

which states:

- Extract the domain name from the EHLO command sent by the SMTP client

- Query DNS for a SRV record under the EHLO domain name (see
  [ID-CSVCSA])

- Check the SRV reply for flags returned, and check for a match in the
  list of returned IP addresses

   Granted, almost the only thing I actually reject is EHLO jlc.net...

   I claimed that was allowed under 2821; and I believe there was
general agreement that rejecting clearly forged EHLO is allowed under
5321. If there isn't such general agreement, perhaps we should add a
sentence saying it's OK to reject a session if the EHLO is clearly
forged.

   But I can't agree with David's proposed language...

The suggested language for a change was:

  An SMTP server MAY reject a mail session if a domain name argument in
  the EHLO command does not actually correspond to the IP address of the
  client.  Clients that are unable to establish this correspondence MUST
  NOT provide an invalid domain name argument.

   There's a big difference between applying a crisp statement of which
IP addresses are (currently) used by authorized MTAs, versus guessing
that A)ddress records returned on a DNS query give the list of addresses
of authorized MTAs.

The claimed benefit was that a currently useless and frequently abused
parameter, the heloname, could then become useful in rejecting forgeries,

   I'm using it for that right now.

and that would motivate legitimate senders to take it seriously.

   I can't report much movement in that direction...

This in turn could lead to large numbers of receivers making good use
of the heloname, whitelisting legitimate domains, etc.

   I'd love to see that. Perhaps David would like to resurrect CSV to
some kind of standards status and see if that makes a difference?

The claimed reason for not making this change was that it would be too
hard on some small fraction of legitimate senders. Three cases were
presented.

1) The small office with a dynamically-assigned IP address.
2) The roaming laptop.
3) The digital camera.

   (Don't forget that any change to the _base_ spec requires compatibility
with existing usage.)

The solutions considered too difficult were:

1) Get a static IP address for the transmitter in the small office.

   Not really necessary: there are dynamic-DNS services to cause a
dynamically-assigned IP address to be returned by the DNS server.

2) Relay through a transmitter with an established identity and
   reputation.

   Aggregating reputation inevitably makes reputation less crisp.

3) Authorize the entire block of addresses that might be dynamically
   assigned to the transmitter.

   ... exposing you to the risk of bad players anywhere in the block...

4) Use an address literal, meaning - please accept this session without
   a HELO ID.

   I suppose you could always do "EHLO [127.0.0.1]", but why bother?

Have I missed anything?

   Dave has missed the poor correlation between A)ddress records and
intent to authorize particular MTAs.

   He's also missed cases where the IP address might actually change
_during_ a SMTP session (but we've all missed that, hoping it will be
hidden from us).

   And, most important, he's missed the need for compatibility with
existing usage.

   But I quite agree with him that an EHLO string _should_ be useful
for something. We just need to define ways to do so. CSV could be one.
Or we could define an extension to allow the SMTP client to send an
encrypted authorization. Or something else I haven't thought of.

   It's just that we shouldn't try to squeeze this into the base spec.

--
John Leslie <john(_at_)jlc(_dot_)net>

<Prev in Thread] Current Thread [Next in Thread>