Re: Scope of SMTP Verify

On 2004-03-04 01:53:16 -0500, Yakov Shafranovich wrote:
> Peter J. Holzer wrote:
> >On 2004-03-01 21:20:44 -0500, Yakov Shafranovich wrote:
> >
> >>Peter J. Holzer wrote:
> >>
> >>>1) The identity of the SMTP client. SMTP auth exists, but doesn't seem
> >>> to be much use between random hosts on the internet (It is useful for
> >>> authenticating users to their "home MTA").
> >>>
> >>> Various plausibility checks (check for PTR records, check HELO
> >>> parameter against IP, ...) also fall into this category.
> >>>
> >>
> >>We know the identity of the SMTP client based on its IP. What other
> >>kinds of identity are possible?
> >
> >
> >E.g., "This is Joe's laptop". Or "This is the same computer that sent
> >spam last week".
> >
> >The IP address is only an indicator of identity for systems with static
> >IP addresses.
> >
>
> For those systems, is an IP address sufficient identity?

For the system, yes. It unambiguously identifies the system. (A system
can have several static IP addresses, but a static IP address by
definition belongs to only one system).

The real question of course is, "does the identity of the the system
tell me anything about whether that mail is spam or not?" In and of
itself of course not. It can, however, be combined with other data (has
this system sent spam in the past? Has it sent legitimate mail? Is it an
outgoing MTA of a reputable ISP? ...)

> For dynamic systems, is the actual "dynamic" of the address the only
> reason why we would need other identification systems beside IP?

For purposes of identifying the system, I cannot think of one. However,
since there is no way to tell whether an IP address is static or
dynamic, I think that is reason enough.

> >>>2) The identity of the sender of a message.
> >>>
> >>>  This is currently only possible with cryptographic signatures in the
> >>>  message, not at the SMTP level. (That distinction might be academic)
> >>
> >>If you trust the MTA, you can trust it to pass the sender's identity via
> > ^^^^^^^^^^^^^^^^^^^^
> >  That's the crux, isn't it? I don't trust any random MTA connecting to
> >  my MTA's port 25.
> >
>
> But we do want to allow a new domain to make its own MTA and not having
> to "pay the piper" to some gatekeeper in order to send mail.

Absolutely, yes. I am running my own MTA, and I would hate to be forced
to use my provider's smart host or to pay Thawte a yearly fee for a
certificate.

I also want to be able to receive mails from strangers.

But if an unknown MTA connects to my MTA I cannot trust it to pass the
correct return path in the MAIL FROM command. The return path can be
invented out of the blue, it can be picked at random from a list, or it
can indeed belong to the originator of the mail. I simply don't know and
I have no way of verifying it. (LMAP narrows it down to the domain level
- but any user of a domain can still masquerade as any other user of
that domain).



> >>>  An ESMTP extension to pass a signature of relevant envelope
> >>>  information (return path, envid(?), size(?), ...) and a timestamp
> >>>  could be devised.
> >>>
> >>
> >>There actually is a proposal at the IETF for passing all headers via an
> >>SMTP extension which might be similar to what you are thinking of.
> >
> >
> >I looked through the internet draft abstracts, but couldn't find it. Do
> >you have an URL handy?
> >
>
> http://www.ietf.org/internet-drafts/draft-klensin-email-envelope-00.txt

Ah thanks. I've seen that, but it's something different.

It only moves trace information (currently the Received headers) from
the message headers into the envelope. The other headers (most
importantly From, Subject, Date, Content-Type) stay in the header and
are transitted with the DATA command.

	hp

--
   _  | Peter J. Holzer    | I think we need two definitions:
|_|_) | Sysadmin WSR       | 1) The problem the *users* want us to solve
| |   | [email protected]         | 2) The problem our solution addresses.
__/   | http://www.hjp.at/ |    -- Phillip Hallam-Baker on spam

[demime 0.99d.1 removed an attachment of type application/pgp-signature]