[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] NULL "Mail From:<>" headers...
[ The following text is in the "iso-8859-1" character set. ]
[ Your display is set for the "US-ASCII" character set. ]
[ Some characters may be displayed incorrectly. ]
Alrighty people... here is what ORBS has to say about denying NULL From:
fields:
==start excerpt==
> This directly states that I should not implement step three of
> your "checks" against my SMTP gateway (eliminating the null
> email from), as it can cause more problems than it solves for
> our users.
Not quite. All the SMTP checks should be aimed at preventing
relaying, not to reject senders outright. Even an external null
sender has no reason to relay via your server to another server
unrelated to your operation and should be denied access if this is
attempted.
==end excerpt==
Basically, they want you to deny any mail with null From: fields relaying
via your SMTP server to a domain not belonging to you. However, if the mail
with the null From: field is directed to your domain, then you can still
allow it.
My question here is, by following the above recommended deny and allow
scenario, will a secure SMTP gateway be "violating" the RFC ?
Next question that remains unanswered is:
How do I check for the null From: fields.. if I am to implement the above
deny and allow rules...??
I tried *@* and it doesn't work!...
.peace.
Amin Tora, Internet Engineer
ICN - Internet Solutions Group
Phone: (703) 550 - 0101 x514
Fax: (703) 550 - 7697
mailto://amint@icn.com
http://www.icn.com
-----Original Message-----
From: Paul D. Robertson [mailto:proberts@clark.net]
Sent: Wednesday, March 31, 1999 7:17 PM
To: John Selph
Cc: FW-1-MailingList (E-mail)
Subject: Re: [FW1] NULL "Mail From:<>" headers...
On Wed, 31 Mar 1999, John Selph wrote:
> >
> > This is a bad idea. That's how the SMTP protocol handles some bounce
> > messages to stop bounce loops. Your users will be unable to find out
that
>
> I can tell you why it's being done. I think the Internet is in what may
some day
I know *why* it's being done, and I also know *why* it's a bad thing to do.
> be known as the Spam War Days. We have the spammers, the anti-spammers
> and the people caught in the middle. A few months ago our mail server got
hit
> as a relay with me thinking it was blocked. So here we go, the flood of
"how
> dare we" emails. None of these "so called" spam haters acted against the
> spammer, only us the victim relay. I emailed the host site of the spammer
and
I've never gone after a relay where it was obvious it was a relay. It's
rarely obvious though given that some spammers forge headers to go in
front of the last hop. Since your system forwarded the mail, it is
indeed your repsonsibility.
> got their web site shut down MYSELF. Anyway I digress, so because of this
You should be the one to go after the relay - it's *your* resources
that were directly abused and it's *your* system that was configured to
allow 3rd party relay. Intentional or not, the burden of responsibility
is fairly and squarely yours.
> act we get listed in WWW.ORBS.ORG. No problem I change everything, block
> relaying (at 2 levels no less). ORBS still isn't happy, so I emailed and
asked
> them what else I was suppose to do. They told me to block FROM: <>
> addresses. Even if it doesn't relay the email, they want you to not
accept that
> at all. Well ok, I wanted off the list of course. Anti-spammers seem to
have this
This is complete bull, and you should tell them that *and quote the RFC*.
I've not dealt with ORBS, but a legitimate blocking site like RBL
wouldn't require you to violate the RFCs so blatently, and the ORBS people
are being complete idiots if they indeed think this is a good idea. Feel
free
to point them my way if they continue to insist that non-relayable mail from
a
null sender should be blocked and you don't feel up to discussing why the
SMTP
protocol shouldn't be purposefully broken.
While I sympathise with your plight, it's no reason for you to break my
mail system. Can you tell me a good reason to accept several hundred
e-mails a day at my gateway that are going to queue bounces that will be
rejected and tie up useful bandwidth for the retry interval necessary to
ensure proper mail delivery? What happens when that becomes several
thousand and then tens of thousands? You're defending blocking
legitimate bounce messages, so what's your solution to bounced mail?
> "I got a spam email, screw the world I want it stopped" attitude. Like
there is an
> electric shock on their delete key. Meanwhile it's us system managers
that are
> getting blamed from both sides because users want it both ways, no
restrictions
> and no spam.
How do you propose that your users find out they mispelled addresses,
their friends moved, their customers aren't wherever anymore, or any of the
other things that happen when an SMTP system bounces a mis-addressed mail
with
mail from:<>? Why should my mail system have to keep bouncing invalidly
addressed mail from your users when my RFC compliant mail system has
attempted to notify the user in question that their mail is undeliverable?
If everyone had it your way, at some point 20% of the mail being
exchanged between sites will be for users who have moved on. How does
your own mail system bounce mail to an invalid address, or is this a case
of "do as I say, not as my system does?"
If you don't like the SMTP protocol, by all means come up with an
alternative, get it through the IETF and give us an RFC that both allows
non-deliverable messages to be returned _without_creating_bounce_loops_ and
(optionally) solves the anti-spam issue. Until then, we have a mechanism in
the SMTP protocol that allows non-deliverable messages to be returned. If
you
aren't speaking the SMTP protocol they you shouldn't be allowed to play
with SMTP servers. SMTP is a *standard*, the protocol is well-defined
and breaking this portion places undue load and worse yet causes
end-users to believe mail to be delivered that isn't.
I'm prepared to break and accept the breaking of portions of the SMTP
protocol in the case of spam that result in mail to my users not being
delivered, but rejected. I'm not prepared to harm anyone else's mail system
in doing so. Why are you so quick to cause my mail system ill?
I didn't create spam or spammers. One of my several hundred
responsibilities
is to run a functional mail system. If one of the perpetual victims that
keep complaining about the issues but do nothing to solve them would like to
propose a solution that doesn't break mail then I'm all ears.
Until then, blackholing sites that degrade my mail system's performance
seems to be my best option. Once the total of your rejected mail gets to be
above a threshold value you're comfortable with you'll probably see my
point.
Bouncing a user's mail for a *year and a half* from a site that doesn't
accept standards-based delivery failure notifications doesn't work for me.
If they're prepared to fill my queues with mail that will bounce and then
reject the bounces, what other parts of the RFCs are they prepared to
toss aside that will cause my mail system harm?
I'd love to hear a workable alternative that still meets the SMTP
standard. If you don't have that, then you really shouldn't be
advocating breaking the protocol.
Paul
----------------------------------------------------------------------------
-
Paul D. Robertson "My statements in this message are personal opinions
proberts@clark.net which may have no basis whatsoever in fact."
PSB#9280
============================================================================
====
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
============================================================================
====
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================