Re: A flood of spams - another virus on the way?

From: JF Mezei (jfmezei.spamnot_at_istop.com)
Date: 09/20/03 

Date: Sat, 20 Sep 2003 16:42:19 -0400

Don Sykes wrote:
>
> As I've been complaining about recently, I can't even get the HP SMTP
> service to check incoming messgaes for a valid user during the initial
> connection, which IIRC could be done in the 2nd step of the connection
> process!

If you are talking about HP.com's SMTP service, they have had fairly agressive
spam blocking in effect for some time (as well as Compaq before the merger).
Many of us had had problems reaching a Digital employee within Compaq or HP at
one point or another.

If you are talking about the Digital TCPIP Services for VMS, since 5.1 or 5.3,
it has had RBL capabilities to block much of the spam.

The only valid information an SMTP server can have during reception of a
message is the IP address of the remote sender. All other information is
unverifiable. Also, by the time the SMTP server has gone into DATA mode to
accept the contents of the message, it MUST accept the message and then send a
non-delivery notification if it decides that the contents ofthe message were
not acceptable. (note that RFC 822 headers are considered content at this
stage of the transport).

typically, a SMTP session would look like:
-----------
HELO <chocolate.com>
MAIL FROM: <chef@chocolate.com>
RCPT TO: <elves@cookies.com>
DATA
Received from: <received from text>
From: "Chef Pierre" <chef@chocolate.com>
To: "My little elves" <elves@cookies.com>
Subject: Chocolate coating for your cookies
Date: 31 Feb 2005 22:35 EDT

Dear Elves,
It would be a great pleasure for me to supply you with the 3 tons of melted
swiss chocolate to coat your cookies. We will use a Canadair CL-415 water
tanker to do an aeral dump of the chocolate over your factory. Make sure your
cookies are laid out on the roof by 16:00 tomorrow.
. 

---
Most SMTP servers simply add a Received: line, regenerate the Reply-Path: line
(on top of headers, and is taken from the MAIL FROM:). Most will also check
for a valid Date: line. However, for the remainder of ther RFC822 header, you
cannot really check much. And in terms of checking the contents, it is very
CPU intensive, especially if checking for viruses in attachements etc.
(Consider that the RFC header is often updated AFTER the virus checking is done).
Remember what the first letter of SMTP stands for. Remember that in its
origins, it had to deal with very interesting adresses when you had uucp and
bitnet adresses that were gatewayed to SMTP email.
The mail client only sees the RFC822 headers, it doesn't see the 821
conversation between the two SMTP servers. But the receiving SMTP server can
do a lot during that conversation to check validity of the message. It can
check to see if the true IP address of the sending server maps to some DNS
entry. If relaying is disabled, it will ensure that the RCPT TO: is within its
own domain. However, there isn't much one can do with the HELO and MAIL FROM:
in terms of validation because there are many legal cases where the sending
SMTP server was legally entrusted with mail coming from a different domain so
the MAIL FROM: may not match the real domain name of the IP adress of the SMTP
server sending this message. (consider UUNET which owns ozemail in australia.
Some of the SMTP servers reverse map to a UUNET domain name even though the
mail from is an ozemail.com.au address.
The RBL mechanisms work almost exclusively with the IP address of the sending
SMTP server, the only trusted piece of information the receiving server gets
(it is obtained from the TCPIP stack during call establishement, and for
responses to make it back to the sending SMTP, the IP must exist and have
routes back to it).
When you consider the number of intranets and NAT protected firewalls, it
becomes even harder to start to impose rules on SMTP to ensure legitimate
emails. My SMTP server thinks it is 10.0.0.10 but to the outside world, it
appears as a true internet address. And in a multi-homed network, you may have
multiple domains attached to SMTP server, so you must allow people inside your
intranet to send to the outside with a From: that could be anyone of those
domains that are multihomed to you. So the mail client may generate an email
from elves@cookies.com while the SMTP server may reverse translate to
chocolate.com.  Will you block those emails even though they are perfectly
legitimate and not spam ?
Also, when you consider that not all of the world uses normal roman alphabet
and that such languages usually encode their names so that when read on a
ascii terminal, it looks like jibberish. Will you block all From: that appear
as jibbererish ?

Relevant Pages

  • Re: A flood of spams - another virus on the way?
    ... > If you are talking about HP.com's SMTP service, ... Yet another effect of Spam. ... by the time the SMTP server has gone into DATA mode to ... he'll most likely get the NO SUCH USER response. ...
    (comp.os.vms)
  • Re: Font in Inbox larger........
    ... SMTP server, and I don't recall what that server name is. ... Gary VanderMolen, MS-MVP (Mail) ... Norton Antivirus) I had AVG for a long time and decided to go back to Norton ...
    (microsoft.public.windows.vista.mail)
  • Re: Email programs that work.
    ... multiple accounts since one wouldn't want the same filters to apply to all ... All my home filters only apply to my home mail. ... simple SMTP interface so they can do away with the command line altogether. ... the fact that it passes through an SMTP server prior to the work ...
    (Debian-User)
  • Re: Outlook Access permission
    ... library in Windows 2000 and 2003 to create and send messages through an SMTP ... Sue Mosher, Outlook MVP ... >>functions to use an SMTP server. ... >>programming langauge on the computer. ...
    (microsoft.public.outlook.thirdpartyutil)
  • Re: Analysis of an MSN rejection.
    ... and suggest that the sender needs to use their own ISP's SMTP ... >> Mercury SMTP Server: ... > server which accepted the message for relay. ... > and IP addresses are irrelevant in this case; SBC Yahoo! ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)