> 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
================================================================================
