ietf-822
[Top] [All Lists]

Re: VMN: Virtual Mail Networks (ESMTP)

2004-02-08 04:20:33

Bruce Lilly wrote:
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

What I posted was not "the only reasonable VMN". It was merely an example of one of many possible VMNs.

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.

So "the sample VMN" may specify separate policies for initial submission e.g. SMTP AUTH to MSA port (587).

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.

So you say that "remove from VMN" timeout proposed by me was too short.
But it would be nice too keep list of active domains and make initial MTA avoid kludging its queue with messages to domain with long period problems.

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.

Now we have DNS based "black list", DNS based "white list" have been already proposed (with periodic automatic retests).

And nothing you've mentioned provides any mechanism for
true sender identification.

SPF is not "true sender identification" but an "SPF like" method can significantly reduce the problem.

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".

You are right for MUA->MTA transmissions but how SMTP AUTH is supposed to authenticate sender for MTA->MTA transfers ?
SPF idea is a step in right direction for MTA->MTA transmission.
[ I do not say that SPF itself is optimal]

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.

?!
MTA would treat the above address as:
'John(_dot_)Doe(_at_)example(_dot_)com' via 'SPF' virtual mail network

I can see no flat name space.

* 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?

I have mentioned use of DNS based "white lists" already.

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.

My design was driven by desire to make VMN available to unmodified email clients and restricting modification only to MTAs.

I treat my addressing scheme proposal as option zero to be replaced ASAP if a better scheme is proposed.

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?)?

My idea was to limit requirement for MUAs and make it available to unmodified MUAs: * MUA->MTA : modified recipient address used by client, optional requirement to use SMTP AUTH to MSA port
* MTA->MUA : "X-VMN-Name:" header generated my MTA

VMN requiring "SMTP AUTH to MSA port" may treat check VMN policies per "recipient" assuming that the other side is MTA.

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?

It is up to the specific VMN to decide.

OT: It is possible to use "mail in signed mail" relay.

--
Andrzej [en:Andrew] Adam Filip http://anfi.freeshell.org backup: 
anfi(_at_)xl(_dot_)wp(_dot_)pl


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