Transaction-based IP email protocol

At least 97% of the email I receive is junk mail that I don't want in my
inbox. Most of it has forged headers. Why isn't there a protocol that can
confirm that the routing information contained in the headers is valid? The
receiving end server should be able to link to the sending server for
confirmation before it accepts an email.

N
Tue Nov 25 21:31:41 CST 2003

In article <3fc3c18c$0$185$a726171b@news.hal-pc.org>,
BillyBubba@LittleRock.Gov says...
> At least 97% of the email I receive is junk mail that I don't want in my
> inbox. Most of it has forged headers. Why isn't there a protocol that can
> confirm that the routing information contained in the headers is valid? The
> receiving end server should be able to link to the sending server for
> confirmation before it accepts an email.

The routing information is a part of the body; except for that which the
receiving server will create after accepting the email for delivery. In
other words, the receiving SMTP server won't have access to the routing
details until after it accepts the message for delivery. Messages, once
accepted, should not be bounced because of the possibility of forged
"Return-Path:" addresses (derived from the "MAIL FROM:" part of the SMTP
process). That is why my server is set to reject during the SMTP
transaction; I don't bounce email at all.

There are applications that parse the message headers for fraudulent routing
details, but they need the downloaded message to do their magic; and once
they start processing the message, it is too late for a "User not known"
error type bounce.

--
Norman
~Win dain a lotica, En vai tu ri, Si lo ta
~Fin dein a loluca, En dragu a sei lain
~Vi fa-ru les shutai am, En riga-lint

Rolls
Wed Nov 26 15:34:22 CST 2003

How do I look at routing information that is not in the headers if I don't
see it in the message body/text? Abuse@<domain> wants the full message plus
full headers which I copy/past into the forwarded email. If headers are
forged how can anytrhing be traced?

N
Thu Nov 27 04:42:51 CST 2003

In article <3fc51c61$0$182$a726171b@news.hal-pc.org>,
BillyBubba@LittleRock.Gov says...
> How do I look at routing information that is not in the headers if I don't
> see it in the message body/text? Abuse@<domain> wants the full message plus
> full headers which I copy/past into the forwarded email. If headers are
> forged how can anytrhing be traced?

I see. I think I misunderstood your question. I attempted to describe what
happens during the SMTP transaction between two MX servers, but you are
concerned with what happens when you pull your email from your POP3 server.
And the receiving end server is linked to the sending end server; but there
is no way to validate anything beyond the IP address, HELO string, MAIL
FROM: address, and RCPT TO: address at that time; that is all the receiving
server has to go by. The receiving MX can reject the message at this point;
but once it decides to accept the email, there is no checking of the routing
information contained in the DATA block. From the point where the receiving
server said, "Send DATA", the information is an uninterrupted stream from
the sending server. And once the receiving server sends "message queued for
delivery", it is pretty much all over; and you have the message.


Unfortunately, POP3 servers would need to run code like the SpamCop.net
parser to check the validity of the headers. That is not a trivial, or error
free task. It would be a load, and strain on the servers. Your ISP would
have to buy more hardware, and you'd have to pay for it in your service
bill. And you would still face the possibility of false positives and false
negatives.

--
Norman
~Win dain a lotica, En vai tu ri, Si lo ta
~Fin dein a loluca, En dragu a sei lain
~Vi fa-ru les shutai am, En riga-lint

Rolls
Thu Nov 27 14:08:25 CST 2003

Thanks. I think that I now understand e-mail is not secure and that headers
may contain unreliable information. It appears that almost all headers
associated with the most annoying spam are forged/altered. To deal with
spam in OE I'm using K9 set to reject everything except for the whitelist
rules I've set up. I don't think this program is reliable in the automatic
self-training (wordlist) mode, but it does switch incoming emails between
Inbox and Spam folders reliably using its override filters. Also have
Norton AV (free trial) and will use AVG after that. I check Win Update (XP)
and Office (2003) Update very frequently. Using K9 I'm able to keep my
inbox clean. Every few days I check the Spam folder to see if anything was
rejected that should be accepted, set up the appropriate whitelist rule,
then delete all the spam messages. My ISP has a filtering service for
$extra, but it's no better than K9, and K9 is both simpler and free. Some
of these features may already be in Outlook/OE and if not eventually they
might be.

I gave up on returning spam to abuse@ due to unreliable headers.

Messenger is running in the background. Personal friends and I have mostly
switched to Chat instead of using e-mail.

Too bad that internet e-mail has a signal-to-noise ratio of 1:30 due to so
mush spam.