ietf-822
[Top] [All Lists]

Re: VMN: Virtual Mail Networks (ESMTP)

2004-02-08 03:12:57

Andrzej Filip wrote:

Sample VMN specification:
* mandatory strong SPF specification for any domain participating
(e.g. up to 10 hosts which can send messages with sender in specific
domain)
* mandatory requirement of domain reachability
(removal from VMN domains which do not accept mail for more than 4 days)
* mandatory check for open relay/proxy of any host participating in the VMN

SPF and open relay checks can be troublesome; it is occasionally necessary
for some senders to specify an alternate sender envelope address for
legitimate mail (e.g. when traveling and a different ISP is to be used
for bounces and replies).   SPF etc. might be useful for ISP-ISP transfers,
but they would cause trouble at the sender's initial SMTP session.

Believe it or not, some SMTP servers do go down; that happened recently
for a server handling an IETF mailing list -- it took a few days for
anybody to notice, then took a few more days to leave a message for the
machine's administrator (obviously email couldn't be used), and it was a
few more days before the server was back on-line.

So far, I see problems for legitimate mail traffic, and with not-unusual
outages.

The above mentioned VMN could reduce "spam as we know it" by at least
order of
magnitude by excluding most of open relays/proxies and forcing easy
identification of real sender.

So far it's unclear how you expect the scheme to exclude open relays
without also preventing legitimate mail delivery.  And nothing you've
mentioned provides any mechanism for true sender identification.

ESMTP AUTH could be used for sender authentication w/o adversely affecting
legitimate mail traffic in the cases mentioned above, but of course ESMTP
AUTH is possible (and used by some ISPs) today -- no need for "VMN".

Requirements to implement VMN
* VMN indicator in email address e.g. 
John(_dot_)Doe(_at_)example(_dot_)com(_dot_)SPF(_dot_)VMN

Gack. You want to turn the DNS-based hierarchical address scheme into a
flat namespace?  Fooey and double-fooey.

* enforcement of specific VMN rules by MTA

I'm not sure how you envision the "mandatory check for open relay" for
participating hosts. Let's suppose hosts A and B are participating, and
A wishes to send a message to B.  B checks to see if A is an open relay,
presumably by attempting to send a message to A. A in turn checks to see
if B is an open relay.  Doesn't that lead to a stalemate?

What is you opinion about this "evolutionary path" ?

You need a better "VMN indicator".  Perhaps a negotiated ESMTP extension.
Definitely not a kludge in the address.

The scope of VMN needs to be specified more clearly, and its role in
various types of SMTP traffic explained. E.g. is it intended for use
between the sender's MUA and the first-hop SMTP MTA? Or by the recipient's
SMTP MTA and connecting clients? Between SMTP MTAs and not MUA SMTP
clients (how do you propose differentiating an MUA client from an MTA
client?)?  What happens with traditional SMTP (sender's MUA SMTP client
connects to recipient's SMTP MTA)? How does it work for a sender who
has multiple ISPs and wishes to use one sender address with another
ISPs first-hop SMTP server?


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