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

From: "David F. Skoll" <[email-masked]>
Date: Fri, 28 Mar 2003 10:39:34 -0500 (EST)

> 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

---

From: [email-masked]
Date: Fri, 28 Mar 2003 06:27:46 -0800 (PST)

> Callback transmission is an interesting idea, but consider:
I never said its "best" of my ideas. It just something that I considered 
when evaluating various verification schemes and I actually saw some more 
problems with callback then just the ones you noticed or the ones I included
in the notes. I ended up selecting message tracking as the one I'd write 
actual draft on. But callback can still be usefull, I may come back to it.

> attempting to receive the purported mail.
Which proposal was this for #2 or #4? If #2 (callback to server listed in 
EHLO), the connection must still be maintained with the original source
that is making transmission so they'll be found pretty quickly by network 
engineers. I mean DoS is still possible but it requires the same amount of 
resource that they can otherwise already do from those same hosts to 
attack site directly, so it does not change the picture.

If its #4 (callback to domain listed in MAIL FROM command), I see your 
point since connection is made after original server closes it. But 
change to keep connection open just like in #2 can also be made.
 
> 2 - How does this fix open SMTP relays?
I meant existing ones... but that probably does not matter since they'll 
not support new system. But it certainly does get rid of proxying.

> An open SMTP relay will presumably
Since this is per-tranmission technology it'll require each relay to do 
callback.

What was not included is another is version of callback proposal 4 which 
does it differently:
  If email is received with MAIL FROM and CALLBACK and email would need to 
go futher (be relayed), this email server (relay) will try to call the next 
server that it'd otherwise going to send email to and if next server 
support callback, it'd be make a connection and provide same commands
(RCPT TO, MAIL FROM with CALLBACK) as the original call to this server 
and in this case the actual callback has to be done by that next or final 
destination server.

In the above the relay just passes on origin information and last server 
in chain that was going to deliver email does callback to pick the actual 
email data. This makes open relay effectively useless as far as spammer is 
concerned.

----
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: "Tony Preston" <[email-masked]>
Date: Fri, 28 Mar 2003 12:18:35 -0500

|From: "M Wild" <[email-masked]>
|To: <[email-masked]>
|Subject: Re: [Asrg] My ideas...
|Date: Thu, 27 Mar 2003 17:21:36 -0500
|
|> I do have some questions about the solutions/ideas talked about.  I
|> was wondering why not have the "TO:" field be required to be
verifiable
|> from each stop.   I know this would increase the bandwidth
requirements
|> of each email, but it would also prevent unidentified emails (99% of
|> the spam I get are unidentified).   If the MTA would validate on
|> arrival and unvalidated email gets rejected, you at least have an
|identified
|> user to squash when spammed.
|
|Welcome Tony - Reading this message I get the sense that you want to
|validate the From: address rather than the To:  I am contemplating
clueing
|my MTA's in to actual valid users in the domain so that I can reject
mail
|that I know I won't be able to deliver.  The thought here is to reduce
the
|bounce messages to likely invalid free email accounts.  If the list
members
|have any thoughts on why this would be a Bad Plan(tm) I am open to
hearing
|them.  My first thougth on it is that my MTA will assist the spammers
in
|weeding out invalid accounts in my domain however that is balanced by
not
|having to send bounce messages (to the tune of 28000 I'm getting rid of
now
|just to get some spool space back) to sometimes unresponsive mail
hosts.

Your right, I was thinking FROM: and typed TO:   I was not thinking it
would
be all that much of a benifit for a spammer to send you tons of mail
that all
bounced since that identifies his IP address for blocking.
|> Any solution that requires users to change their tools/upgrade/do
|something
|> different is OK, they have the incentive to do it so as to
|> get rid of spam.
|
|Um...I don't know.  I never ceased to be amazed by the number of
customers
|that we have that are using sub 200MHz Pentium boxes using IE
3.02/Microsoft
|Mail as their client software.  Some folks just don't have the patience
for
|a 25MB download.
I guess my view is that if a user wants to get rid of spam they must do
something
(like upgrade their mail tools, pressure their isp to upgrade) or I have
little
sympathy.
|> The problem has to be solved on the sending end or you do not have
|> a solution.  The only ideas that seem to make sense are the idea of
|> validating the sender at each hop (then as more and more MTAs get
|> updated to do this, the sender is better identified and can be
blocked)
|> and the idea of estamps.
|
I| disagree on this point.  I cannot control what other folks do with
their
|MTA's  I *CAN* control how my mail servers are configured, what
software
|they run and whatever else it takes to, if not solve, at least reduce
the
|problem.  This paragraph also supports my initial assertion that you
want to
|validate From: addresses.  This has been proposed in other threads and
the
|question that comes to my mind is "Isn't that what VRFY is for?"  I may
be
|mistaken.  Again, I appeal to the collective wisdom of the list.
|
|Regards
|Mike
That is my point, you cannot control what other people do, but on your
system
you upgrade to the super-duper spam detector and you help all those
downstream
to your system.  It reduces your load because you only receive them and
don't have to send them on.   The closer you get to the sender at
stopping spam,
the greater the benifit.

---

From: mathew <[email-masked]>
Date: Sat, 29 Mar 2003 19:41:24 -0500

On Friday, Mar 28, 2003, at 10:39 US/Eastern, David F. Skoll wrote:
> 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.

That's really no different from the same person having the 0wned hosts 
directly DDoS the victim, or having the 0wned hosts send out ping 
packets with the victim's IP address. Already illegal most places, and 
the spammer already has the capability, so the proposal isn't making 
anything worse.

I think that objecting to a proposal because it allows bad guys to 
mount an attack they can already mount is a bit nit-picky.

mathew