On Sun, May 13, 2001 at 04:13:43PM +0530, Suresh Ramasubramanian wrote:
> Using a large mallet, Horace G. Friend III whacked out:
>
> > I read from the RedHat Sendmail HOWTO that the forward and reverse DNS
> > "should" match. This became necessary due to the proliferation of spam
> > mails on the Net.
>
> Then they are wrong about it. Could you paste the relevant section into a
> mail (and maybe mail me offlist or take this to news.admin.net-abuse.email -
> either of these will be more on topic to mutt-users) :)
The document doesn't say that "the forward and reverse DNS should match"
but this is what I gathered from reading paragraphs 3 and 4 of Section
4.1.2 of the faq, and I quote:
4.1.2 Masquerading, relaying and a word about UCE
The masquerade lines shown above are critical. YOU MUST HAVE THESE
LINES IN ALMOST ALL CASES for the stand alone environment using a
dial-up connection. Why is this so important? Let's compare an email
message to a letter sent through the postal service. When you address
the envelope you provide several pieces of information so the postal
service can do their job correctly. You would write the person's name
and address that you want to send it to and you would also write your
name and mailing address so that if the letter can't be delivered, it
can be safely returned to you. After you post the letter what does the
postal service do? They pick it up and attempt to deliver it based on
the information you provided.
Now, if you had a criminal mind and wanted to mail something malicious,
you wouldn't put your correct return address on the envelope would you?
Probably not. If you put a false return address and the message was
ultimately undeliverable the postal service wouldn't be able to return
it to you. In this example, everything is very anonymous and you can
send out garbage without being held accountable. Just a few short
months ago, Internet based electronic mail worked the same way. You
could send out garbage with a false return address and it wouldn't be
returned to you if it proved undeliverable. Granted, this is not a very
nice thing to do but it happens all the time.
In order to eliminate this abuse the people who develop code for Mail
Transfer Agents (MTAs -or- the post office in our scenario) started to
tighten things up a little bit. These much improved MTAs now check that
the sender's envelope address is valid before they will relay, or
deliver, a message. What this means is that the post office
transmitting the message must exist... it has nothing to do with the
from address. This is a good thing but it has caused problems for many
people, particularly those who use an MTA rather than client software
to send their mail... translation... the dial-up user with a Linux box
is likely to get a bunch of bounced mail unless he or she configures
their MTA to properly masquerade the envelope and relay through their
provider's MTA.
It's not enough to set the From: and Reply-To: addresses in a piece of
email client software because, much like a regular letter, all this
does is tell the person who receives the message who it's from
(maybe). The newer versions of sendmail (particularly since the
release of 8.9.1) and other modern MTAs are more concerned with which
mail server or MTA it was sent from than they are with which user sent
the message so they read the message envelope. They're not looking for
the person that sent it by checking the sender's From: or Reply-To:
email address, they're checking to see if the post office, or MTA, the
message came from is a valid host and that the domain is also valid.
This is equivalent to checking the zip code of origin on a letter.
Once this information is excerpted from the message it's verified via
reverse DNS to see if the sending post office and the ?From: domain
exists (in other words, would the sending MTA would receive a bounce
if the intended recipient didn't exist) and if that post office (the
sending MTA) or the domain does not exist, then the receiving MTA will
reject the message. We fix this by configuring our MTA to masquerade
the envelope and then we relay our messages through our ISP's mail
host which gives our mail the final stamp of legitimacy it needs.
Paragraph 4 says that a reverse DNS is done to verify that the source
(mail server or MTA) of the msg is valid. And the receiving mail server
does this by doing a reverse DNS.
And I guess this is the reason why iname.net appended "maybe forged" in
it's Received header.
Okay, the doc says nothing about the forward and reverse DNS that
"should" match for mail transfer to take place, but I think it's "BAD"
practice for any mail server to use non-matching forward & reverse DNS.
"Am I getting confused?" :)
>
> > I guess by clean, I meant spam free.
>
> right
>
> > Honestly, I'm not looking for a 100% spam-free environment because
> > that's next to impossible without blocking other legit mail.
>
> tough :)
>
> > What get's my goat is that someone (and outblaze.com tops the list)
> > intercepts mails and/or pretends to be someone else. Here is the header
> > >from the Java Developer Connection Newsletter which I subscribe from.
> > It's even got a "Precedence: Junk" in it. Can you believe that?
>
> its a standard feature of an MTA man, and Precedence: Junk is inserted by many
> mailing lists so that mailservers can allot lower priority to list mail (and
> autoresponders)
>
> > Received: from spf8.us4.outblaze.com (205-158-62-35.outblaze.com
> > [205.158.62.35] (may be forged))
> > by smv19.iname.net (8.9.3/8.9.1SMV2) with ESMTP id DAA20037
>
> from sun. the outblaze <-> mail.com handoff is an internal thing which you
> can ignore safely
>
> > From: JDC.C&[EMAIL PROTECTED]
>
> they are wrong in not qualifying their address - and in using & in the address
> :)
Okay, so it is a standard feature. I'm just wondering how come they are
sending me this bulletin that they've classified as "junk" when I am a
subscribed member and receive several mails from them regularly
regarding their promos and all sorts of things with nary a complaint. :(
Maybe it's about time I should ask them for some answers.
Thank you all for making this a very enlightening and frustrating
exercise in trying to block spam and learning how to verify legit mail
by taking a look at mail headers for any signs of forgeries.
>
> --
> Suresh Ramasubramanian + Lumber Cartel India - <tinlcI>
> mallet @ cluestick.org + Wallopus Malletus Indigenensis
> EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
--
Horace G. Friend III
[EMAIL PROTECTED]
GnuPG DSA/ElGamal Key Fingerprint
9295 80C4 C723 621B 9C2D B53E D432 7936 4CA9 8AD6
