VMN: Virtual Mail Networks (ESMTP)
Bruce Lilly
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...@example.com.SPF.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?
Andrzej Filip
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...@example.com.SPF.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...@example.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: an...@xl.wp.pl
Keld JørnSimonsen
On Sat, Feb 07, 2004 at 11:15:50PM +0100, Andrzej Filip wrote:
> [reposted from mai...@imc.org]
>
> 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.
Well, I think the current situation is quite manageable, with the RBS,
the virus checking and spam-checking software. The only thing I would
like to get rid of, is all the error reporting mails, saying that I have
sent out virus infected mail, or that I have sent mail to somebody whose
address is unknown or their mailbix is full.
I have by the way collected strings for postfix filters to discard
messages reporting bogus virus, available at
http://www.dkuug.dk/keld/virus/
Actually there is some good chances of getting rid of the bogus error
reports. We are dealing with the good guys here, so they may be able to
take proper advice.
I would advice that we recommend some best practice procedures,
hopefully to be implemented in the MTAs spftware productss of the world.
1. Always check for virus/spam before checking for valid receipient, or
whether the mailbox is full or some such.
2. Generate a specific error message, maybe we should introduce a
standard error code for this, like 551 - mail rejected as virus or spam
3. If the mail is virus or spam, then do not send it back to the
sender - as this is most likely a forged address anyway. Discard it
instead. But if you must, then use the standard error mesaage as
described above.
I think with this scheme, we would have avoided alomost all of the
virus/spam and also annoying error traffic .
No need for new protocols, closed networks etc. Maybe a need for some
RBL listing virus/spam infected machines, I don't knos.
Best regards
Keld
Charles Lindsey
In <2004021012...@rap.rap.dk> Keld Jørn Simonsen <ke...@dkuug.dk=
> writes:
>1. Always check for virus/spam before checking for valid receipient, or
>whether the mailbox is full or some such.
>2. Generate a specific error message, maybe we should introduce a
>standard error code for this, like 551 - mail rejected as virus or spam
>3. If the mail is virus or spam, then do not send it back to the
>sender - as this is most likely a forged address anyway. Discard it
>instead. But if you must, then use the standard error mesaage as
>described above.
I think the first thing you need is some standardized header that says
"this message is a bounce", preferebly giving some brief reason including
an error code.
It is much easier to filter out messages containing such a header that to
search the body for clues that might indicate its filterability.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------=
------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.u=
k/~chl
Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU=
, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4=
AB A5
Keld JørnSimonsen
On Thu, Feb 12, 2004 at 02:23:49PM +0000, Charles Lindsey wrote:
>
> In <2004021012...@rap.rap.dk> Keld Jørn Simonsen <keld@dkuug.=
dk> writes:
>
> >1. Always check for virus/spam before checking for valid receipient, o=
r
> >whether the mailbox is full or some such.
>
> >2. Generate a specific error message, maybe we should introduce a
m
>
> >3. If the mail is virus or spam, then do not send it back to the
> >sender - as this is most likely a forged address anyway. Discard it
> >instead. But if you must, then use the standard error mesaage as
> >described above.
>
> I think the first thing you need is some standardized header that says
ng
> an error code.
>
> It is much easier to filter out messages containing such a header that =
to
> search the body for clues that might indicate its filterability.
Yes, I agree that some reliable message in the subject would be a great
step forward.
Best regards
Keld