Of all the messages that we have received to this particular mail server
that come from a sender of <>, 100% of them are *SPAM*
I don't want to bounce them back, I simply want to dump them into the bit
bucket.
Dave Grabowski
System Arts, Inc.
(212) 604-9015 x316
[EMAIL PROTECTED]
"Paquette, Trevor"
<Trevor.Paquette@attc To: "'[EMAIL PROTECTED]'"
anada.com> <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
05/26/2000 02:12 PM cc:
Subject: RE: [FW1] Blank MAIL
FROM: field in SMTP Security
Server
When email from "<>" arrives at a site, this is 99.99% of the time a
message
stating that the email was an 'undeliverable'.
NEVER send a reply back to a blank address, not matter what the 'reply-to'
header shows.
This can cause mail loops, as we have seen with some sites.
All email from "<>" should be directed sent to a human to deal with,
resolved and then deleted.
------
>From RFC-821 Section 3.6
If a server-SMTP has accepted the task of relaying the mail and
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).
This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:<>
An undeliverable mail notification message is shown in example 7.
This notification is in response to a message originated by JOE at
HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
to HOSTZ. What we see in the example is the transaction between
HOSTY and HOSTX, which is the first step in the return of the
notification message.
--
The early bird gets the worm, but the second mouse gets the cheese..
Trevor Paquette | AT&T Canada |Work:(403)705-6390
[EMAIL PROTECTED] |600, 205 5th Ave SW | Fax:(403)705-9601
http://www.metronet.ca |Calgary, AB, Canada |ICBM:51'03"N/114'05"W
Senior Unix Network Architect| T2P 2V7 |Mind:In the Rockies
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 26, 2000 11:30 AM
> To: [EMAIL PROTECTED]
> Subject: [FW1] Blank MAIL FROM: field in SMTP Security Server
>
>
> I've gone through the archives of this list, and this same question was
> asked a little more than a year ago. Lots of discussion ensued, but I
> couldn't find the resolution.
>
> Here's the story: We're running FW-1 4.0. Behind the firewall, we have a
> mail server that hosts POP3 mailboxes for about a dozen different
domains.
> Users have configured their mail clients to use this server for both POP3
> and their outgoing SMTP.
>
> Because the clients use it, the SMTP server receives two types of e-mail:
>
> 1. Messages destined for mailboxes belonging to the various domains that
> we
> host (domainA.com,domainB.com, etc)
> 2. Messages from users of the various domains that we host, going to any
> other domain
>
> I've written two separate resource-based rules to handle these:
>
> SRC DEST SERVICE ACTION
> <any> <our mail server> smtp->to-clients accept
> <any> <our mail server> smtp->from-clients accept
>
> smtp->to-clients is a resource defined as: Match Tab -> Sender=blank,
> Recipient=*@{domainA.com,domainB.com, etc}
>
> smtp->from-clients is a resource defined as: Match Tab -> Sender
> =@*{domainA.com,domainB.com, etc}, Recipient=blank
>
> Both rules function as expected.... EXCEPT if the MAIL FROM: field in the
> SMTP message itself is *BLANK* (i.e., <>). The second rule will still
pass
> the packet:
>
> Escape character is '^]'.
> 220 CheckPoint FireWall-1 secure SMTP server
> helo abc123
> 250 Hello abc123, pleased to meet you
> mail from: <>
> 250 <>... Sender ok
> rcpt to: <[EMAIL PROTECTED]>
> 250 <[EMAIL PROTECTED] Recipient ok
> data
> 354 Enter mail, end with "." on a line by itself
> subject: this should not work!
>
> argh!
> .
> 250 Ok
> quit
> 221 Closing connection
> Connection closed by foreign host.
>
>
> The FW-1 log indicates that the second rule passes the message.
>
> Help! Our internal mail server is running Lotus Notes, and according to
> our
> Notes Guy, he can't implement the same thing on the server itself. We'll
> be
> moving away from this server within six months or so, but we're getting
> hit
> with SPAM right now and it'd be great if we could stop it. We've been
> given
> the scarlet letter by ORBS...
>
>
> Dave Grabowski
> System Arts, Inc.
> (212) 604-9015 x316
> [EMAIL PROTECTED]
>
>
>
>
==========================================================================
> ======
> 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
================================================================================
