Re: Fw: blocking from-addresses (badmailfrom)

[Charles Cazabon]

mtaylor <[EMAIL PROTECTED]> wrote:
> I'm new to this list [...]

And yet you go on to assault Henning, who is a long-standing contributor
to this list.  You have three choices:

  -live with the way this list works and get assistance here
  -hire a qmail consultant to fix things for you, so you can ignore this
   list
  -just go away

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
---

Re: Fw: blocking from-addresses (badmailfrom)

[Henning Brauer]

On Fri, Jul 13, 2001 at 07:52:38AM +0100, mtaylor wrote:
> as sent to this list " read the f archives " So my question to you Mr
> Heenning Brauer if you are not willing to help in a polite manner then don't

This "problem" with solutions and explanations is a thousand time in the
archives. A quick search for "sexyfun" or something likely would have
brought you the solution.

This list isn't intended for repeating the same FAQs all the time, its for
helping newbies to help themselves, solving real/complicated problems and
dicussions about extensions, code, patches, future development and so on.

-- 
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany   *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

Fw: blocking from-addresses (badmailfrom)

[mtaylor]

I'm new to this list and have spent untold hours reading the archives for
solutions regarding my problems. I was aware that this list is in place for
helping each other to overcome our personify problems. I have noticed that
some one cant be bothered to share his experienced to a newbee or some one
that has not got the time to spend hours searching the list or should I say
as sent to this list " read the f archives " So my question to you Mr
Heenning Brauer if you are not willing to help in a polite manner then don't
comment at all. Or should I say us in South Africa would say ( jy mout
youself gaan naai )

So to the person trying to solve his/her problem I haven't a clue what your
talking about but I'm sure some of the more intelligent people on this list
will help you gladly


- Original Message -
From: "Henning Brauer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 12, 2001 4:55 PM
Subject: Re: blocking from-addresses (badmailfrom)


> Read the f*** archives.
> --
> * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
> * Roedingsmarkt 14, 20459 Hamburg, Germany   *
> Unix is very simple, but it takes a genius to understand the simplicity.
> (Dennis Ritchie)
>

Re: blocking from-addresses (badmailfrom)

[Adrian Ho]

On Thu, Jul 12, 2001 at 10:53:31AM -0500, Q wrote:
> Does anyone have any personal recommendations as far as the AV software
> on the page goes?

Check the archives: , search for
"anti-virus".  Also .

- Adrian

Re: blocking from-addresses (badmailfrom)

[dale]

Install a virus scanner.. that is the only good way I have found
to stop those. I use the amavirus scan and it works great...
there is a link to it on the qmail home page.

On Thu, Jul 12, 2001 at 10:41:54AM -0500, Q wrote:
> We have been getting some e-mails sent from a virus some people have.  I am
> trying to block them out using the badmailfrom file, but it doesn't seem to
> be working the way I need it to.  The e-mail has a:
> 
> From: Hahaha <[EMAIL PROTECTED]>
> 
> in the header, so I put [EMAIL PROTECTED] in the badmailfrom file.
> Whenever I try to send a test message with the from address of
> "[EMAIL PROTECTED]" it gets blocked like it should.  However when the
> actual mail gets sent from someone that has the virus, it does not get
> blocked.  I checked the logs and this seems to be because qmail is saying
> that it is from <> because there is a:
> 
> Return-Path: <>
> 
> in the header too.  Is there any way I can block messages that have a null
> Return-Path or a way to have qmail check the badmailfrom against the From:
> header instead of the Return-Path one?
> 
> 
> Also it is interesting to note that my test messages bounce back to
> [EMAIL PROTECTED] and they get accepted by their mail server.
> 

Re: blocking from-addresses (badmailfrom)

[Henning Brauer]

Read the f*** archives.
-- 
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany   *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

Re: blocking from-addresses (badmailfrom)

[Q]

OK, I understand.  I will look into that.  Does anyone have any personal
recommendations as far as the AV software on the page goes?  Are there any
that you know about that aren't on the page that work well?  Also, we would
need the software to be free as we can't afford a commercial version.

Thanks!

- Original Message -
From: "Chris Johnson" <[EMAIL PROTECTED]>
To: "Q" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 12, 2001 10:49 AM
Subject: Re: blocking from-addresses (badmailfrom)

Re: blocking from-addresses (badmailfrom)

[Charles Cazabon]

Q <[EMAIL PROTECTED]> wrote:
> 
> Is there any way I can block messages that have a null
> Return-Path or a way to have qmail check the badmailfrom against the From:
> header instead of the Return-Path one?

No, and it's a bad idea.  Bounces are required to have a null envelope
sender (<>), and MTAs are required to accept them.

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
---

Re: blocking from-addresses (badmailfrom)

[Chris Johnson]

On Thu, Jul 12, 2001 at 10:41:54AM -0500, Q wrote:
> We have been getting some e-mails sent from a virus some people have.  I am
> trying to block them out using the badmailfrom file, but it doesn't seem to
> be working the way I need it to.  The e-mail has a:
> 
> From: Hahaha <[EMAIL PROTECTED]>
> 
> in the header, so I put [EMAIL PROTECTED] in the badmailfrom file.

qmail-smtpd doesn't look at the header. It looks at the envelope sender, and
the envelope sender on these messages is empty.

> Whenever I try to send a test message with the from address of
> "[EMAIL PROTECTED]" it gets blocked like it should.  However when the
> actual mail gets sent from someone that has the virus, it does not get
> blocked.  I checked the logs and this seems to be because qmail is saying
> that it is from <> because there is a:
> 
> Return-Path: <>
> 
> in the header too.  Is there any way I can block messages that have a null
> Return-Path or a way to have qmail check the badmailfrom against the From:
> header instead of the Return-Path one?

You must not block messages with a null envelope sender; this is the way
bounces are delivered. And qmail-smtpd will not check the From: header under
any circumstances.

If you want to block this kind of mail, you'll probably want to look at one of
the various anti-virus packages. See http://www.qmail.org.

Chris

 PGP signature

blocking from-addresses (badmailfrom)

[Q]

We have been getting some e-mails sent from a virus some people have.  I am
trying to block them out using the badmailfrom file, but it doesn't seem to
be working the way I need it to.  The e-mail has a:

From: Hahaha <[EMAIL PROTECTED]>

in the header, so I put [EMAIL PROTECTED] in the badmailfrom file.
Whenever I try to send a test message with the from address of
"[EMAIL PROTECTED]" it gets blocked like it should.  However when the
actual mail gets sent from someone that has the virus, it does not get
blocked.  I checked the logs and this seems to be because qmail is saying
that it is from <> because there is a:

Return-Path: <>

in the header too.  Is there any way I can block messages that have a null
Return-Path or a way to have qmail check the badmailfrom against the From:
header instead of the Return-Path one?


Also it is interesting to note that my test messages bounce back to
[EMAIL PROTECTED] and they get accepted by their mail server.

Re: Spam from addresses harvested from message IDs

[Wolfgang Zeikat]

In the previous episode (03.03.2001), Chris Johnson
<[EMAIL PROTECTED]> said:

>What I'd like to do is collect all of this mail in a Maildir, so I can
>avoid
>all the double bounces. What I propose to do is put this in
>~alias/.qmail-default:
>
>|condredirect messageidspam sh -c "echo "$DEFAULT" | egrep -q '^a[0-9]+$'"

why $DEFAULT ? wouldn't you want to use $LOCAL ?
see http://Web.InfoAve.Net/~dsill/lwq.html#environment-variables

>|fastforward -d aliases.cdb

wolfgang

Spam from addresses harvested from message IDs

[Chris Johnson]

Somebody's stupid e-mail address harvester can't tell the difference between an
e-mail address and a Message-ID header. The result is that a lot of spam is
sent to addresses like [EMAIL PROTECTED], which came from the the Message-ID
header ([EMAIL PROTECTED]) of a message that I once sent to
this list. This mail bounces because there is no such address, and, since a lot
of spammers aren't kind enough to provide a legitimate return addresses, much
of this mail double bounces to the postmaster, which is annoying him (me).

What I'd like to do is collect all of this mail in a Maildir, so I can avoid
all the double bounces. What I propose to do is put this in
~alias/.qmail-default:

|condredirect messageidspam sh -c "echo "$DEFAULT" | egrep -q '^a[0-9]+$'"
|fastforward -d aliases.cdb

(Right now ~alias/.qmail-default consists of just the fastforward line.)

Can anyone see anything particularly evil about the above? Is there a better
way to accomplish this? Am I the only one having this problem?

Thanks!

Chris

 PGP signature

Re: From-Addresses

[David Dyer-Bennet]

Florian G. Pflug <[EMAIL PROTECTED]> writes on 15 October 1999 at 18:45:11 +0200

 > Can anybody explain to me, why ezmlm uses the from-address from the 
 > smtp-evenlope, instead of the from: provided in the mail-header?

This is a somewhat controversial issue.  I've been considering writing
a patch for ezmlm+idx to change this behavior.  However, I'm going to
try to explain why it *is* done the way it is; there are some good
reasons.

 > I think that can be a disadvantage, e.g. some home-linux-systems habe 
 > private (192.168.xxx.xxx)
 > Addresses, and xxx.uucp domain names..

IP addresses aren't at issue; the smtp-envelope would normally have an
fqdn.  And it's quite important that it *never* be an unresolvable
fqdn (fake) or a private-network ip address: the smtp-envelope from
address is the address that bounce messages are returned to.  So if it
isn't a reachable address, you'll never get your bounces.

ezmlm isn't the only mailing list system to make this choice; it seems
that majordomo and list-serv also pay considerable attention to the
envelope sender.

Furthermore, the from: and reply-to: headers are, statistically,
fairly likely to have been configured wrong by the user.
-- 
David Dyer-Bennet **Update your records, forwarding expires soon** [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!

From-Addresses

[Florian G. Pflug]

Hi

Can anybody explain to me, why ezmlm uses the from-address from the 
smtp-evenlope, instead of the from: provided in the mail-header?

I think that can be a disadvantage, e.g. some home-linux-systems habe 
private (192.168.xxx.xxx)
Addresses, and xxx.uucp domain names..

Those systems could have @domain.uucp as their mail-from, while the 
from-address is correct.

Or did it missunderstand things completly? ;-)

Greetings, Florian Pflug

PS: Sorry for the incomplete mail I sent before - my fault.

From-Addresses

[Florian G. Pflug]

Hi

Can anybody explain to me, why ezmlm uses the from-address from the 
smtp-evenlope, instead of the from: provided in the mail-header?

I think that can be a disadvantage, e.g. so

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[budney]

[Pardon me; I sent this reply yesterday but it only went to Sam, who
didn't think much of it.]

Jason Haar <[EMAIL PROTECTED]> writes:
> On Mon, Mar 08, 1999 at 10:49:00PM +, Sam wrote:
> > How would you propose to handle the second and subsequent E-mail
> > messages that the sender might send, after the first one is
> > accepted by Qmail?
> 
> Well that about sorts that problem out.
> 
> I can't see how I can do what I want without patching qmail itself.

As Dan would say, "This is UNIX. Stop acting so helpless."

There are a handful of ways to do the above without patching
qmail. Remember that qmail-smtp reads stdin and writes stdout. In
short, it is a filter. Hence, for example, an expect wrapper along the
following lines would work:

   #!/usr/bin/expect --
   proc maybe_kill {addr} {
 # Check $addr; if bogus, kill as follows:
 send "QUIT\n"
 send_user "550 Go away! You smell like spam."
   }
   spawn qmail-smtpd
   interact {
 -re "mail from:<(.*)>\r" maybe_kill $interact_out(1,string)
   }


A similar skeleton can implement tarpitting, helo-host verification,
or almost anything.

Len.


-- 
46. Take all Admonitions thankfully in what Time or Place Soever given
but afterwards not being culpable take a Time & Place convenient to let
him him know it that gave them.
  -- George Washington, "Rules of Civility & Decent Behaviour"

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Jason Haar]

On Mon, Mar 08, 1999 at 10:49:00PM +, Sam wrote:
> How would you propose to handle the second and subsequent E-mail messages
> that the sender might send, after the first one is accepted by Qmail?

Well that about sorts that problem out.

I can't see how I can do what I want without patching qmail itself. I think
I'll give up the purist approach and just go for the existing patches that
already do all this...

[Better document... Better not be hit by a bus ;-/]

-- 
Cheers

Jason Haar

Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Sam]

Jason Haar writes:


> What I was thinking about is a program that carried out the SMTP
> conversation until the MAIL FROM occurred, and then checked that the address
> was "correct" (by DNS lookup). If it isn't, drop the SMTP as spam, otherwise
> turn around and replay the conversation to qmail-smtpd and then link the two
> together.

How would you propose to handle the second and subsequent E-mail messages
that the sender might send, after the first one is accepted by Qmail?

-- 
Sam

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Harald Hanche-Olsen]

- Jason Haar <[EMAIL PROTECTED]>:

| > Clearly, you can't.  But what you could do is to have a program
| > sitting between the TCP socket and qmail-smtpd.  Normally, it would
| > just pass every incoming command to qmail-smtpd, but it would check
| > any MAIL command first.  If it's bad, it will take over and reject
| > every RCPT or DATA command until a RSET or new MAIL command appears.
| 
| What I was thinking about is a program that carried out the SMTP
| conversation until the MAIL FROM occurred, and then checked that the
| address was "correct" (by DNS lookup). If it isn't, drop the SMTP as
| spam, otherwise turn around and replay the conversation to
| qmail-smtpd and then link the two together.

Well, there is no way for a program to magically link two file
descriptors together and then go away:  The program must remain and
copy data from one file descriptor to the other.  Second, after the
DATA phase is done the sender may start over with a new MAIL command,
etc., and your front end program must be prepared for that.  So it
would need to parse the traffic to detect this, and filter the new
address.  Further, a spammer could easily get around your filter by
just doing

MAIL FROM:<[EMAIL PROTECTED]>
  (the front end checks this, finds it ok, replays this to
   qmail-smtpd, and leaves the rest to qmail-smtpd)
RSET
MAIL FROM:<[EMAIL PROTECTED]>
  (qmail-smtpd blissfully accepts the new sender address)

Personally, I don't see checking the sender domain in the DNS as a
very useful antispam measure, since spammers are learning to use
sender addresses with existing domains.  But it can be seen as a way
to increase the reliability of mail delivery:  By accepting mail, you
take on the responsibility to either deliver it or to notify the
envelope sender of a failure to do so.  By refusing to accept mail
without a valid sender domain, you are basically refusing an
obligation that is impossible to meet.  (On the other hand, it may be
impossible anyway, since the local part of the sender address may be
wrong as well.  But then you could, at least in principle, pass the
resulting double bounce to the postmaster at that domain.)

- Harald

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Jason Haar]

On Mon, Mar 08, 1999 at 10:53:58AM +0100, Harald Hanche-Olsen wrote:
> | How would you propose going about writing clairvoyant code which would
> | know in advance that the client on the other side of a new SMTP connection
> | will do a MAIL FROM: with an unresolvable address at some point in the
> | future?
> 
> Clearly, you can't.  But what you could do is to have a program
> sitting between the TCP socket and qmail-smtpd.  Normally, it would
> just pass every incoming command to qmail-smtpd, but it would check
> any MAIL command first.  If it's bad, it will take over and reject
> every RCPT or DATA command until a RSET or new MAIL command appears.

What I was thinking about is a program that carried out the SMTP
conversation until the MAIL FROM occurred, and then checked that the address
was "correct" (by DNS lookup). If it isn't, drop the SMTP as spam, otherwise
turn around and replay the conversation to qmail-smtpd and then link the two
together.


> Avoiding patches is a valid goal, but not at any price.

Too true. However I am concerned that there are a LOT of patches for Qmail
now that are needed to make it compete with sendmail (anti-UCE support is
extremely lacking in "pure" qmail), and if I go down the path of shoving all
the (great) patches available into qmail, I'll end up with something
unsubstainable. DJB certainly implies he thinks most of these patches should
be done as standalone apps instead of qmail patches (rblsmtpd is an example
of this) - so I'm just asking what he's suggesting...

Personally I think http://www.flame.org/qmail/mlg-patches.diff is a great
patch (does all I'm asking, AND assigns "spam points" to each message -
bouncing when a threshold level has been met, adding a "X-Spam" header
otherwise so that you can then filter it).


-- 
Cheers

Jason Haar

Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Harald Hanche-Olsen]

- "Sam" <[EMAIL PROTECTED]>:

| On Mon, 8 Mar 1999, Jason Haar wrote:
| 
| > I know there's a bunch of patches out the to make Qmail do this, but I was
| > wondering if anyone had done it in a similar fashion to rblsmtpd - i.e. it
| > would do the check and then pass the connection onto the next part of the
| > chain - rblsmtpd, qmail-smtpd, whatever.
| 
| How would you propose going about writing clairvoyant code which would
| know in advance that the client on the other side of a new SMTP connection
| will do a MAIL FROM: with an unresolvable address at some point in the
| future?

Clearly, you can't.  But what you could do is to have a program
sitting between the TCP socket and qmail-smtpd.  Normally, it would
just pass every incoming command to qmail-smtpd, but it would check
any MAIL command first.  If it's bad, it will take over and reject
every RCPT or DATA command until a RSET or new MAIL command appears.

I am not saying this is a good idea, only that it could be done.
Since the front end has to parse the entire SMTP protocol in order to
avoid responding to data in the body of a message, it would be a lot
easier to simply run a patched qmail-smtpd.

Avoiding patches is a valid goal, but not at any price.

- Harald

Re: Getting Qmail to reject unknown MAIL FROM addresses...

[Kevin Waterson]

Jason Haar wrote:

> I know there's a bunch of patches out the to make Qmail do this, but I was
> wondering if anyone had done it in a similar fashion to rblsmtpd - i.e. it
> would do the check and then pass the connection onto the next part of the
> chain - rblsmtpd, qmail-smtpd, whatever.

I am sorry if I am missing something here, but are you wishing to setup
badmailfrom, thus denying acces to certrain domains??

Kevin

Getting Qmail to reject unknown MAIL FROM addresses...

[Jason Haar]

I know there's a bunch of patches out the to make Qmail do this, but I was
wondering if anyone had done it in a similar fashion to rblsmtpd - i.e. it
would do the check and then pass the connection onto the next part of the
chain - rblsmtpd, qmail-smtpd, whatever.

[I'm trying to do things by the "DJB-book" - so don't want any patches ;-)]

-- 
Cheers

Jason Haar

Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417