Subject: [Asrg] Notes on Callback SMTP Transmission

From: [email-masked]
Date: Fri, 28 Mar 2003 03:13:34 -0800 (PST)

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 tranmission has use in verifying server 
listed in EHLO (this can also be done by pure dns) and prohibiting use of 
mail relays and proxies. If callback is additionally delayed it can also 
be used to determine "bulkness" of email (since you assume spammer would 
have many emails waiting for you at his server all of same or similar 
content) but drawback of delayed email communications is too great. What 
is listed in #2 and #4 are probably best as far as callback ideas. 

-----------------------------------------------------------------------
Introduction:

In normal email transmission, email communication is one way from the 
source to destination. The actual transmission may involve multiple hops
(mail servers) but in all cases the email travels one way, each time 
source or previous server in the mail path contacts next server and sends 
the data stream. As a comparison in POP3 protocol, mail is retrieved and 
there client (which is destination where mail message would end up) calls 
the server and requests to download the message.

With callback transmission, the above are combined, so now source contacts 
the destination and informs that it wants to send an email, but instead of 
actually sending email, the actual data is retrieved by destination from 
the source server. 

Technical Details on Callback proposals

1. SSMTP (from http://www.ietf.org/internet-drafts/draft-nunn-ssmtp-00.txt)
 Email is initiated as normal SMTP, instead of issuing EHLO command 
 the source issues "SHLO domain.com", if destination server supports SSMTP
 it means it knows this protocol and "after receiving a SHLO from the 
 source, desitnation mail server performs an MX lookup, then connects to 
 the IP address over port 25 and issues X-RECEIVEMAIL command (as opposed 
 to EHLO or SHLO) and if successfull answer is received, that means it 
 reached server that initiated contact (in which case original tranmission 
 source-> desttination is dropped) and destination then retrieves the 
 message using this new connection
 Pros:
    a. This allows verification that address listed in HELO is for domain 
       where email server that is sending email to the target
    b. The system completely prohibits use of mail relays and proxies that 
       are so favorite by spammers
    c. This guarantees that source server is actual server handling email 
       for that particular domain
 Cons:
    a. This will work only if there is one and only one MX listed for 
       domain in SHLO and only one server can send the message. Obviously 
       in most cases there are log more then one MX and in many cases 
       email is transmitted outbound from different servers then received 
       inbound.
    b. This will not work when source is from location under firewall 
       where firewall closed port25 or is only redirecting it to specific 
       other server, it'll not work for NAT, it'll not work for roaming users.
    c. This requires modifications to SMTP protocol or new protocol
    d. Issues to be worked out on actual retrieval (i.e. MAIL FROM, DATA 
       command susually initiated by sender, here its by receiver, but 
       receiver can only give status codes).
    e. The source server may have nothing to do with server listed in MAIL 
       FROM or From, so it does not help with forged headers
  Summary:
    This proposal is not very usefull because of the way how SMTP is extended
    and because it assumes only one MX exists for domain in SHLO. But it 
    can be noted that draft actually has a lot more good ideas and 
    extensions then just callback and as a whole it can be improved and 
    is a possible base for futher work.

2. Real-time callback to domain listed in EHLO
 Source mail server connects to destination mail server and issues 
 "EHLO server.domainname.com" command indicating its actual name. 
 The destination mail server answers and provides list of extensions it 
 supports, if one of the extensions is callback and source mail server 
 also supports and wants this function, then source server issues command 
 to request callback (CALLBACK callid). Destination server thens calls 
 source on port 25 and issues retrieve command (RETRIEVE callid), which 
 source server answers with status and immediatly with EHLO. Afterwards
 communication continues as if source server originally called in.
 Pros:
    a. This allows verification that address listed in HELO is for domain 
       where email server that is sending email to the target
    b. The system completely prohibits use of mail relays and proxies that 
       are so favorite by spammers
    c. This will work for most roaming users, for maillists, for forwarders
       as long as they all support new extensions
 Cons:
    a. This will not work when source is from location under firewall 
       where firewall closed port25 or is only redirecting it to specific 
       other server, it'll not work for NAT or for other places where 
       calling server can not listed on port 25.
    b. This requires modifications to SMTP protocol
    c. The source server may have nothing to do with server listed in MAIL 
       FROM or From, so it does not help with forged headers
    d. All mail servers in mail path need to support callback for this 
       system to be usefull and its absolutly no way to know from mail 
       connections if this true
 Summary:
   This proposal is quite usefull for verification of EHLO server and as 
   well as at stopping use of mail relays and proxies but it does require
   all mail servers to support callback

3. Delayed callback to domain listed in EHLO
 The technology is exactly the same as listed in #2, except that callback
 is not immediate and can be done within certain period of time specified 
 as answer to CALLBACK command. The destination when calling  the source 
 does not not require active previous connection and it can be noted that 
 if multiple emails are pending for destination from the same source, all 
 the email can be retrieved together in one callback session.
 Pros:
    a. This allows verification that address listed in HELO is for domain 
       where email server that is sending email to the target
    b. The system completely prohibits use of mail relays and proxies that 
       are so favorite by spammers
    c. This will work for maillists, for forwarders as long as they all 
       support new extensions
    d. This will prohibit dialup users or "hit-run" spammers from being 
       able to send email
    e. When emails are retrieved from the server if there are multiple and 
       they are all of the same or similar content, this is very good 
       estimation that this is a spam (easier to determination if emails
       are bulk, especially since spammers would generally send all emails 
       within same day)
 Cons:
    a. This will not work when source is from location under firewall 
       where firewall closed port25 or is only redirecting it to specific 
       other server, it'll not work for NAT or for other places where 
       calling server can not listed on port 25 and will not work for 
       roaming users and other locations that do not have permanent 
       internet connection.
    b. This requires modifications to SMTP protocol
    c. The source server may have nothing to do with server listed in MAIL 
       FROM or From, so it does not help with forged headers
    d. There is a presumption in email communication that emails should be 
       delivered quickly, this breaks this system as emails can be delayed  
       for unknown period of time. Discussion in emaillist is very difficult.
    e. All mail servers in mail path need to support callback for this 
       system to be usefull and its absolutly no way to know from mail 
       connections if this true
 Summary:
   This proposal is quite usefull for verification of EHLO server and as 
   well as at stopping use of mail relays and in addition helps to distinguish
   bulk emails, but tranmission time for email communication time is severely
   impacted which generally overshadows the good points.

4. Callback to server with MAIL FROM extensions.
  The source server connects to destination and destination should show 
 callback extensions support during EHLO. The source server shows support 
 for callback by listing "CALLBACK=callbackservername,calllbackid" as 
 extended parameter during MAIL FROM command. In this case either during 
 MAIL FROM or after RCPT TO, the destination server can request callback 
 by giving back special statuscode. 
  If statuscode is received, source server prepares for callback - if 
 source server is not the one listed in CALLBACK parameter as callback 
 server, the source server internally within its network connects to that 
 server and sends email there with callback id (this is done by  using 
 CALLBACK mailfrom extension and if server sees that its name as 
 callbackserver, it understands that its a client mail server within 
 same network that wants it to do relay for callback and as its within 
 same network server should know how to authenticate that client). After 
 preparation for callback are complete, source server gives command 
 "NOOP" and disconnects, at this time time destination server checks in 
 dns if callback server it got from as part of MAIL FROM is one of the 
 servers listed as MX server for domain listed in MAIL FROM.
  If this is so, destination server calls on port 25 that callback server
 and after going through typical EHLO it issues "CALLBACK callid" command.
 This should be followed by 200 ok code at which time server "change 
 positions" and the callback server sends EHLO command followed by
 RCPT TO and MAIL FROM. The destination server should verify that MAIL 
 FROM and RCPT TO are the same as it got during original call and if it 
 is so, it can accept the email.
 Pros:
    a. This allows verification that address listed in HELO is for domain 
       where email server that is sending email to the target
    b. This allows verification that email address in MAIL FROM is in fact 
       for the network that is theh source of the mail tranmission.
    c. This will work for properly setup maillists, for forwarders as long 
       as they all support new extensions and put their address for MAIL FROM.
    d. This will work for systems behind firewall and NAT and roaming 
       users, but they will all need to automaticly relay email through
       central domain server (which should have some way to authenticate 
       such firewall/roaming systems).
    d. This will prohibit dialup users or "hit-run" spammers from being 
       able to send email
    e. The system completely prohibits use of mail relays and proxies that 
       are so favorite by spammers
 Cons:
    a. Locations under firewall, roaming users and in fact any server
       that is not one listed as MX for the domain must relay the email 
       through central callback ready MX server and be able to authenticate
       there.
    b. This requires modifications to SMTP protocol
    c. All mail servers in mail path need to support callback for this 
       system to be usefull and its absolutly no way to know from mail 
       connections if this true
 Summary:
   Probably most usefull of callback proposals as it also verified use of 
   MAIL FROM but does have restrictions that all non-central mail servers 
   from domain must relay email through one of main source domain server.
   To be effective this must be implemented on all servers in mail path.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric D. Williams" <[email-masked]>
Date: Fri, 28 Mar 2003 15:04:31 -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 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:[email-masked]] wrote:
> > From: [email-masked]
> > Subject: [Asrg] Notes on Callback SMTP Transmission
>
> > 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.
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Sun, 30 Mar 2003 00:18:48 -0500

I think the point is that the attack may result from a mis-configured MTA that 
loops on the 'spam' or soem other anomaly, I don't think it would take a 
malicious user to do it, I will look again (because I like the idea of call 
back).

-e

On Saturday, March 29, 2003 7:41 PM, mathew [SMTP:[email-masked]] wrote:
> 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
>