AMEN,
It does not appear to address the fundamentals and is easily circumvented using
easily implemented methods (not the least of which is exploiting relays and/or
causing DoS to 'get revenge' on some poor unsuspecting user group. It is well
thought through however and to me represents an attempt at addressing of a
requirement. IMHO, a requirement that addresses (My requirement #1 in a later
thread on this list):
The proposal MUST address the issue of RFC821 [or envelope protocol]
originating MTA/MUA authenticity.
However, after reviewing the draft I would make the following points:
+ Some of the elements appear to mix RFC822 header functionality with RC821
envelope functionality, is this intended or just begging for yet another
revision to 821?
+ The section 4.0 stuff is a bit mis-leading, errors in the message
verification checks suggested (bogus verification checks) a client could
potentially lead to loss of message, for instance a so-called bogus message
verification token may have a name space collision with a valid message or with
a message in 'transit'. What are the client validation message (so that the
server does not arbitrarily drop messages on 'validation') envelope semantics,
e.g. how does the server know the verifying client is the recipients client?
Thanks,
Eric
On Friday, March 28, 2003 10:40 AM, David F. Skoll
[SMTP:dfs(_at_)roaringpenguin(_dot_)com] wrote:
From: william(_at_)elan(_dot_)net
Subject: [Asrg] Notes on Callback SMTP Transmission
As promised I'm sending you notes on callback tranmission. This notes
are similar format as verification notes I sent before and in fact I had
them done together.
Callback transmission is an interesting idea, but consider:
1 - NastySpammer sends millions of connections from thousands of 0wned hosts,
and suddenly poor victim gets a DDoS from all the callbacks from hosts
attempting to receive the purported mail.
2 - How does this fix open SMTP relays? An open SMTP relay will presumably
set itself as the host to call back. In fact, how does this interoperate
with SMTP relaying?
--
David.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg