[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. ]
I managed, but it was a mistake, to ban null senders just leave the
recipient field BLANK. I haven't tested on VPN-1 but on 3.0b 3072 Solaris
2.51 it worked, although this wasn't my goal. And if I recall it matches all
& blank not sure try and see. Maybe with Sender BLANK it works correctly ?
... ... ... ...
(o o) (- o) (o -) (- -) ZZzz..
-ooO--(_)--Ooo-ooO--(_)--Ooo-ooO--(_)--Ooo-ooO--(_)--Ooo-
| | | | | | |
__|________|_ david.jank@consilium.eu.int _|______|______
| European Council Net/Sec Staff | |
______|_______|_______|_______|_______|_______|_______|__
| Windows NT - from the people who brought you EDLIN! |
_|_______|_______|_______|_______|_______|_______|______|
_ _
/_` . _ _ _ / / / ` _ _ _/ . _ _
/ / / /_'|/|//_|/ / /_; /_//_|/ /_/ / /_|/ /
-----Original Message-----
From: Amin Tora <AminT@icn.com>
To: FW-1-MailingList (E-mail) <fw-1-mailinglist@lists.us.checkpoint.com>
Date: jeudi, avril 01, 1999 6:28
Subject: RE: [FW1] NULL "Mail From:<>" headers...
>
>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
>===========================================================================
=====
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================