ietf-mxcomp
[Top] [All Lists]

Re: Let senders pick identities

2004-03-28 03:32:47

I think this is good first shot Yakov.

The bottom line is that the process makes the information available with the
enforcement policies behind, not by stating how it is related or not, but
rather that the system implementation used to perform the validation has the
enforcement power to reject the transaction.   This is very important
because we can not lock ourselves into one set of "rules."  Regardless of
the "rules" or proposals, they are all based on:

In your #1, all that says is that HELO means something finally.

In your #2, all that says is that MAIL FROM means something finally.

These items can no longer be relaxed to the extent that it gives no
incentive whatsoever for any one to "change", especially the abusers.   The
problem is world wide and the legitimate systems will adapt very quickly.
If need be, we can put a "time frame" statement for migration.   But rest
assured,  once the enforcement is put in place, all commercial mail software
vendors and operations will quickly support it.   Once there are "false
rejections" due to old setups, these systems will quickly adapt be it, 1
hour, 1 day, 1 week, or whatever. they will adapt.  It means people will
have to get their configurations straight, including the IETF mail servers!
<g>

But once these items have some real "cojones" behind them, I believe we will
get a new wave of ESMTP ideas that work with the enforceable protocol level
entities. LMAP works for the domain, but the validation of the address or
any address is still open but that can not solved until the RFC has it
written in stone that correct and valid usage of the envelope is now a
requirement, not an option.  In fact, I can see VRFY making a comeback.

I can't see any of this work working until that happens.  No enforcement
means software will need "AI" to solve the problem or SMTP will suffer the
consequences requiring acceptable of mail before anything is done which, of
course, will put a major burden on network bandwidth.  No enforcement means
most (or the smart ones) spammers will not change and that is basically what
we are doing, closing the window on them. If they want to continue, they
need to adapt, only this time we have tracking and auditing.

Ironically, I think the best thing that we have today is the one statement
in RFC 2821 Section 3.3 which layouts a recommendation for the enforcement
of MAIL FROM by actually delaying "any out of 2821 scope" validation until
RCPT is known. I can not stress enough how this small logic has been a
tremendous improvement to our software when we implemented it back in Dec
24, 2003.  Rather than have to check 2500 average connections with MAIL
FROMS, the require checking was to reduce by 31%.  No valid RCPT, no need to
bother with validation.

Finally, I wish to state that if the anonymous access spoofing problem was
less than 50% of the mail transactions, I don't think we would have such an
urgent problem to solve.  But that is not the case, in my estimates it over
70-80% and that seems to match industry research statements.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com





----- Original Message ----- 
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "IETF MXCOMP (E-mail)" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Saturday, March 27, 2004 9:22 PM
Subject: Let senders pick identities



I am going to take a different angle at the problem. Instead of
specified configuration information or identity information, lets turn
this around and say that by publishing MARID records the sender is
making statements about his email. Since this will be used mainly for
whitelisting, the truth of these statements can be used as part of the
process.

The problem with RFC2822 checking as being discussed is that we are
afraid of the MARID data being used for such checking when the sender
clearly does not want that to happen. To avoid that, just let the sender
pick what he wants but that would imply that his email is compliying
with these statements.

If so, the sender will list a bunch of IP addresses or provide MTA MARK
records, with the following statements:
1. HELO - expect all mail that uses my domain name in the HELO parameter
to come from these IP addresses.
2. MAIL FROM - expect all mail that uses my domain in MAIL FROM to come
from these IP addresses.
3. in-addr-arpa - expect all email from a given IP to be legit or
nonlegit, or perhaps tied to a domain.
4. RFC2822 - expect all email from my domain to have non-forged "From"
headers.

This is no mere suggestions for verifications, rather the domain/IP
owner is stating to the world that his email has these parameters and if
they are not fulfilled, then the emails are forged. HOWEVER, if the
sender is stating that MAIL FROM is non-forged, that does not mean that
you can do "from" verification. This way there is no guessing about what
happens - rather the sender is stating clearly what his email should
look like and what is should not look like. This gives everybody their
cake and opporunity to eat it too.

This way we don't have to choose among identities, rather we will seek
to make a mechanism that will emcompass all of them. The sender will be
free to use any of these to make statements about his email, as opposed
to have the sender and receiver guess.

Thoughts?

Yakov





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