Re: A flood of spams - another virus on the way?
From: Don Sykes (anonymous_at_pacbell.net)
Date: 09/21/03
- Next message: tutor_at_nospam.cfl.rr.com: "vax/vms cobol job?"
- Previous message: steved: "Re: newbie multinet, wasd question"
- In reply to: JF Mezei: "Re: A flood of spams - another virus on the way?"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: A flood of spams - another virus on the way?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 21 Sep 2003 00:13:47 GMT
JF Mezei wrote:
>
> 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.
Yet another effect of Spam.
>
> If you are talking about the Digital TCPIP Services for VMS, since 5.1 or 5.3,
Sorry. I should said HP TCPIP Services for VMS.
> it has had RBL capabilities to block much of the spam.
That doesn't seem to help very much. I still get 100s of spams a day and
this method also requires my server to make yet another internet call to
the RBL service to find out if it's on their list. And remember that's
AFTER the spam has taken n hops consuming valuable router cycles and
bandwidth.
>
> 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).
I think you missed my point. If RFC*** cannot implement a legitimate,
workable email service without this onslaught of crap than RFC*** needs
to be changed. We're talking about software here and one of the most
elegant things about software is that it can be changed so easily. That
is not to say the changes wouldn't have great impact on other software.
What I'm suggesting IS drastic, but drastic problems require drastic
measures.
>
> typically, a SMTP session would look like:
> -----------
> HELO <chocolate.com>
> MAIL FROM: <chef@chocolate.com>
> RCPT TO: <elves@cookies.com>
Yes. Right here I want say NO SUCH USER and drop the link.
And I don't care if chef@chocolate.com is valid or not. If he's valid
he'll most likely get the NO SUCH USER response. If he's fictional, I
don't want to waste another nanosecond on him. Even if he IS valid and
doesn't get the message because his ISP is down or something, I don't
want to bog down my SMTP service trying over and over to reach him to
tell him he used a bad address. If chef really wants to find out if the
elves got the message, he can request a receipt.
> 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.
> .
Chef,
That will do fine. For your convience, we'll leave your check on the
roof as well.
The Elves
> ---
>
> 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).
Virus checking is problematic for a lot of reasons, but I wonder what
solutions the ISPs would come up with if THEY were held financially
responsible for transmitting them?
>
> 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.
You mean were using an outdated protocal that can't shed its old skin as
it grows? - I'm shocked! :)
>
> 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 ?
No. Assuming your multiple domains are all registered to you. If your
email showed up on my doorstep with a 10.0.0.10 in the senders address I
would expect to be able to translate that to chocolate.com. If I can't,
I would assume it's junk. The fact that the MAIL FROM: showed
elves@cookies.com would not concern me as much, but there needs to be a
method to insure that cookies.com users are authorized to send email
from chocolate.com.
>
> 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 ?
If they want me to be able to read them, YES! It should be the
responsibility of the sender to insure the MAIL FROM: is readable by the
receiver in their language & alphabet. The rest of the message can be
encoded Greek.
-- Have VMS, Will Travel Wire paladin, San Francisco (paladinATalphaseDOTcom)
- Next message: tutor_at_nospam.cfl.rr.com: "vax/vms cobol job?"
- Previous message: steved: "Re: newbie multinet, wasd question"
- In reply to: JF Mezei: "Re: A flood of spams - another virus on the way?"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: A flood of spams - another virus on the way?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
