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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg