Callback is not intended to be used by itself as a solution. As with most
of my notes, they are intermediate step when I'm evaluating ideas, I look
at good and bad in each one and look at more general idea, then I try to
mix several ones keeping good and eliminating bad points. So what you saw
in notes are more like bricks or building blocks that could be used in
the actual proposal. The reason why I posted callback notes is because it
has not been considered or discussed before and I did promise two weeks ago
to send you these notes (when I sent verification notes). My actual
proposal is based on message tracking verification and its briefly
described in last two pages of the presentation I'v already posted
multiple times, the proposal would verify both 822 header and 821
envelope (actually as you'll see pretty in one other draft soon I'll try
to minimize the distinction).
Now the answers for callback are below inline
AMEN,
It does not appear to address the fundamentals
Callback is by design design to provide MTA<->MTA verification which is
envelope (not headers which is most users see).
and is easily circumvented using
easily implemented methods (not the least of which is exploiting relays
Relays can exist but can not be exploited with callback, same for proxies.
These are some of the good points that are solved.
and/or causing DoS to 'get revenge' on some poor unsuspecting user
group.
Possibbility of DoS is a problem and has to be looked at seriously.
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?
Because of the way callback works it can not address headers and only
verifies envelope. The MAIL FROM is from ENVELOPE by design - not from
headers. Its absolutly true that most users will see forged headers and
consider what is listed in "From:" header to be the sender and this issue
must be addressed, just focusing on MAIL FROM is not a solution to spam
(which is one of my objections to RMX, other being that it breaks mailing
lists).
+ The semantics seemed confusing to me.
my $.02
-e
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg