Subject: RE: [Asrg] Re: Notes on Callback SMTP Transmission

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 28 Mar 2003 22:59:18 -0500

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 semantics seemed confusing to me.

my $.02

-e

On Friday, March 28, 2003 10:40 AM, David F. Skoll 
[SMTP:[email-masked]] wrote:
> > From: [email-masked]
> > 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Fri, 28 Mar 2003 19:45:17 -0800 (PST)

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

> 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 
> requirement.  IMHO, a requirement that addresses (My requirement #1 in 
> a later thread on this list):
>
> 
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).