On Mon, 06 Jan 2003 18:08:44 EST, Doug said:
You can tell the difference between 1, 2, and 3 because they all have
a different DNS/IP footprint.
They do? Are you sure of this? I'll give you a hint - if you're outside
the two /16's of our network, and you get an inbound SMTP connection from us,
looking up the PTR to get the hostname will almost certainly *NOT* have
the string 'mail' in it.
And the inbound and outbound mail servers at ietf.org are called 'odin' and
'ran', respectively.. Not much info there.
And last I heard, about 30% of the PTR space is broken beyond use due to
cluenessness on the ISP's part, so you can't get a DNS name you can trust.
So what DNS/IP footprint were you planning to use?
You can send email directly to the IETF mail server?
Yes, sometimes multiple times an hour if I'm in a verbose mood...
Do you have an
account on that server?
Nope, no account there. Don't need one, works fine..
I myself use a SMTP server to send out my email. It goes from my email
client to the SMTP server I happen to be using and it then gets
relayed through the network until it reaches the destination email
server.
OK.. to be *very* pedantic, I use an SMTP server as well. My MUA (Mail
User Agent) exmh hands the mail to the SMTP server I happen to be using,
and the SMTP server relays mail everyplace. It just happens that my preferred
SMTP server happens to be already running on my laptop....
I am not suggesting that the destination email server should ask for
authentication for every email it receives before it relays it on to
another mail server or a client. I am saying that the originating
server should ask for it before accepting it and relaying it on to the
network.
Aha. I see now. What you *want* is what all properly run mail servers
*ALREADY* do. It's amazingly useful for tracking down users that are being
silly and need a slap upside the head to clear the kloo blockage. What
it's NOT useful for is stopping the determined spammer who doesn't use
your mail server to inject the mail into the net....
The reason it doesn't stop spam is because you're missing an important
point - you seem to think that "if the sending server validates the user,
we won't have spam.."
authenticate with the server. This in effect means that you cannot use
a different return/reply address (or a fake return/reply address) that
Hmm.. so the mail I'm replying to wouldn't work, because I got it from the IETF
server
but it has your From: address on it - therefore the IETF server must be
lying about who it is and who the sender is.
Actually, that's not quite true - there's usually
cannot be traced back to your account on the originating server by the
recipient or an IP/DNS footprint that cannot be traced back to your
machine or a point on your network by the recipient. This is to force
the person sending the email to be accountable for the email sent.
OK.. and this is *forcing* it *how*?
Think carefully here - the receiving end is trusting what the sender
sends.
and account status on that server. The server would then tag
information onto the email that would identify the machine on which
the email client that sent the email resides (not the information of
an unsecured proxy). In addition, the originating server should tag
information that identifies the account (on the originating
server/network) that the client used to send the email and force the
originating client to provide a valid reply address that is associated
with the account to the recipient of the email.
And of *COURSE*, not even a SPAMMER would be so unrighteous as to forge
a "this mail was approved" header.
This mail has a 'X-Verified-Sender-Address:' header that identifies
the originating address. Take a look at it, and tell me if you feel any
better about having verified the origin. And remember that since I control
my machine, I can make a similar change to any *OTHER* header (From:, Sender:,
X-Authenticated:, or whatever).
And the spammer controls his server....
/Valdis
pgppsS8SpgGDz.pgp
Description: PGP signature