Subject: smap: Mail From question

From: "Dirk.Nerling" <[email-masked]>
Date: Mon, 10 Jul 2000 09:48:54 +0200

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Hello,

I (as postmaster) got an email which pointed me to my smap configuration.
The person told me, I have to enable  mail from: <>
because:

"since many delivery agents use such mail from: when generating
mail delivery notices. Blocking it, you're happily block any delivery
messages to your system, so that mail senders will never know about
mistakes in recipients addresses."

Is this true? Should I enable this feature and if so, which smap options
could to this?
best regards Dirk
--
Dirk Nerling, PDV-Systeme Erfurt, Haarbergstr. 73, 99097 Erfurt, phone:
++49-361-4407144
           PGP Fingerprint: C559 FF0E BAD0 9E09 F720  20F3 683E 357F 69B5
CC83
				http://www.pdv.de

---

From: [email-masked]
Date: Mon, 10 Jul 2000 11:23:05 +0200 (CEST)

Hi,

I have the same question. After I applied smap anti-spam patch (I forgot
the name of this patch, but it creates some utlities with names: mkspamdb,
etc.), I have such lines in my messages log:

smap[15038]: spam ignored address=<> host=x.x.x.x/y.y.y.y (DB)

How can I enable these empty addresses ?

Thank in advance for any answer,

				L. Vitek.

---

From: "Ken Long" <[email-masked]>
Date: Mon, 10 Jul 2000 08:21:38 -0600

I just went through this.  Here's what I did.

I Installed the latest version 2.1 smap and applied the Yao anti-spam 
patches. A new option is now available in netperm-table called 

  smap:	broken-from address

Replace address with <> to allow all email from the null address.  The line 
should look like

   smap:	broken-from <>

Allowing email from the null address is required if you want to be RFC 
compliant.  IMHO, it's ultimately your call.  The advantage to not allowing 
that address is that you may block some spam from coming in.  The 
disadvantage to not allowing it is you and your users will never get certain 
error and bounce messages.  Those errors that will be blocked don't happen 
very often, most errors and bounces you receive are sent back to you 
immediately and these will still get through.  The ones you will block are 
those that happen after the remote system has initially accepted the message 
for delivery but later decides it is unable to deliver it.  I allow the 
address.

Regards,
Ken Long

---

From: Mark C Farone <[email-masked]>
Date: Mon, 10 Jul 2000 10:37:35 -0400

>The person told me, I have to enable  mail from: <>

According to http://www.rfc-editor.org/rfc/rfc2505.txt, you "MUST NOT 
refuse "MAIL From: <>".

Although some mta's still only use 'mail from: <>' to bounce mail, 
many (not all) use [email-masked]'.  Mail From: <> was 
supposed to be just for smtp mta's to bounce mail.  However, that 
accounted for nearly one-half of all our mail at one point (~25000 
msgs/week), 99.9% of which was unsolicited spam.

In my case, I had to balance the weight of some users possibly 
missing bounced messages against violating the RFC and controlling 
excessive unsolicited traffic.  Frankly, our users complain more 
about unsolicited traffic.

>mistakes in recipients addresses."

Of course, if you block email from addresses that don't resolve 
properly, you also might miss out on an exciting opportunity to earn 
up to $10,000 per moth OR MORE by starting a home-based business 
involving CLICKING FOR CA$H!! that GENERATE $$$ IN SLEEP! :)

>Is this true? Should I enable this feature and if so, which smap options

If you're using Yao's fine anti-spam patch, you could remove any 
netperm-table line like these to allow mail from <> or unresolvable 
domains:

smap:   require-full-email 1
smap:   unknown-hosts 1

 From the patch:

**      require-full-email
**              "smap: require-full-email 1" causes this program to
**              verify that hosts that are NOT local have an @host part,
**              while checking the "from" address.
**      unknown-host
**              "smap: unknown-host 1" allowing us to accept
**              connections from a host whom we can't name [via
**              peername()].

Best,
Mark

-- 
Mark C. Farone <[email-masked]>   In the future,
Systems Analyst, Gainesville Sun        everything will work.

---

From: Ted Keller <[email-masked]>
Date: Mon, 10 Jul 2000 12:38:15 -0400 (EDT)

I block  spam messages like ...

CLICKING FOR CA$H!! that GENERATE $$$ IN SLEEP!

by using a set of spam filters that I've placed into smap.  These scan
both the header and now the top part of the message body.  I've been able
to cut the spam stuff to a minimum (can't quite get it all).

With this approach - even if a spammer uses the <> type address - the
message it still blown away.

Sorry I can't supply patches (my version of samp has varied very far from
the original 2.1)  Can, however, supply a quick kit that you could
integrate into the tool-kit.

ted keller

---

From: Mark C Farone <[email-masked]>
Date: Mon, 10 Jul 2000 14:17:13 -0400

>to cut the spam stuff to a minimum (can't quite get it all).
[...]

Ted, may I ask what content you are filtering on?  Subject?

Thanks,
Mark

---

From: Ted Keller <[email-masked]>
Date: Mon, 10 Jul 2000 18:31:56 -0400 (EDT)

Filter on ...

message from address
message to address
message header
message subject

first 10 (definable) lines of text

Have not gotten into attachments or any encoded type of data.

Pretty effective for most spam.

Also pretty effective for simple type viruses ... Melissa - ILOVEYOU -
Stages ....

The starting spamlist was picked up at 

http://www.cnx.com/stopspam.html

The code procsses that format.

ted keller