bounced spam

[m***@csi.hu]

Lately, I have been receiving spam in the following way:

1) A spammer sends a spam to some address with a return-path of the form

Return-Path: ***@wierdlmpc.msci.memphis.edu

where `someone' is a varying local part

2) The recipient of the spam bounces the message to my server, where
it doublebounces since `someone' usually does not exist.


I have put a few instances of this at

http://www.csi.hu/mw/1057683526.637.moni.msci.memphis.edu:2,S
http://www.csi.hu/mw/1057683582.645.moni.msci.memphis.edu:2,S
http://www.csi.hu/mw/1057684639.979.moni.msci.memphis.edu:2,S
http://www.csi.hu/mw/1057684712.1315.moni.msci.memphis.edu:2,S
http://www.csi.hu/mw/1057684906.1363.moni.msci.memphis.edu:2,S
http://www.csi.hu/mw/1057685915.1456.moni.msci.memphis.edu:2,S

but I get about 200/300 a day.

How do people deal with this?

Thx,

Mate

[Tomasz Nidecki]

Post by m***@csi.hu
How do people deal with this?

Three ways come to my mind:

1. direct double bounces to /dev/null [create an alias which does no
delivery and add /var/qmail/control/doublebounceto with this alias in it]

2. create a .qmail-default alias that does no delivery - then everything
for inexisting recipients will be accepted but will disappear in the
mists of your /dev/null and no bounces will be generated

3. use some smtp-front or patch qmail [if it is possible - I don't know
as I have never looked into it] so that it rejects messagges to
inexistant addressess on the smtp session level.

[m***@csi.hu]

Post by Tomasz Nidecki
1. direct double bounces to /dev/null [create an alias which does no
delivery and add /var/qmail/control/doublebounceto with this alias in it]

I am not sure I can afford to do this.

Post by Tomasz Nidecki
2. create a .qmail-default alias that does no delivery - then everything
for inexisting recipients will be accepted but will disappear in the
mists of your /dev/null and no bounces will be generated

Thought about this, but the rate of these mails increase (started
10/day a week ago, and today it is already over 300) and soon it may
be too high to dare to afford this.

Post by Tomasz Nidecki
3. use some smtp-front or patch qmail [if it is possible - I don't know
as I have never looked into it] so that it rejects messagges to
inexistant addressess on the smtp session level.

This is exactly what I looked at: the badrcptto patch. But I have no
idea whether I can put an entry in the control file badrcptto so that
nonexistent local users get rejected. My suspicion is, that you
cannot do this with the patch.

Mate

[Adam Aube]

Post by m***@csi.hu

Post by Tomasz Nidecki
1. direct double bounces to /dev/null [create an alias which does no
delivery and add /var/qmail/control/doublebounceto with this alias in it]

I am not sure I can afford to do this.

Why not? Of what use (to an admin) are double bounces? The only time a
double-bounce
occurs is when the original sender address is invalid, causing the bounce
message to
be undeliverable.

Adam
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/2001

[Larry Weldon]

Post by Adam Aube

Post by m***@csi.hu

Post by Tomasz Nidecki
1. direct double bounces to /dev/null [create an alias which does no
delivery and add /var/qmail/control/doublebounceto with this alias in it]

I am not sure I can afford to do this.

Why not? Of what use (to an admin) are double bounces? The only time a
double-bounce
occurs is when the original sender address is invalid, causing the bounce
message to
be undeliverable.

If a client misconfigures his reply-to wouldn't that cause a double
bounce? It might be nice to be able to tell him.

Larry Weldon

[Adam Aube]

Post by Larry Weldon

Post by Adam Aube
Why not? Of what use (to an admin) are double bounces? The only time a
double-bounce
occurs is when the original sender address is invalid, causing the bounce
message to
be undeliverable.

If a client misconfigures his reply-to wouldn't that cause a double
bounce? It might be nice to be able to tell him.

Only if it was sent to an invalid email address in the first place.

If you misconfigured your reply-to and sent me a message, and I replied to
your message, I would get a bounce. There would be no double bounce.

Adam
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/2001

[m***@csi.hu]

Post by Adam Aube

Post by Larry Weldon

Post by Adam Aube
Why not? Of what use (to an admin) are double bounces? The only time a
double-bounce
occurs is when the original sender address is invalid, causing the bounce
message to
be undeliverable.

If a client misconfigures his reply-to wouldn't that cause a double
bounce? It might be nice to be able to tell him.

Only if it was sent to an invalid email address in the first place.
If you misconfigured your reply-to and sent me a message, and I replied to
your message, I would get a bounce. There would be no double bounce.

Two things: first, even if doublebounces are eliminated, they still
first are accepted by qmail-smtpd, so they are queued first.

Second: I can have situations where I do want to see a doublebounce.
For example, a user sends a message to ***@a.b instead of ***@a.b,
and also her envelope sender is incorrectly set. If I eliminate
doublebounces, we may not notice such a problem quickly.

Mate

[Adam Aube]

Post by m***@csi.hu
Two things: first, even if doublebounces are eliminated, they still
first are accepted by qmail-smtpd, so they are queued first.

The only way to fix this is to patch qmail to not send double bounces, to
instead simply drop bounces that bounce. I think it's better to let the
double bounces get queued and let the mail admin decide what to do with
them.

Post by m***@csi.hu
Second: I can have situations where I do want to see a doublebounce.
and also her envelope sender is incorrectly set. If I eliminate
doublebounces, we may not notice such a problem quickly.

How often does this occur, compared to the number of double bounces that
are simply spam sent from a bogus address to a non-existant address?

Furthermore, this would be better solved by setting an address in
.qmail-default to catch all mail sent to nonexistant addresses. You can then
route it as needed (this - or something similar - was posted on qmail.org).

Adam
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/2001

[Larry Weldon]

Post by m***@csi.hu

Post by Adam Aube

Post by Larry Weldon

Post by Adam Aube
Why not? Of what use (to an admin) are double bounces? The only time a
double-bounce
occurs is when the original sender address is invalid, causing the bounce
message to
be undeliverable.

If a client misconfigures his reply-to wouldn't that cause a double
bounce? It might be nice to be able to tell him.

Only if it was sent to an invalid email address in the first place.
If you misconfigured your reply-to and sent me a message, and I replied to
your message, I would get a bounce. There would be no double bounce.

Two things: first, even if doublebounces are eliminated, they still
first are accepted by qmail-smtpd, so they are queued first.
Second: I can have situations where I do want to see a doublebounce.
and also her envelope sender is incorrectly set. If I eliminate
doublebounces, we may not notice such a problem quickly.
Mate

Precisely my point. Many of us are driven by not only customer needs,
but even more by what the customer does without our knowledge or against
our recommendation. So whether we read/heed doublebounces becomes part
of the business model.

Larry Weldon

[Charles Cazabon]

Post by Larry Weldon
If a client misconfigures his reply-to wouldn't that cause a double
bounce?

No, bounces go to the envelope return path, not the Reply-To: address. But
his MUA might set them to the same value as the From: address.

Post by Larry Weldon
It might be nice to be able to tell him.

And if he's misconfigured his From: address and return path, how do you
contact him?

Charles

[m***@csi.hu]

Post by Charles Cazabon
And if he's misconfigured his From: address and return path, how do you
contact him?

He is a local user.... And in another situation, when the envelope
sender and the recipient address were incorrect, I think it is
certainly reasonable to examine the doublebounce.

echo | qmail-inject -fmisconfigured misspelled

Mate

[Matthias Andree]

Post by Charles Cazabon

Post by Larry Weldon
If a client misconfigures his reply-to wouldn't that cause a double
bounce?

No, bounces go to the envelope return path, not the Reply-To: address. But
his MUA might set them to the same value as the From: address.

Post by Larry Weldon
It might be nice to be able to tell him.

And if he's misconfigured his From: address and return path, how do you
contact him?

Looking at the signature might reveal phone or fax numbers, for one.

[Markus Stumpf]

Post by m***@csi.hu
How do people deal with this?

It depends on what you mean with "deal".

1) echo 'doublebounceto' > /var/qmail/control/doublebounceto
echo '#" > ~alias/.qmail-doublebounceto
This helps you get rid of all the double bounces

2) If you have e.g. the SPAMCONTROL patch you can use a small
script (or these two lines) in .qmail-default like
| echo "$RECIPIENT" >> /var/qmail/control/badrcptto
| exit 100
This will cause the message to bounce and the recipient to be added
to the badrcptto file, so that subsequent messages to that address
will be rejected at SMTP level. However, if the messages come in at a
high rate you'd better use some locking for the badrcptto file to not
damage the file.

3) I have a "goodrcptto" patch in qmail-smtpd. If a file
/var/qmail/control/goodrcptto/<domain>
exists it contains all the valid addresses for that domain.
All other addresses will be rejected at SMTP level. IMHO there were
other implementations of such a patch folating around in the list
2-5 weeks ago. Problem are wildcard (aka .qmail-default) addresses
that are IMHO not supported by these patches (and neither by mine).

Hope that helps!

\Maex

[m***@csi.hu]

Post by Markus Stumpf
2) If you have e.g. the SPAMCONTROL patch you can use a small
script (or these two lines) in .qmail-default like
| echo "$RECIPIENT" >> /var/qmail/control/badrcptto
| exit 100
This will cause the message to bounce and the recipient to be added
to the badrcptto file, so that subsequent messages to that address
will be rejected at SMTP level.

Unfortunately, I do not see much repetition of the names.

Post by Markus Stumpf
3) I have a "goodrcptto" patch in qmail-smtpd. If a file
/var/qmail/control/goodrcptto/<domain>
exists it contains all the valid addresses for that domain.
All other addresses will be rejected at SMTP level. IMHO there were
other implementations of such a patch folating around in the list
2-5 weeks ago. Problem are wildcard (aka .qmail-default) addresses
that are IMHO not supported by these patches (and neither by mine).

That would be the good solution, IMO. The problem is that under qmail
people create new addresses all the time (like mailinglists), so I
think wildcards are a must.

Also, I see

Even if there was an existent recipient before a nonexistent
one, the email will not be accepted.

at

http://netdevice.com/qmail

and not sure about the statement.

In any case, I now see the current state of the solutions.

Mate

[Eben]

Post by m***@csi.hu
http://netdevice.com/qmail

Regarding the goodrcptto patches, double bounces don't appear to understand
5 series response codes.
The delivery is attempted several times.
There is a break even point, where getting x number of delivery attempts is
still less bandwidth compared to accepting the body of the double bounce
message once.
It would depend on how big the body of that particular double bounce
message is.
The cost may be less to reject it x times, as opposed to accepting it once.

[Eben Pratt]

Post by Eben

Post by m***@csi.hu
http://netdevice.com/qmail

Regarding the goodrcptto patches, double bounces don't appear to understand
5 series response codes.

Are you sure the victimized "relay" is not just being fed the weird mail
again and again? It's hard to tell that from just the envelope.

Roger, would you care to comment on what you are seeing in the case that we
discussed off list?
__________________________________________________________________

Eben Pratt
75 Indian Rock Road, Merrimack NH 03054
aim: ebenpratt
voice: 603.424.8676
!try; do();

[Matthias Andree]

Post by Eben

Post by m***@csi.hu
http://netdevice.com/qmail

Regarding the goodrcptto patches, double bounces don't appear to understand
5 series response codes.

Are you sure the victimized "relay" is not just being fed the weird mail
again and again? It's hard to tell that from just the envelope.

[Matthias Andree]

Post by m***@csi.hu
Even if there was an existent recipient before a nonexistent
one, the email will not be accepted.

The document claims that it's spam if it mixes bad and good addresses,
but it might just be a typo.

Rejecting the invalid recipients and accepting the valid ones would be
the right thing to do, and it wouldn't interfere with
PIPELINING. PIPELINING is desirable, because it can reduce traffic
(packet overhead).

The current goodrcptto v4 shape looks too aggressive.

Imagine your qmail is hosting multiple domains, and some mailing list
delivers mail for 17 users in 11 domains in one go, you'd be rejecting
mail for 16 innocent users if the 17th terminates his account without
unsubscribing from the list before, and the list admin will not be able
to figure what went wrong, not to speak of fixing the issue.

That's way too much collateral damage. I'd be happy to link to
goodrcptto from my qmail-bugs.html document, but not before the patch
has been revised to only reject the invalid recipients rather than
killing the whole session after DATA or dropping it altogether (the
latter is BTW the reason why the spammers keep coming back, connection
loss is equivalent to a 400-series code to any recipient).

[Eben]

Post by Matthias Andree

Post by m***@csi.hu
Even if there was an existent recipient before a nonexistent
one, the email will not be accepted.

The document claims that it's spam if it mixes bad and good addresses,
but it might just be a typo.

I wrote 'is almost certainly spam'.

Post by Matthias Andree
mail for 16 innocent users if the 17th terminates his account without
unsubscribing from the list before, and the list admin will not be able
to figure what went wrong, not to speak of fixing the issue.

Users at an organization understand that the qmail administrator updates
tcp.smtp.cdb with the IPs of the list servers that they subscribe to.
or
Users at an organization understand that the qmail administrator is
responsible for subscribing users to mailing lists under group aliases.
They send to a list as Howard <***@example.com>, Robin
<***@example.com>, etc., and incoming list messages go to each of them.
alias/.qmail-listname:
&hstern
&rquivers
&fnorris
or
An organization is too small to have two or more people subscribed to the
same list.
or
Your solution here.

Thanks for your suggestions.

[Matthias Andree]

Post by Eben

Post by Matthias Andree
mail for 16 innocent users if the 17th terminates his account without
unsubscribing from the list before, and the list admin will not be able
to figure what went wrong, not to speak of fixing the issue.

You omitted the crucial part, these users are in different domains that
happen to be served by the same qmail server. (POP toaster with virtual
domains).

You also appear to assume that any legitimate mail is single-RCPT, which
is utterly wrong.

Post by Eben
Users at an organization understand that the qmail administrator updates
tcp.smtp.cdb with the IPs of the list servers that they subscribe to.

Nonsense. The list's MTA is an SMTP client like any other.

Post by Eben
Users at an organization understand that the qmail administrator is
responsible for subscribing users to mailing lists under group
aliases.

a. doesn't apply
b. defeats VERP
c. will not route direct, off-list, replies properly

qmail is supposed to REMOVE load from the administrator, not add to
it. Your suggestion make me doubt you have understood how SMTP works
outside qmail, on the SMTP client side. There are clients that bundle
per-domain mail, and there are clients that bundle per-MX even and cache
connections, the current goodrcptto flies in the face of anyone
accepting mail from non-qmail clients.

What license is the origrcptto patch under? May one distribute a
modified version, potentially under a different name?

[Eben]

Post by Matthias Andree
blah

The patch works very well in many situations.
It most certainly will not fit everyone's requirements.

Post by Matthias Andree
What license is the origrcptto patch under? May one distribute a
modified version, potentially under a different name?

Not sure what an origrcptto patch is, but everyone except you is allowed to
modify and distribute it.
;)

[Jonathan de Boyne Pollard]

E> The patch works very well in many situations.

A correct statement would be that the patch contains a flaw (aborting the
entire transaction when it encounters a "RCPT" verb that it doesn't like) that
simply isn't hit all of the time by every SMTP transaction. Put another way:
The patch introduces the possibility of false negatives.

[Matthias Andree]

Post by Jonathan de Boyne Pollard
E> The patch works very well in many situations.
A correct statement would be that the patch contains a flaw (aborting the
entire transaction when it encounters a "RCPT" verb that it doesn't like) that

Yup.

Post by Jonathan de Boyne Pollard
The patch introduces the possibility of false negatives.

How do you define "false negative" in this context? Unwanted side
effects, rejecting solicited mail, that's what can happen -- common
terminology is "false positive", in the meaning of "false positive
identification as UCE".

[Jonathan de Boyne Pollard]

JdeBP> The patch introduces the possibility of false negatives.

MA> How do you define "false negative" in this context?

A rejection of a mail (a "negative") where the mail is either non-bulk or
solicited (i.e. a "false negative").

"positive" and "negative" would be interchanged if one regarded the process as
being the checking of mail messages against criteria to see whether they
match, rather than as being the deciding of what mail messages to accept.

[Eben]

Post by Jonathan de Boyne Pollard
E> The patch works very well in many situations.
A correct statement would be that the patch contains a flaw (aborting the
entire transaction when it encounters a "RCPT" verb that it doesn't like) that
The patch introduces the possibility of false negatives.

In it's current form, it doesn't accept an email with any bad recipients,
it rejects the message at the data request.
It's the responsibility of the sender who misspells one of several
addresses to comprehend the bounce message.
A qmail server wouldn't have any problems sending to it however.
Malicious connections could be handled by a cron that looks at the logs and
updates tcprules accordingly.

[Matthias Andree]

Post by Eben

Post by Jonathan de Boyne Pollard
The patch introduces the possibility of false negatives.

In it's current form, it doesn't accept an email with any bad recipients,
it rejects the message at the data request.

Your approach is bogus and defeats delivery of legitimate mail.

Post by Eben
Malicious connections could be handled by a cron that looks at the logs and
updates tcprules accordingly.

Blah blah. Idiot anti-UCE measures could (and if I see crap like this
should) be subject to a 10 year sentence, with minimum penalty being one
year without parole. This is deliberately mutilating the mail system,
nothing else.

[Jonathan de Boyne Pollard]

JdeBP> A correct statement would be that the patch contains a flaw
JdeBP> (aborting the entire transaction when it encounters a "RCPT"
JdeBP> verb that it doesn't like) that simply isn't hit all of the
JdeBP> time by every SMTP transaction. Put another way: The patch
JdeBP> introduces the possibility of false [rejections].

E> In it's current form, it doesn't accept an email with any bad
E> recipients, it rejects the message at the data request.

That's the flaw.

E> It's the responsibility of the sender who misspells one of
E> several addresses to comprehend the bounce message.

No. It's the responsibility of the SMTP Relay server to handle the protocol
properly so that the right type of bounce happens in the first place.
Envelope recipients are given individually so that they can be individually
accepted or rejected, and be reported as such. A rejection of one recipient
does not require the entire transaction to be aborted. And aborting the
entire transaction causes the wrong type of bounce.

E> A qmail server wouldn't have any problems sending to it however.

The fact that one particular SMTP Relay client doesn't hit the problem,
because it doesn't use that part of SMTP, doesn't make the problem itself
nonexistent. The patch is flawed.

[Eben]

Post by Jonathan de Boyne Pollard
E> In it's current form, it doesn't accept an email with any bad
E> recipients, it rejects the message at the data request.
That's the flaw.

It's a feature for the reasons given in the patch text, not a flaw.
John Levine's badrcptto patch does the same thing.

Post by Jonathan de Boyne Pollard
E> It's the responsibility of the sender who misspells one of
E> several addresses to comprehend the bounce message.
No. It's the responsibility of the SMTP Relay server to handle the protocol
properly so that the right type of bounce happens in the first place.
Envelope recipients are given individually so that they can be individually
accepted or rejected, and be reported as such. A rejection of one recipient
does not require the entire transaction to be aborted. And aborting the
entire transaction causes the wrong type of bounce.

Read the patch text and code, the transaction isn't aborted.
Correct error responses are given, the sender gets human readable bounce
messages regarding each recipient.

Post by Jonathan de Boyne Pollard
E> A qmail server wouldn't have any problems sending to it however.
The fact that one particular SMTP Relay client doesn't hit the problem,
because it doesn't use that part of SMTP, doesn't make the problem itself
nonexistent. The patch is flawed.

I'm not sure what you're getting at, the following has been true for all
versions.
A qmail server will send a multiple recipient message individually to each
recipient.
The message will get through to the good recipients in a multiple recipient
email.

[Matthias Andree]

Post by Eben
I'm not sure what you're getting at, the following has been true for
all versions. A qmail server will send a multiple recipient message
individually to each recipient. The message will get through to the
good recipients in a multiple recipient email.

Irrelevant. Few SMTP clients share qmail's "split-mail-even-if-not-VERP"
bandwidth-burning insanity. Any decent client that keeps multi-RCPT mail
as such will be punished.

Use whatever you like on your system, but please don't distribute code
that implements such misguided ideas.

[Markus Stumpf]

Post by Matthias Andree
Irrelevant. Few SMTP clients share qmail's "split-mail-even-if-not-VERP"
bandwidth-burning insanity. Any decent client that keeps multi-RCPT mail
as such will be punished.

Irrelevant.
From a older mail from me to the IRTF ASRG list:
------------------------------------------------------------------------
I used the maillog of one of our mailservers of the last 22 hours.
It saw
128582 RCPT TO commands in
110709 connections
the data is cleaned of 5 customers that did newsletter injects today
that consisted of about 100-250 recipients per connection).

Please note that this mailserver is used by our customers as an outgoing
relay and also by external users as a MX host. If you think this will
make the data inaccurate I could try to filter out our customers to
get better figures.

The distribution is
102252 1 (aka 102252 times 1 recipient per connection)
4562 2
1983 3
674 4
435 5
351 6
132 7
109 8
101 10
52 9
16 13
9 15
9 12
8 11
3 16
3 14
2 17
1 74
1 70
1 65
1 41
1 26
1 25
1 22
1 20
If I only use those hosts that weren't
a) rejected for sender address blocks (spam)
b) rejected for recipient address blocks (spam)
c) tagged because listed with DNSBLs
the distribution is
the distribution is
66269 1
2781 2
575 3
248 4
125 5
84 6
54 7
54 10
39 8
21 9
4 13
3 15
3 12
3 11
2 16
1 22
1 17
1 14
The distribution for all "spam" classified emails is:
35983 1
1781 2
1408 3
426 4
310 5
267 6
78 7
70 8
47 10
31 9
12 13
6 15
6 12
5 11
2 14
1 74
1 70
1 65
1 41
1 26
1 25
1 20
1 17
1 16
------------------------------------------------------------------------

This is a mail on the same subject to the same list
------------------------------------------------------------------------
From: Steven F Siirila <***@tc.umn.edu>
Date: Sat, 31 May 2003 14:52:18 -0500

Here are the numbers for the University of Minnesota spanning the past
10 days or so (granted school is out, so the numbers are lower than
normal):

3686050 MAIL FROM commands issued
3922455 RCPT TO commands issued

These are numbers ONLY for our MX servers (incoming mail where only systems
who look at our MX records should be connecting). It appears that we have
about a 1.064 to 1 ratio (almost all of our mail is single recipient mail).
------------------------------------------------------------------------

Post by Matthias Andree
Use whatever you like on your system, but please don't distribute code
that implements such misguided ideas.

Your mileage may vary if you like the code or not. But the misguided
idea is obviously the wide spread use of multiple RCPT TOs in one
connection. And this shows that the "bandwidth-burning insanity" as you
call it is common to all MTAs out there. The only ones widely utilizing
multi RCPT TOs are spammers.

\Maex

[Markus Stumpf]

The conclusion is false. The method of just counting RCPT TO per MAIL
FROM doesn't offer such data, because it doesn't recognize how much of
that mail was sent to multiple recipients.

Read it again. The percentage of MAIL FROM to RCPT TO shows that the use
of the "feature" of using /multi/ RCPT TO for /one/ MAIL FROM is as good
as not existing. And the method of course offers that kind of data.
If I have 100 MAIL FROM and 101 RCPT TO it is clear that exactly one
connection had more than one RCPT TO and 99 hadn't.
If I have
3686050 MAIL FROM commands issued
3922455 RCPT TO commands issued
at least 3449645 must have had only ONE recipient and that is 93% of all
connections in the case that the multi RCPT connection /all/ had exactly
/two/ rcpients. It grows higher for every connection that had more than
two.

To this end, you'd have to
checksum some common header and envelope data and the body, disregarding
variant data such as MIME boundaries (that can change as mail is
re-encoded on the fly) or Received: headers.

No. You're quite lousy in math.

Killing like 5% of the legitimate mail is a pretty ragged approach and

If you look the my numbers you'll see that 5% is far from any realism.
To get this 5% legitimate mail rejected you'd have to meet several criterias:
1) only 7% has more than one recipient.
2) out of this 7% one of the recipients has to be a wrong address
So you are arguing that 71% of all emails with more than one recipient
has at least one invalid address?
3) out of those it has to be legitimate mail and not spam.
I don't have exact numbers on these but I think you won't even reach 0.01%.

MTAs were designed to deliver mail, not to make other people headaches
of the "Why did our mail bounce today?" kind.

Correct. But at the time of design nobody thought of a > 60% rate of
spam to mail. So if you want to send mail you have to meet some easy
understandable criterias. Strange enough that we outragiously reject
about 60% of our emails. And we only got 5 complaints within the last 6
month. That makes ... 0.000028 percent of our rejections made the
senders headache. Hey, this is one day headache in 100 years, I can live
with that ... most people don't get that old.

It's a pity that qmail is so deficient that people try such radical
mechanisms to ward off a certain percentage of mail, and this is a sure
sign of desparation.

Bullshit.
The design and implementation of qmail is so easy and clear that it is
possible to add these checks fast and efficient, while the admins of
other MTAs sit in their corner crying and desperate.

\Maex

[Matthias Andree]

Post by Markus Stumpf
Read it again. The percentage of MAIL FROM to RCPT TO shows that the use
of the "feature" of using /multi/ RCPT TO for /one/ MAIL FROM is as good
as not existing. And the method of course offers that kind of data.
If I have 100 MAIL FROM and 101 RCPT TO it is clear that exactly one
connection had more than one RCPT TO and 99 hadn't.

Reading it again doesn't reveal information that isn't there.

You still don't know if you had one mail with 100 RCPT TO that got
mangled by qmail or if you had 50 mails with 2 RCPT TO each, mangled by
qmail, or if you really had 100 mails with 1 RCPT TO.

Nevermind, I posted a patch to fix this; beyond this, Eben's morercptto
patch carries more traces of its author not knowing what he's doing,
like, letting mailing list servers relay, and being impractical for
people who use variable address extensions, VERP, TMDA and the like.
All this works with Postfix' local_recipient_maps.

Post by Markus Stumpf
If I have
3686050 MAIL FROM commands issued
3922455 RCPT TO commands issued
at least 3449645 must have had only ONE recipient and that is 93% of all

Nope. You don't get to know that without evaluating the mail content.

Post by Markus Stumpf

Killing like 5% of the legitimate mail is a pretty ragged approach and

If you look the my numbers you'll see that 5% is far from any realism.
1) only 7% has more than one recipient.
2) out of this 7% one of the recipients has to be a wrong address
So you are arguing that 71% of all emails with more than one recipient
has at least one invalid address?

Potentially, yes. Does the statistic reveal that information? No, it
does not.

Post by Markus Stumpf
3) out of those it has to be legitimate mail and not spam.
I don't have exact numbers on these but I think you won't even reach 0.01%.

I don't actually care if it's 10% or 100 ppm, the approach is wrong.
Some qmail disciples, lacking more effective means, grasp every strawl
that comes along, and then repudiate any adverse effects...

Mail servers are about reliability, even in adverse conditions, namely
UCE. With deliberately misinterpreting data, you're not getting
any problem solved, but just add new problems.

Post by Markus Stumpf
Correct. But at the time of design nobody thought of a > 60% rate of
spam to mail. So if you want to send mail you have to meet some easy

Interestingly enough, my ratio is WAY lower, even at sites without spam
filters.

Post by Markus Stumpf
understandable criterias. Strange enough that we outragiously reject
about 60% of our emails. And we only got 5 complaints within the last 6
month. That makes ... 0.000028 percent of our rejections made the

I'd rather blackhole space.net than argue with stubborn people.

Post by Markus Stumpf

It's a pity that qmail is so deficient that people try such radical
mechanisms to ward off a certain percentage of mail, and this is a sure
sign of desparation.

Bullshit.

Yah, sure, people grasp that goodrcptto crap and defend it when it's so
obviously flawed. Why would they use and argue in favor if they weren't
desperately looking for means to deal with the ">60%".

Post by Markus Stumpf
The design and implementation of qmail

That's not the matter here.

Post by Markus Stumpf
is so easy and clear that it is possible to add these checks fast and
efficient, while the admins of other MTAs sit in their corner crying
and desperate.

Do they really? They don't need to patch their MTA to make these checks
in the first place, and they don't need to justify adverse side effects
of a bogus patch with misinterpreting statistics to rectify why the
patch is there; rather than fixing the patch.

Postfix has had $local_recipient_maps for years, with support for
address extensions ($recipient_delimiter), without the adverse "kill the
whole mail if one recipient is bogus" effect, and it's been default-on
since 2.0, since Postfix derives the lists automatically. Exim has had
SMTP callbacks for ages. Exim and Sendmail have rejected known
undeliverable RCPT TO for as long as I can remember.

You can use and patch qmail for as long as you like, but do stop making
bogus claims about other MTAs. I have used qmail for production for an
extended amount of time, have you used Postfix or Exim in a serious way?

[Markus Stumpf]

Post by Matthias Andree

Post by Markus Stumpf
Read it again. The percentage of MAIL FROM to RCPT TO shows that the use
of the "feature" of using /multi/ RCPT TO for /one/ MAIL FROM is as good
as not existing. And the method of course offers that kind of data.
If I have 100 MAIL FROM and 101 RCPT TO it is clear that exactly one
connection had more than one RCPT TO and 99 hadn't.

Reading it again doesn't reveal information that isn't there.

If you can't detect or understand the information then stop discussing
about it.

Post by Matthias Andree
You still don't know if you had one mail with 100 RCPT TO that got
mangled by qmail or if you had 50 mails with 2 RCPT TO each, mangled by
qmail, or if you really had 100 mails with 1 RCPT TO.

As I said: this list is not the place to do private math lessons for you.
But if you think that 50 mails with 2 RCPT TO each will result in
100 MAIL FROM you have more than slight deficiencies in math or in RFC2821.
As all your other blabla depends on those false calculations it is wrong
blabla, also.

Oh, and by the way the above numbers are from a logfile of a MTA that's
/not/ qmail.

Post by Matthias Andree
in the first place, and they don't need to justify adverse side effects

I dont justify any effects (I have clearly stated that in my first mail
and I don't care about the goodrcptto patch. I've done somthing similar
in a completely different way years ago).

I have proven that all that bullshit talk of yours about the wide spread
use of multiple RCPT on which the whole mail system depends is exactly that:
bullshit.

A side effect is that dropping a SMTP connection at any point I see
something I don't like (and issuing a proper error) does no harm at all
"to the mail system".

As I said in a former mail: Please stop talking about any effects
something will have on "The Internet mail system". You don't know anything
about "The Internet mail system" and especially not about communication
structures and communication behaviour using the SMTP protocol.

\Maex

[Matthias Andree]

Post by Markus Stumpf

Post by Matthias Andree
You still don't know if you had one mail with 100 RCPT TO that got
mangled by qmail or if you had 50 mails with 2 RCPT TO each, mangled by
qmail, or if you really had 100 mails with 1 RCPT TO.

As I said: this list is not the place to do private math lessons for you.
But if you think that 50 mails with 2 RCPT TO each will result in
100 MAIL FROM you have more than slight deficiencies in math or in RFC2821.

I maintain that the recipient side does not know with how many RCPT TO
headers a mail has been injected, unless it looks at the mails.
Particularly, those figures didn't tell us how many of the received
multi-RCPT mails were legitimate.

It is about time that you stop insulting and get your facts straight.

Post by Markus Stumpf
Oh, and by the way the above numbers are from a logfile of a MTA that's
/not/ qmail.

Doesn't matter at the receiving end.

Post by Markus Stumpf
As I said in a former mail: Please stop talking about any effects
something will have on "The Internet mail system". You don't know anything
about "The Internet mail system" and especially not about communication
structures and communication behaviour using the SMTP protocol.

Repetition does not establish validity.

[Charles Cazabon]

Post by Matthias Andree
Repetition does not establish validity.

But that doesn't stop you from posting Postfix blather to the qmail list, for
some strange reason.

Charles

[Matthias Andree]

Post by Charles Cazabon

Post by Matthias Andree
Repetition does not establish validity.

But that doesn't stop you from posting Postfix blather to the qmail list, for
some strange reason.

I wrote, in a different thread, that I'll put false claims about Postfix
right when I see them. Stop people from posting false claims to stop me
from putting those facts straight.

[Uwe Ohse]

Post by Matthias Andree
I wrote, in a different thread, that I'll put false claims about Postfix
right when I see them. Stop people from posting false claims to stop me
from putting those facts straight.

in this case Markus asked you to stop making claims about the internet
mail system (translation: how the internet mail infrastructure works).
He's shown that you've got no idea about it.

Regards, Uwe

[Matthias Andree]

Post by Uwe Ohse
in this case Markus asked you to stop making claims about the internet
mail system (translation: how the internet mail infrastructure works).
He's shown that you've got no idea about it.

He hasn't shown anything besides insulting someone who points out his
conclusions aren't correct, making unsubstantiated claims about somebody
else's ignorance.

[Uwe Ohse]

Post by Matthias Andree
I maintain that the recipient side does not know with how many RCPT TO
headers a mail has been injected, unless it looks at the mails.

could you please tell me how to get delivery level information from the
mail? From _this_ mail, please?

Post by Matthias Andree
Particularly, those figures didn't tell us how many of the received
multi-RCPT mails were legitimate.
From the 800something mails running through one of my main mail

systems since about 21:00 UTC yesterday to about 10:00 UTC today only
32 had multiple RCPT TOs.
Judging from the target addresses used not a single one was legitimate
(i looked them up in the up-to-date userbase).

Let's say 800 mails, 32 with multiple RCPT to, makes 4 percent.
These 32 had 77 recipients.
Recipients in total: 77 (32) plus 768 (800-32).
-> 10% of the target addresses came from mails with multiple RCPT-TOs.

I wouldn't call that a big win, but i'm sure you do.


On the other hand one of my other machines was an open relay for
two days and something, and in 53.5 hours the system logged 21649 MAIL FROM,
21689 RCPT TO and 21581 DATA. Usual traffic on that machine: 750 per day.

During the spam days the machine received up to 1 multi recipient mail
per tausend spam mails, so even that spammer didn't care about multiple
RCPT TOs. Do you now think that the spammer used qmail? He didn't,
judging from the mail headers.

Post by Matthias Andree
It is about time that you stop insulting and get your facts straight.

has it ever occured to you that you get insulted often here?
I think it's possible that this is due to you attitude.

Post by Matthias Andree
Repetition does not establish validity.

That's true for the "postfix is good and whatever you see as a postfix
misfeature is a feature to me"-automaton on this list, too.

Gruß, Uwe

[adi]

Post by Uwe Ohse

Post by Matthias Andree
From the 800something mails running through one of my main mail

systems since about 21:00 UTC yesterday to about 10:00 UTC today only
32 had multiple RCPT TOs.
Judging from the target addresses used not a single one was legitimate
(i looked them up in the up-to-date userbase).

then you take only one sender into account then :-)

There are occations where statistics from Markus don't apply,
there are occations where they do apply. Anyway, taking a
conclusion from simple minded sampling technique would be
unwise, otherwise it'll just wasting a lot of our time discussing
it.

Matthias believes that on the receiving site, there is no information
about single/multiple rcpt to originated mail. Nothing from the
taking this factor into account.

And, people, please don't forget about another factor: the mail size.

Regards,

P.Y. Adi Prasaja

[Matthias Andree]

Post by adi
Matthias believes that on the receiving site, there is no information
about single/multiple rcpt to originated mail. Nothing from the
taking this factor into account.

Let's put it another way:

Sender software injects:

MAIL FROM: aaa
RCPT TO: ***@ccc.dom
RCPT TO: ***@ccc.dom
RCPT TO: ***@fff.dom
DATA...

Recipient ccc.dom can see either:

MAIL FROM: aaa
RCPT TO: ***@ccc.dom
RCPT TO: ***@ccc.dom

or:

MAIL FROM: aaa
RCPT TO: ***@ccc.dom
MAIL FROM: aaa
RCPT TO: ***@ccc.dom

When you're looking at the second, you don't know if the injected mail
was multi-RCPT.

And mind you, Mailman can do multi-RCPT injects (it has a nifty "VERP
for every fifth mailing" feature that can save quite some traffic -- and
isn't tied to qmail, so relying on somebody else using qmail to send to
your misconfigured goodrcptto-patched system just won't work.

Taking Uwe's observation into account that spammers don't often go for
multi-RCPT, you'd need to reject single-RCPT as well, but nobody
suggests that when rejecting multi-RCPT is fine with everybody. Why
don't you people (this isn't directed at adi) apply the same standards?

I checked Postfix logs of a production system I looked after of the past
few weeks for nrcpt, doesn't look as though I could just drop any
multi-RCPT mail on the floor. NOTA BENE: The nrcpt are AFTER weeding out
invalid local recipients, so if I have one valid and one invalid RCPT TO
line in the SMTP transaction, I get nrcpt=1. This is different from the
other statistics presented here.

count nrcpt=
389388 1
706 2
2563 3
59683 4
20 5
14 6
6 7
2 8
2 9
30 11
14 18
1 19
1 21
4 34
1 40

This makes 63,047 multi-RCPT and 389,388 single-RCPT out of 452,435
mails, that's 14 % multi-RCPT when only counting valid RCPT lines.

[Markus Stumpf]

Post by Matthias Andree
MAIL FROM: aaa
DATA...
MAIL FROM: aaa
MAIL FROM: aaa
MAIL FROM: aaa
When you're looking at the second, you don't know if the injected mail
was multi-RCPT.

Again, what are you talking about?
You want to tell us that when SMTP Server A sends to SMTP Server B and
SMTP Server A sends

Post by Matthias Andree
MAIL FROM: aaa
DATA...

SMTP Server B will see

Post by Matthias Andree
MAIL FROM: aaa

Come on, you really must be joking?
If you mean you have mail relays in between that split the messages up, then
your argumentation is irrelevant. But I don't think you're talking about
relays as you are also arguing that the internet mail system is a
end-to-end system, so there are no relays in between, right? So who is
mangling the multi RCPT to single RCPT in a end-to-end connection?
And: this is irrelevant. Messages arrive with a probability of 0.93
in single RCPT connections at large mailservers. Out of the 7% there
is a large overweight to spam messages.
If one would reject multi RCPT at all it would still cause no big harm to
the Internet Mailsystem per se, neither would it result in a breakdown.

Post by Matthias Andree
And mind you, Mailman can do multi-RCPT injects (it has a nifty "VERP
for every fifth mailing" feature that can save quite some traffic -- and
isn't tied to qmail, so relying on somebody else using qmail to send to
your misconfigured goodrcptto-patched system just won't work.

You're loosing the topic again.
We don't talk about Mailman or any patches. We're talking about the
precentage of the use of multi RCPT TO across The Internet in general.
Just like a usual car uses an average of 10 liters of gasoline/100km.
There are also tanks that use 200 liters/100km but that is irrelevant
for the global picture.
And I'd *guess* that most large mailservers handling big load have MX
sorting disabled, but in the time that is needed to MX sort a list with
200000 recipients the list is probably sent with single RCPT.

Post by Matthias Andree
Taking Uwe's observation into account that spammers don't often go for
multi-RCPT, you'd need to reject single-RCPT as well, but nobody
suggests that when rejecting multi-RCPT is fine with everybody. Why
don't you people (this isn't directed at adi) apply the same standards?

1) You're loosing the topic again.
2) Millions of Mailservers reject zillions of connections of single-RCPT
transactions each day.
So what are you talking about?

Post by Matthias Andree
I checked Postfix logs of a production system I looked after of the past
few weeks for nrcpt, doesn't look as though I could just drop any
multi-RCPT mail on the floor. NOTA BENE: The nrcpt are AFTER weeding out
invalid local recipients, so if I have one valid and one invalid RCPT TO
line in the SMTP transaction, I get nrcpt=1. This is different from the
other statistics presented here.

Yes and your manipulation renders it irrelevant. It's just like:
"After removing all the log records of invalid AOL mails my statistics
clearly show that all AOL mails are to valid recipients".
If you try to argue that your statistics are positive for my
argumentation as the real numbers will be lower, this is irrelevant,
too, as you don't show numbers how much nrcpt manipulation has happend
because of invalid RCPT TO lines in the transaction. And you'd also have
to show us numbers how much the number of recipients has been "adjusted",
i.e.
5 -> 1
2 -> 1
7 -> 2
It could also be that you had exactly one adjusted log record for
2 -> 1
which wouldn't change a thing.

Besides that I'd be interested in the origin of those
59683 4 RCPT/connection
as they account for 94% of the multi-RCPT transactions and the userbase
behind the server.

To repeat it, your numbers as presented are without any statistical
relevance.

\Maex

[Matthias Andree]

Post by Markus Stumpf
If you mean you have mail relays in between that split the messages up, then
your argumentation is irrelevant. But I don't think you're talking about

The point has been and still is that your interpretation of the
statistics is skewed, no matter how much you try to justify the outcome
itself. The assumption that you could deduce the original recipient
count at the receiving site does n o t hold.

Post by Markus Stumpf
relays as you are also arguing that the internet mail system is a
end-to-end system, so there are no relays in between, right? So who is
mangling the multi RCPT to single RCPT in a end-to-end connection?

The receiver will not know that from looking at the envelope, which is
also my point. It takes at least looking at the Received: headers to
find _that_ out.

Post by Markus Stumpf
And: this is irrelevant. Messages arrive with a probability of 0.93
in single RCPT connections at large mailservers. Out of the 7% there
is a large overweight to spam messages.

The count of RCPT itself is no reliable indication of whether the mail
is spam. How much of the single-RCPT is spam? For some of my regular
addresses (no spamtraps), the single-RCPT spam outnumbers single-RCPT
solicited mail by a factor of between 10 and 40 to 1, depending on the
day. I could conclude I should block all single-RCPT mail -- same
argumentation, because spam outweighs regular mail.

Post by Markus Stumpf
If one would reject multi RCPT at all it would still cause no big harm to
the Internet Mailsystem per se, neither would it result in a breakdown.

Apparently you have a very different perception of when things stop
working.

Post by Markus Stumpf
And I'd *guess* that most large mailservers handling big load have MX
sorting disabled, but in the time that is needed to MX sort a list with
200000 recipients the list is probably sent with single RCPT.

You're guessing, but you don't have figures nor profiles. Just because
qmail doesn't do it, doesn't mean others don't do it either.

Software will try to sort a limited amount of recipients at least to
conserve bandwidth; beyond that SMTP doesn't guarantee more than 100
recipients per mail.

Post by Markus Stumpf

Post by Matthias Andree
Taking Uwe's observation into account that spammers don't often go for
multi-RCPT, you'd need to reject single-RCPT as well, but nobody
suggests that when rejecting multi-RCPT is fine with everybody. Why
don't you people (this isn't directed at adi) apply the same standards?

1) You're loosing the topic again.
2) Millions of Mailservers reject zillions of connections of single-RCPT
transactions each day.
So what are you talking about?

You're still trying to justify rejecting the whole transaction if one of
the multi-RCPT is botched. You'll lose legitimate mail that way unless
you're the only user.

Post by Markus Stumpf

Post by Matthias Andree
I checked Postfix logs of a production system I looked after of the past
few weeks for nrcpt, doesn't look as though I could just drop any
multi-RCPT mail on the floor. NOTA BENE: The nrcpt are AFTER weeding out
invalid local recipients, so if I have one valid and one invalid RCPT TO
line in the SMTP transaction, I get nrcpt=1. This is different from the
other statistics presented here.

The figures show that multi-RCPT is an important feature.

Post by Markus Stumpf
Besides that I'd be interested in the origin of those
59683 4 RCPT/connection
as they account for 94% of the multi-RCPT transactions and the userbase
behind the server.

Indeed it does, that's a case where four users are subscribed to the
same list.

[Markus Stumpf]

Post by Matthias Andree
itself. The assumption that you could deduce the original recipient
count at the receiving site does n o t hold.

I don't care about the original recipient count, nor does any other
receiving mailserver. The only thing I have to care about as a
receiving mailserver is how many connections and how many messages I
get and if I can handle that. It is absolutely irrelevant to sit in the
corner and cry about the bad cruel world and how much bandwidth I could
have saved if I'd had more multi RCPT connections.
There aren't. Fact.

Post by Matthias Andree
The receiver will not know that from looking at the envelope, which is
also my point. It takes at least looking at the Received: headers to
find _that_ out.

It 's absolute irrelevant for the receiver just like it is if the email
was written with vi, outlook, pine, elm, or with a web form.
The email is arriving single RCPT and that is all that matters.

Post by Matthias Andree
The count of RCPT itself is no reliable indication of whether the mail
is spam.

Where did I say that?
I said that from the multi RCPT messages arriving I can read from my
logfiles that the percentage of spam is >50%. I can see this from
loglines like:

Jul 23 16:57:14 pid 70917: ds81-30-197-210.ufanet.ru:81.30.197.210
rejected: <***@eguo.com> to <***@space.net> badrcptto
Jul 23 16:57:14 pid 70917: ds81-30-197-210.ufanet.ru:81.30.197.210
rejected: <***@eguo.com> to <***@space.net> spamrcptto
Jul 23 16:57:15 pid 70917: ds81-30-197-210.ufanet.ru:81.30.197.210
rejected: <***@eguo.com> to <***@space.net> badrcptto

that account to "spam" because they are rejected because of an entry in
my "badrcptto". But connections like

Jul 23 16:57:08 pid 70905: dhcp024-209-226-098.cinci.rr.com:24.209.226.98
rbl-allowed: <***@azlyrics.com> to <maex-***@space.net>
Jul 23 16:57:08 pid 70905: dhcp024-209-226-098.cinci.rr.com:24.209.226.98
rbl-allowed: <***@azlyrics.com> to <maex-bind-***@space.net>

Jul 23 16:57:08 pid 70906: pcp03441042pcs.olathe01.ks.comcast.net:68.86.123.161
rbl-allowed: <***@notmydesk.com> to <maex-***@space.net>
Jul 23 16:57:08 pid 70906: pcp03441042pcs.olathe01.ks.comcast.net:68.86.123.161
rbl-allowed: <***@notmydesk.com> to <***@space.net>

that are clearly spam are not accounted to spam.

Post by Matthias Andree

Post by Markus Stumpf
If one would reject multi RCPT at all it would still cause no big harm to
the Internet Mailsystem per se, neither would it result in a breakdown.

Apparently you have a very different perception of when things stop
working.

Apparently you have no clue.
We had a customer that was attacked by dict spams with muli RCPT
connections. I did a patch that disabled multi RPCT by accepting the
first RCPT and sending a "451 Too many recipients" to all successive
RCPT commands had no impact on the legal email traffic (all messages
arrived properly) but had a dramatic cut down on the number of spam injects.

Post by Matthias Andree
You're guessing, but you don't have figures nor profiles. Just because
qmail doesn't do it, doesn't mean others don't do it either.

I didn't say that no other mailserver are capable doing it. I said IMHO
most admin turn it off. So, I don't have exact numbers on this. But you
don't have exact numbers at all.

Post by Matthias Andree
Software will try to sort a limited amount of recipients at least to
conserve bandwidth; beyond that SMTP doesn't guarantee more than 100
recipients per mail.

Bullshit. "Software" will not do that.

Post by Matthias Andree
You're still trying to justify rejecting the whole transaction if one of
the multi-RCPT is botched. You'll lose legitimate mail that way unless
you're the only user.

No, I will loose nothing.
The email will be rejected and the sender will get notification, just
like in a single RCPT message. Ig he cares he will correct the error and
resend.

Post by Matthias Andree
The figures show that multi-RCPT is an important feature.

No they don't.

Post by Matthias Andree
Indeed it does, that's a case where four users are subscribed to the
same list.

So this is important for that list sending it to four of your users.
We're receiving mail from (legitimate) lists to some hundred of
customers, some in the same domain, most in different. They all come
single RCPT, and the sending systems aren't qmail and the list manager
isn't ezmlm.
So you have your four recipients on one list against some hundred users
on some 100 lists.

As I said before: get a clue about how the Internet mail structure works
in general and get out of your limited view.

\Maex

[Jonathan de Boyne Pollard]

MA> Taking Uwe's observation into account that spammers don't often
MA> go for multi-RCPT, you'd need to reject single-RCPT as well, but
MA> nobody suggests that when rejecting multi-RCPT is fine with
MA> everybody. Why don't you people (this isn't directed at adi)
MA> apply the same standards?

MS> 1) You're loosing the topic again.

He's not losing it, though.

MS> 2) Millions of Mailservers reject zillions of connections of
MS> single-RCPT transactions each day.

No, they don't. The reject the transactions on _other_ grounds.

MS> So what are you talking about?

It's pretty clear what he's talking about. The argument put forward in favour
of discarding all multi-recipient transactions in their entirety is that they
have a very high correlation to whether the mail involved is unsolicited bulk
mail. But this argument can equally well be applied to single-recipient
transactions. From what Uwe's has said, there is also a reasonably good
correlation between whether a mail is a single-recipient transaction and
whether it is unsolicited bulk mail. The same argument thus applies to both
classes of transaction; and thus if one adheres to it properly and logically
one must reject _both_ single-recipient and multi-recipient transactions, as
they _both_ have a good correlation to whether the mail involved is
unsolicited bulk mail. To apply the argument non-uniformly, when there is a
correlation in both cases, would be hypocritical.

In other words, the argument is flawed, and the mechanism that resulted from
it is but one more example of the fundamental design flaw in technical
anti-UBM measures and of their adverse consequences: The designs of anti-UBM
measures incorporate looking for some element, that is common to some number
of unsolicited bulk mail messages but that is not actually directly related to
their undesirable "unsolicited" and "bulk" qualities, and blocking all
messages with that element, unsolicited bulk ones or no. The senders of
unsolicited bulk mail simply end up removing or changing this element, and the
problem continues. In the long run, all that results is that SMTP becomes
less usable and patchy, as all of these various blocks and protocol
violations, and the collateral damage from their false positives, accumulate.

[Markus Stumpf]

Post by Jonathan de Boyne Pollard
messages with that element, unsolicited bulk ones or no. The senders of
unsolicited bulk mail simply end up removing or changing this element, and the
problem continues.

One goal could be to drive the senders of UCE into a corner and then
shoot them.

Post by Jonathan de Boyne Pollard
In the long run, all that results is that SMTP becomes
less usable and patchy, as all of these various blocks and protocol
violations, and the collateral damage from their false positives, accumulate.

So what?

- >60% of all messages we receive are spam.
- all Exchange servers have broken autoresponders that lead to maillops in
case of errors
- thousands of hosts violate the protocol by sending stray newlines
- zillions of hosts have broken configurations
- thousands of misconfigured SMTP servers send emails with non existing
envelope senders
- thousands of domain are broken with regard to DNS (i.e. lookups for MX
or A return SERVFAIL).

You think it will become worse than now?
Improve the logging of your SMTP Server and have a look at the logfiles.
Most admins don't even recognize what's going on ...

And: as long as the "violations" only hurt myself (i.e. false positives)
nobody else than me has to worry and it doesn't result in collateral
damage. And even if all mailserver in the Internert would start to
reject multi RCPT and enforce single RCPT there would be no collateral
damage.

\Maex

[Matthias Andree]

Post by Markus Stumpf
- >60% of all messages we receive are spam.
- all Exchange servers have broken autoresponders that lead to maillops in
case of errors
- thousands of hosts violate the protocol by sending stray newlines
- zillions of hosts have broken configurations
- thousands of misconfigured SMTP servers send emails with non existing
envelope senders
- thousands of domain are broken with regard to DNS (i.e. lookups for MX
or A return SERVFAIL).

- thousands of "news letters" have web-based subscription forms but do
not verify if it was really the sender who subscribed. Abuse galore.

Post by Markus Stumpf
You think it will become worse than now?

Yes. Adding deliberate breakage is going to increase the pain.

Post by Markus Stumpf
And: as long as the "violations" only hurt myself (i.e. false positives)
nobody else than me has to worry and it doesn't result in collateral
damage. And even if all mailserver in the Internert would start to
reject multi RCPT and enforce single RCPT there would be no collateral
damage.

Increased and unnecessary traffic from smarthosts for outgoing mail is
no collateral damage? Interesting POV, but invalid.

[Erwin Hoffmann]

Post by Jonathan de Boyne Pollard
In other words, the argument is flawed, and
1. the mechanism that resulted from
it is but one more example of the fundamental design flaw in technical
anti-UBM measures and
2. of their adverse consequences: The designs of anti-UBM
measures incorporate looking for some element, that is common to some number
of unsolicited bulk mail messages but that is not actually directly related to
their undesirable "unsolicited" and "bulk" qualities, and blocking all
messages with that element, unsolicited bulk ones or no.
The senders of
unsolicited bulk mail simply end up removing or changing this element, and the
problem continues. In the long run, all that results is that SMTP becomes
less usable and patchy, as all of these various blocks and protocol
violations, and the collateral damage from their false positives, accumulate.

Ack. However, the wisdom you share with us, doesn't help anyone.

Finally (IMHO), the spammers

(a) will generate emails conforming to every RFC and avoiding specific (SMTP) features.
(b) will learn to translate the messages such it is human-readable but very hard to analyse by software.

In conclusion, any classification method based on structural and/or textual analysis will eventually fail [we see this already happening with SpamAssassin].

One solution: Post-Initial Receipt blocking - as soon as a email is identified as spam in a spam attack, block mails from that sender.

regards.
--eh.

PS: A discussion about that can be found (ok, in german language I confess) at
http://www.fehcom.de/qmail/qmailbook.html reading section 7.2.
+-----------------------------------------------------------------------+
| fff hh http://www.fehcom.de Dr. Erwin Hoffmann |
| ff hh |
| ff eee hhhh ccc ooo mm mm mm Wiener Weg 8 |
| fff ee ee hh hh cc oo oo mmm mm mm 50858 Koeln |
| ff ee eee hh hh cc oo oo mm mm mm |
| ff eee hh hh cc oo oo mm mm mm Tel [phone] |
| ff eeee hh hh ccc ooo mm mm mm Fax [phone] |
+-----------------------------------------------------------------------+

[Matthias Andree]

Post by Erwin Hoffmann
Finally (IMHO), the spammers
(a) will generate emails conforming to every RFC and avoiding specific
(SMTP) features. (b) will learn to translate the messages such it is
human-readable but very hard to analyse by software.
In conclusion, any classification method based on structural and/or
textual analysis will eventually fail [we see this already happening
with SpamAssassin].
One solution: Post-Initial Receipt blocking - as soon as a email is
identified as spam in a spam attack, block mails from that sender.

Paul Graham recently published another article on his spam thoughts, I'm
quoting some parts below.

One of his ideas is to let spam filters actually request advertised
URLs:

"So I'd like to suggest an additional feature to those working on
spam filters: a "punish" mode which, if turned on, would retrieve
whatever's at the end of every url in a suspected spam n times,
where n could be set by the user. [4]

[...]

The huge volume of the spam, which has so far worked in the
spammer's favor, will now work against him, like a branch snapping
back in his face. Auto-retrieving spam filters will drive the
spammer's costs up, and his sales down: his bandwidth usage will go
through the roof, and his servers will grind to a halt under the
load, which will make them unavailable to the people who would have
responded to the spam.

[...]

We should try to ensure that this is only done to suspected
spams.

[...] auto-retrieval should be combined with blacklists of
spamvertised sites. Only sites on a blacklist would get
auto-retrieved, and sites would be blacklisted only after being
inspected by humans. [...]" -- Paul Graham,
http://www.paulgraham.com/ffb.html

His [4] footnote mentions that the anti-spam software needs to follow
redirects to a certain level.

Of course, this is somewhat dangerous and requires trust to the
black-list. If it's a melting-pot style list such as the merged
spews.org list, it's going to hit innocents big time.

[James Craig Burley]

Post by Matthias Andree
Of course, this is somewhat dangerous and requires trust to the
black-list. If it's a melting-pot style list such as the merged
spews.org list, it's going to hit innocents big time.

No kidding. I just sent him an email about this. Given that my
jcb-sc.com domain name is already an innocent victim of significant
quantities of joe jobs, I really don't want a whole bunch of stupid
email clients deciding to ping my various web sites in response to
each spam sent out by the first spammer who decides to "teach us a
lesson" by turning our collective fists against us.

And, no, whitelists and blacklists pertaining to URLs won't help --
that just recurses back to the same sets of problems we've had trying
to whitelist and blacklist SMTP clients, SMTP servers, IP addresses,
DNS addresses, and so on.

He makes a lot of good points in his article(s), though.

[Henning Brauer]

Post by Matthias Andree
Paul Graham recently published another article on his spam thoughts, I'm
quoting some parts below.
One of his ideas is to let spam filters actually request advertised
"So I'd like to suggest an additional feature to those working on
spam filters: a "punish" mode which, if turned on, would retrieve
whatever's at the end of every url in a suspected spam n times,
where n could be set by the user. [4]
[...]
The huge volume of the spam, which has so far worked in the
spammer's favor, will now work against him, like a branch snapping
back in his face. Auto-retrieving spam filters will drive the
spammer's costs up, and his sales down: his bandwidth usage will go
through the roof, and his servers will grind to a halt under the
load, which will make them unavailable to the people who would have
responded to the spam.
[...]
We should try to ensure that this is only done to suspected
spams.
[...] auto-retrieval should be combined with blacklists of
spamvertised sites. Only sites on a blacklist would get
auto-retrieved, and sites would be blacklisted only after being
inspected by humans. [...]" -- Paul Graham,
http://www.paulgraham.com/ffb.html

this is utterly stupid.
best dDoS ever perhaps.
just spam for your competitor's site...

[Donald L. Nash]

--On Wednesday, August 13, 2003 9:02 PM +0200 Henning Brauer

Post by Henning Brauer
this is utterly stupid.
best dDoS ever perhaps.
just spam for your competitor's site...

That'll only work if your competitor is already a known spammer or

Post by Henning Brauer

Post by Matthias Andree
[...] auto-retrieval should be combined with blacklists of
spamvertised sites. Only sites on a blacklist would get
auto-retrieved, and sites would be blacklisted only after being
inspected by humans. [...]" -- Paul Graham,

That means you have to trust the blacklist operators, of course. Paul
addresses this point in footnote 5 of his paper:

There should probably be multiple blacklists. A single point
of failure would be vulnerable both to attack and abuse.

[Matthias Andree]

Post by Uwe Ohse

Post by Matthias Andree
I maintain that the recipient side does not know with how many RCPT TO
headers a mail has been injected, unless it looks at the mails.

could you please tell me how to get delivery level information from the
mail? From _this_ mail, please?

You're asking the wrong person. Maex is the person who claims to be able
to derive such information by just looking at MAIL FROM and RCPT TO at
the receiving end.

[10% multi-RCPT]

Post by Uwe Ohse
I wouldn't call that a big win, but i'm sure you do.

That's how SMTP works.

Post by Uwe Ohse
has it ever occured to you that you get insulted often here?
I think it's possible that this is due to you attitude.

Objecting to deliberate protocol violations is grounds to insult?
Strange folks post here...

Post by Uwe Ohse
That's true for the "postfix is good and whatever you see as a postfix
misfeature is a feature to me"-automaton on this list, too.

I don't care about features, but (deliberate) misrepresentation, for
example when it comes to softupdates.

[Dave Sill]

Post by Matthias Andree
I don't care about features, but (deliberate) misrepresentation, for
example when it comes to softupdates.

Deliberate? What makes you think anyone deliberately misrepresented
softupdates, Postfix, or anything else here?

-Dave

[Matthias Andree]

Post by Dave Sill
Deliberate? What makes you think anyone deliberately misrepresented
softupdates, Postfix, or anything else here?

That we've been through putting softupdates facts straight months ago
and still claims that no MTA could operate safely on softupdates are
made again, and particularly by people who have "search the archives",
"stop wasting our time" and other similar phrases bound to function keys
or keyboard macros...

[Jonathan de Boyne Pollard]

MS> You [Matthias] don't know anything about "The Internet mail
MS> system" and especially not about communication structures and
MS> communication behaviour using the SMTP protocol.

It's patently true that he knows a fair amount. That's unwarranted.

There should be a variation on Godwin's Law that states: When someone has
produced a software that implements some protocol incorrectly; if the
discussion of the protocol violation continues for long enough, the
probability, that the software writer or his/her apologists will stop talking
about the protocol and its implementation and instead start baldly asserting
that the people who are pointing out (and even possibly showing how to
correct) the violation know nothing about the protocol in question or its
implementation and are out of touch with the real world (usually despite the
ample evidence in the discussion up to that point), will approach one.

At which point, it becomes time to invoke Dukhat.

[Markus Stumpf]

Post by Jonathan de Boyne Pollard
discussion of the protocol violation continues for long enough, the
probability, that the software writer or his/her apologists will stop talking
about the protocol and its implementation and instead start baldly asserting
that the people who are pointing out (and even possibly showing how to
correct) the violation know nothing about the protocol in question or its
implementation and are out of touch with the real world (usually despite the
ample evidence in the discussion up to that point), will approach one.

I have *never* argued for the goodrcptto patch.
I have stated that multi RCPT in overall Internet traffic is not as
important as all the urban legends and their supporters tell.

\Maex

[Matthias Andree]

Post by Markus Stumpf
I have *never* argued for the goodrcptto patch.
I have stated that multi RCPT in overall Internet traffic is not as
important as all the urban legends and their supporters tell.

The same is true for SMTP, thus, mail. It's not as important compared to
HTTP and file sharing traffic. What point are you trying to make?

Justify off-topic ad-hominem attacks on authors of older goodrcptto
patch criticism?

What made you try to justify goodrcptto patch bugs in the first place?

[Markus Stumpf]

Post by Matthias Andree
What made you try to justify goodrcptto patch bugs in the first place?

Repeating things ten times seems to not be enough to make it it's way into
your brain.
Let's try it the other way: show me the sentence where I "justify
goodrcptto patch bugs" or shut up.

\Maex

P.S. This is "shut up".

[Eben]

Post by Markus Stumpf
Let's try it the other way: show me the sentence where I "justify
goodrcptto patch bugs" or shut up.

The subject of this thread doesn't apply to the goodrcptto v7 patches, see
http://netdevice.com/qmail.

[Jonathan de Boyne Pollard]

MS> Please note that this mailserver is used by our customers as an
MS> outgoing relay and also by external users as a MX host. If you
MS> think this will make the data inaccurate I could try to filter
MS> out our customers to get better figures.

How kind of you to offer to filter out the class of transactions that is the
_more_ likely of the two to involve multiple-recipient transactions! (-:

Try filtering out the external users, in order to see what the incidence of
multiple-recipient transactions from your customers is.

[Markus Stumpf]

Post by Jonathan de Boyne Pollard
How kind of you to offer to filter out the class of transactions that is the
Try filtering out the external users, in order to see what the incidence of
multiple-recipient transactions from your customers is.

I could also filter out all SMTP transactions and proof that UUCP rulez.
And I could use the statistics of our bulk server where pseudo mailinglists
are injected in bunches of 100 recipients (by PHP scripts or by Outlook
e.g.) but all of these are not MX deliveries but smarthost deliveries.

\Maex

[John R. Levine]

Post by Eben

Post by Jonathan de Boyne Pollard
E> In it's current form, it doesn't accept an email with any bad
E> recipients, it rejects the message at the data request.
That's the flaw.

It's a feature for the reasons given in the patch text, not a flaw.
John Levine's badrcptto patch does the same thing.

I think people may be misunderstanding what badrcptto is for.

Since some of my domains date back to 1993 and 1995, I get a great
deal of spam to addresses that were scraped a long time ago, many by
broken scrapeware that got the addresses wrong so that the the target
addresses of the spam were never valid and so get 100% spam.

I long ago made those addresses into spamtraps, but in recent months
the amount of spam has gone up so much that bouncing the spam has
become a siginificant load on my system, particularly since most of
the return addresses are fake so the bounces all double bounce. I'm
also getting a lot of bounces from other places to bogus addresses in
my domains forged (out of spite I presume) as return addresses on spam
sent to random people all over the net. I've gotten as many as 50,000
bounces a day to forged abuse.net addreses, and double bouncing all
those slows my system to a crawl.

The point of badrcptto is to reject mail to the spamtrap addresses and
forged bounce addresses more efficiently, and maybe make the
rejections show up in the postmaster mailbox of whatever insecure host
was used to relay the mail. Mail sent to a spamtrap address is always
spam, even if it's also addressed to a live address (my main address
hasn't changed since 1993, so it gets a whole lot of spam, too.)
That's why the patch bounces mail if any of the RCPT TO addresses are
bad.

The reason it bounces at DATA rather than RCPT TO is twofold. The
main reason is to deter dictionary attacks. Many people have noted
that qmail systems are rarely targets of dictionary attacks; I gather
that a fairly standard technique used by spamware is to precede a
dictionary attack with a RCPT TO a nonsense address, and if it gets
250, it gives up since it won't be able to validate addresses. I
didn't want to lose that. Also, if spam comes in with a good address
followed by a bad one, I still don't want to receive the mail, and
since it'd already have given a 250 to the good address, it has to
fail the DATA command anyway.

I'm aware of the goodrcptto derivative of my patch. I have no
interest in it, since my mail system is way too complex to enumerate
all of the valid addresses. Its goals are presumably different from
those of badrcptto, so there's no reason to think that the design
decisions that work for me would work for it.

If I were going to validate addresses at SMTP time, I wouldn't stop
there. There are plausible reasons to do spam filtering at SMTP time
(bounce bad mail to the sending host, do realtime checks that don't
work as well once the mail has been queued.) So if you've validated
the address, and done the spam filtering, for the common case where
mail is just delivered into a mailbox or maildir, I'd call the
delivery agent directly from the SMTP daemon and be done with it, only
queueing mail for addresses that need more complicated processing.

This is sort of a reverse version of my Qspam.pm mail sending script.
It attempts to deliver all the mail it generates directly by calling
qmail-remote and only queues mail that's either local (qmail-remote
does wacky things with mail destined for the local system) or can't be
delivered on the first try. When I use Qspam.pm, I generally see
upwards of 90% of the mail delivered directly with under 10% queued,
and I suspect that for inbound mail to a typical system that's mostly
or entirely a POP toaster, I'd see the same thing.

Regards,
John Levine, ***@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"More Wiener schnitzel, please", said Tom, revealingly.

[James Craig Burley]

Post by John R. Levine
Since some of my domains date back to 1993 and 1995, I get a great
deal of spam to addresses that were scraped a long time ago, many by
broken scrapeware that got the addresses wrong so that the the target
addresses of the spam were never valid and so get 100% spam.
I long ago made those addresses into spamtraps, but in recent months
the amount of spam has gone up so much that bouncing the spam has
become a siginificant load on my system, particularly since most of
the return addresses are fake so the bounces all double bounce. I'm
also getting a lot of bounces from other places to bogus addresses in
my domains forged (out of spite I presume) as return addresses on spam
sent to random people all over the net. I've gotten as many as 50,000
bounces a day to forged abuse.net addreses, and double bouncing all
those slows my system to a crawl.

John's story is pretty much exactly the same as mine, except my bounce
and double-bounce numbers aren't nearly as high. There are only two
real people "behind" the three domain names I own -- myself and my
wife. Only one domain name (jcb-sc.com) gets any serious spam
traffic. qmail forwards email sent to my wife's email addresses
directly to her account at work.

Yet my system has about 240 emails in the queue, waiting to go out,
all of it bounces of spam. I've had qmail deliver double bounces into
/dev/null for over a week now, after carefully watching a
spam-gathering Mailbox for a week to verify that nothing useful was
showing up there. I think those "deliveries" account for the majority
of email activity on my system.

My server has no trouble keeping up with this load. My only problem
with it is the extra time it takes to review my system's log files.
But, in theory, things could get worse.

So badrcptto probably makes sense for me. I don't intend to reject
simple typos, so I don't think I want goodrcptto, but the spamtrap
addresses I've used in the past are as close to 100% reliable
indicators that an incoming message is spam as is feasible to detect
via technology, regardless of how many other legitimate email
addresses are listed in the RCPT TO of the message.

Rejecting such emails during the SMTP session makes a lot of sense to
me, since it means I won't have to view the spam if it happens to
include my correct email addresses in the header. If my system can be
"legally" configured to dump detected spam, bounces of spam, and
double bounces into /dev/null, and can be configured to bounce
post-SMTP-detected spam based on spamtrap addresses in the headers,
there's no basis I can see for the claim that I must not reject
SMTP-time-detected spam (or, for that matter, effectively direct it
into /dev/null, perhaps with some kind of tarpitting enabled as long
as my server's resources allow) based on certain known spamtrap
addresses appearing in RCPT TO.

My main reason for not using badrcptto right now is that I'm too lazy
and/or careful about patching a qmail setup that has been working (and
basically bulletproof) for several years now.

Oh, one more somewhat-related item: just for fun, I put up a new
spamtrap address on the home page of my original web site (the one
shown below currently just redirects to it). I used white-on-white as
a primitive means to obscure it from most readers, along with verbeage
to alert humans to the fact that it's a spamtrap. And I set up a
.qmail file named .qmail-vikings to bounce any email sent to it, using
a distinctive bounce message:

|bouncesaying 'Spam spam spam spam spam spam spam spam Wonderful Spam, Marvelous Spam.'

Within just a few hours of putting it up, I got my first email to
craig-vikings, and have since gotten at least one more. And that spam
had to get through the pre-qmail-smtpd bad-reverse-DNS check and
qmail-smtpd badmailfrom checks first -- though I don't, of course,
know how many other spams would have been sent to that address if
those earlier filters weren't in place.

So even the ancient practice of web crawling for email addresses to
spam is alive, well, and quick on its feet.

Which means we will, indeed, probably have to maintain any anti-spam
technologies we deploy for a very long time: though the leading edge
of the spammers' technology advances, its trailing edge doesn't have
to keep up, and what's in the middle is basically just a bunch of bots
doing what they've always done, and not caring one whit about their
success rate, since cycles and TCP connections are cheap.

[Gerrit Pape]

Post by m***@csi.hu

Post by Markus Stumpf
3) I have a "goodrcptto" patch in qmail-smtpd. If a file
/var/qmail/control/goodrcptto/<domain>
exists it contains all the valid addresses for that domain.
All other addresses will be rejected at SMTP level. IMHO there were
other implementations of such a patch folating around in the list
2-5 weeks ago. Problem are wildcard (aka .qmail-default) addresses
that are IMHO not supported by these patches (and neither by mine).

That would be the good solution, IMO. The problem is that under qmail
people create new addresses all the time (like mailinglists), so I
think wildcards are a must.

Here's an example mailrules file for the use with smtpfront-qmail from
the mailfront package:

$ cat mailrules
k*:***@example.org
k*:goodaddress1-*@example.org
k*:***@example.org
k*:goodaddress2-*@example.org
k*:***@example.org
k*:***@example.org
k*:mailer-***@example.org
k*:***@example.org
d*:floyd*@example.org:This address is used as an example on web pages only, and doesn't receive mail.
d*:pink*@example.org:This address is used as an example on web pages only, and doesn't receive mail.
d*:burdon*@example.org:This address is used as an example on web pages only, and doesn't receive mail.
d:*@example.org:This address cannot get bounces, the envelope of the mail you bounce is forged.
d*:*@example.org:Sorry, no mailbox here by that name.
$
$ telnet a.mx.smarden.org 25
Trying 212.21.76.77...
Connected to smarden.org.
Escape character is '^]'.
220 smarden.org ESMTP
mail from:<>
250 Sender accepted.
rcpt to:<***@smarden.org>
553 This address cannot get bounces, the envelope of the mail you bounce is forged.
quit
221 Good bye.
Connection closed by foreign host.
$

Regards, Gerrit.

[Tom Smith]

Post by Gerrit Pape
Here's an example mailrules file for the use with smtpfront-qmail from
$ cat mailrules

How well does this work in high volume domains?

*Example:* A domain I have yet to convert to qmail currently receives
about 1 million emails sent to unknown recipients. These emails are
rejected with "user unknown" so we never queue the message. We get a few
of these per second. Of the million or so we receive around 35 thousand
are to unique email addresses and the rest are duplicates--that is, the
RCPT TO is the same.

[Gerrit Pape]

Post by Tom Smith

Post by Gerrit Pape
Here's an example mailrules file for the use with smtpfront-qmail from

How well does this work in high volume domains?

I'm not sure, but judging from the source, mailfront is pretty effective,
and doesn't use a lot resources. For your example below, you might be
interested in the other interface (CVM) mailfront provides to validate
recipients though.

Post by Tom Smith
*Example:* A domain I have yet to convert to qmail currently receives
about 1 million emails sent to unknown recipients. These emails are
rejected with "user unknown" so we never queue the message. We get a few
of these per second. Of the million or so we receive around 35 thousand
are to unique email addresses and the rest are duplicates--that is, the
RCPT TO is the same.

I would suggest you test the package, get familiar with it, and judge
yourself.

Regards, Gerrit.

[Matthias Andree]

Post by Markus Stumpf
It depends on what you mean with "deal".
2) If you have e.g. the SPAMCONTROL patch you can use a small
script (or these two lines) in .qmail-default like
| echo "$RECIPIENT" >> /var/qmail/control/badrcptto
| exit 100
This will cause the message to bounce and the recipient to be added
to the badrcptto file, so that subsequent messages to that address
will be rejected at SMTP level. However, if the messages come in at a
high rate you'd better use some locking for the badrcptto file to not
damage the file.

Providing that your echo command emits all its data in a single write(2)
syscall and to a local file system, you don't need to care for locking
in append mode. Unix-compatible systems handle this for you, by bumping
the file pointer to the very end of the file immediately and atomically
before the - also atomic - write(2). And as the write(2) itself is
atomic, you don't need to fear you get one half of the line, then
another line, and then the second half of the first line.

Post by Markus Stumpf
3) I have a "goodrcptto" patch in qmail-smtpd. If a file
/var/qmail/control/goodrcptto/<domain>
exists it contains all the valid addresses for that domain.
All other addresses will be rejected at SMTP level. IMHO there were
other implementations of such a patch folating around in the list
2-5 weeks ago. Problem are wildcard (aka .qmail-default) addresses
that are IMHO not supported by these patches (and neither by mine).

The patch is way too aggressive and interrupts delivery of legitimate
mail, see my other mail in this thread.

[r***@iland.net]

Post by m***@csi.hu
How do people deal with this?

We modified the code slightly to delete a message after the first bounce,
thereby eliminating double bounces. Look in qmail-send.c and find where a
double bounce is created, modify that code slightly so that a double bounce
never happens ( I believe that you just need to take out one if statement and
then modify another, around line 688). If you need more details let me know.

Randy

[Matthias Andree]

Post by m***@csi.hu
1) A spammer sends a spam to some address with a return-path of the form
where `someone' is a varying local part
2) The recipient of the spam bounces the message to my server, where
it doublebounces since `someone' usually does not exist.

...

Post by m***@csi.hu
How do people deal with this?

a. Make sure your machine rejects undeliverable mail at the SMTP port
rather than accepting, queueing and bouncing it. This prevents the
doublebounce from being created on YOUR machine, instead it's created
at the SMTP client's machine, imail.ru for example.

This requires patching or replacing qmail-smtpd, or switching
MTA. I've switched MTA and haven't researched what options are
available, but I have seen some, and I recall one of these solutions
was for qmail-ldap.

This prevents your machine from generating the doublebounces that
crowd your postmaster mailbox.

b. possibly use content-based spam filters, spamAssassin or bogofilter
or spamprobe, you name it, to either reject such junk at the SMTP
port or redirect this junk from your regular mailboxes to a separate
folder.

[Jean-Francois Guilmard]

Hi,

I'm using qmail and I'd like to forward emails a user receive to an
external address...
Ex: my qmail deals with ***@toto.com and it must forward email received
by this address ***@toto.com to ***@hotmail.com ...

Thanks

Jeff

[Charles Cazabon]

Post by Jean-Francois Guilmard
I'm using qmail and I'd like to forward emails a user receive to an
external address...

`man dot-qmail` tells you how to do this.

By the way, you seem to have replied to an unrelated message to post your
question. Please don't do that; it messes up threading in our MUAs and the
list archives. Please start a new thread next time.

Charles

[gary]

Post by Jean-Francois Guilmard
Hi,

Your subject is taken from another email thread, and has nothing to do
with your question.

Post by Jean-Francois Guilmard
I'm using qmail and I'd like to forward emails a user receive to an
external address...

The answer lies in your own computer. man dot-qmail

[Larry Weldon]

Post by Jean-Francois Guilmard
Hi,
I'm using qmail and I'd like to forward emails a user receive to an
external address...
Thanks
Jeff

Please start a new thread. The essentials are in 'man dot-qmail'

Larry Weldon

[Jean-Francois Guilmard]

Sorry guys ... I totally missed my sent ...

Too much work ?

Jeff

-----Original Message-----
From: gary [mailto:gv-dated-***@mygirlfriday.info]
Sent: Tuesday, July 08, 2003 3:08 PM
To: ***@list.cr.yp.to
Subject: Re: bounced spam

On Tue, Jul 08, 2003 at 02:52:53PM -0700 or thereabouts, Jean-Francois

Post by Jean-Francois Guilmard
Hi,

Your subject is taken from another email thread, and has nothing to do
with your question.

Post by Jean-Francois Guilmard
I'm using qmail and I'd like to forward emails a user receive to an
external address...

The answer lies in your own computer. man dot-qmail

[Eben]

Post by John R. Levine

Post by Eben

Post by Jonathan de Boyne Pollard
E> In it's current form, it doesn't accept an email with any bad
E> recipients, it rejects the message at the data request.
That's the flaw.

It's a feature for the reasons given in the patch text, not a flaw.
John Levine's badrcptto patch does the same thing.

I think people may be misunderstanding what badrcptto is for.

...

Post by John R. Levine
The reason it bounces at DATA rather than RCPT TO is twofold. The
main reason is to deter dictionary attacks. Many people have noted
that qmail systems are rarely targets of dictionary attacks; I gather
that a fairly standard technique used by spamware is to precede a
dictionary attack with a RCPT TO a nonsense address, and if it gets
250, it gives up since it won't be able to validate addresses. I
didn't want to lose that. Also, if spam comes in with a good address
followed by a bad one, I still don't want to receive the mail, and
since it'd already have given a 250 to the good address, it has to
fail the DATA command anyway.
I'm aware of the goodrcptto derivative of my patch. I have no
interest in it, since my mail system is way too complex to enumerate
all of the valid addresses. Its goals are presumably different from
those of badrcptto, so there's no reason to think that the design
decisions that work for me would work for it.

The design of the current goodrcptto patches has changed to not reject the
message if there are bad recipients in a multiple recipient email.
Malicious connections may be handled by a cron that looks at the logs and
updates tcprules accordingly.
The grtcheck works similar to the way addrallowed screens out bad recipient
addresses, while allowing the good recipients to receive that email.
There is no longer a block at the DATA command based on screened out bad
addresses.
A qmail server will normally accept email for any recipient name at a domain.
Using this patch, non existent recipients are screened out and the email is
accepted only for the existent ones.
Instead of updating a badrcptto list when bad recipient email comes in, a
goodrcptto list and/or moregoodrcptto database is maintained.
When a good address starts receiving spam, remove it.
There's a reduction in disk IO, as spam and joe job double bounces to forged
recipients is rejected.
The qmail-smtpd logs show the bad recipient hosts, bad and forged recipient
users, and bad envelope sender addresses that were rejected.
...
If you can't account for your addresses, do not use this patch.

[Louis Theran]

The percentage of MAIL FROM to RCPT TO shows that the use of the
"feature" of using /multi/ RCPT TO for /one/ MAIL FROM is as good as
not existing.

This means that time spent implementing heuristics that try to exploit
multiple RCPT delivery is nearly always wasted.

It does not mean senders legitimately using multiple RCPT shouldn't be
able to reasonably expect their messages to be accepted. It's a big
hassle for users injecting mail with dumb clients when their message is
rejected with no useful indication of which address was the problem.

^L

[Markus Stumpf]

Post by Louis Theran
It does not mean senders legitimately using multiple RCPT shouldn't be
able to reasonably expect their messages to be accepted.

I never said anything else. I only brought arguments and numbers that
show that the "multiple RCPT is wide spread and important" is an urban
legend.

Post by Louis Theran
It's a big
hassle for users injecting mail with dumb clients when their message is
rejected with no useful indication of which address was the problem.

The easiest way to solve this problem is to not use dumb clients as you
will have this problem with every failure, not only with rejected multi
RCPT.

\Maex

[Louis Theran]

Post by Markus Stumpf

Post by Louis Theran
It does not mean senders legitimately using multiple RCPT shouldn't be
able to reasonably expect their messages to be accepted.

I never said anything else. I only brought arguments and numbers that
show that the "multiple RCPT is wide spread and important" is an urban
legend.

It is wide-spread and important as a feature used by dumb clients that
inject messages with SMTP (e.g., Apple Mail, Eudora, mh, etc.). Enough
MTAs (e.g., sendmail, postfix) use it on occasionally that people will
notice the failures.

Post by Markus Stumpf

Post by Louis Theran
It's a big
hassle for users injecting mail with dumb clients when their message is
rejected with no useful indication of which address was the problem.

The easiest way to solve this problem is to not use dumb clients as you
will have this problem with every failure, not only with rejected multi
RCPT.

A server relaying mail for dumb clients should accept the message and
generate a bounce describing which recipients failed. This is the
default behavior for qmail. Checking RELAYCLIENT would fix this
particular problem, but the patch at

http://www.chater.demon.co.uk/qmail/

doesn't. Another patch with the same name from

http://netdevice.com/qmail

does. Both are nearly certain to reject messages users wanted and were
expecting. I haven't looked carefully enough to know what other
apparently irrelevant decisions the authors of these patches made that
would at best waste people's time.

^L

[Louis Theran]

Post by Louis Theran
Both are nearly certain to reject messages users wanted and were
expecting.

Sorry to reply to myself, but this isn't quite right. The patch from

http://netdevice.com/qmail/goodrcptto.v7.patch

will deliver a message to any of the recipient addresses that pass
grtcheck() and reject the ones that don't.

In another message[1] the author of this patch wrote: ``In it's
current form, it doesn't accept an email with any bad recipients, it
rejects the message at the data request,'' but I don't see anything in
the patch that does that. This behavior was what motivated my ``nearly
certain to reject messages...''

^L

[1] http://marc.theaimsgroup.com/?l=qmail&m=105815264228782&w=2

[Eben]

Post by Louis Theran
http://netdevice.com/qmail/goodrcptto.v7.patch
will deliver a message to any of the recipient addresses that pass
grtcheck() and reject the ones that don't.

That's correct.

Post by Louis Theran
In another message[1] the author of this patch wrote: ``In it's
current form, it doesn't accept an email with any bad recipients, it
rejects the message at the data request,''

That was written about v6.

Post by Louis Theran
but I don't see anything in
the patch that does that. This behavior was what motivated my ``nearly
certain to reject messages...''

How it works should be clear to you if you read the v7 patch text and code.
Please understand and/or test it before making assumptions.

[Markus Stumpf]

Post by Louis Theran
It is wide-spread and important as a feature used by dumb clients that
inject messages with SMTP (e.g., Apple Mail, Eudora, mh, etc.). Enough
MTAs (e.g., sendmail, postfix) use it on occasionally that people will
notice the failures.

Repeating urban legends still keeps them urban legends.
I have given numbers on at least two large servers. Show me your numbers
or shut up.

And to repeat it again "I AM NOT DEFENDING ANY BROKEN PATCHES".
It's all about "wide-spread and important multi RCPT" being an urban legend.

Btw. RFC2821 clearly allows for a "too much recipients" and senders
have to take care of the situation. RFC2821 says you MAY not reject
based on the number of recipients, if the number is below 100.
There are more than enough mailservers out there that clearly violate
this (e.g. with tarpit/maxrcpt patches, not only in qmail):
RFC 2821 - Simple Mail Transfer Protocol
4.5.3.1 Size limits and minimums
recipients buffer
Rejection of messages (for excessive recipients) with fewer than
100 RCPT commands is a violation of this specification.
I have yet to see a case where this leads to a failure of the mailsystem.
In fact servers and even dumb clients handle the situation perfectly well.

\Maex

[adi]

Post by Markus Stumpf
Repeating urban legends still keeps them urban legends.
I have given numbers on at least two large servers. Show me your numbers
or shut up.

No, you should shut up. Your data tells nothing. Bandwidth saving
by using multiple rcpt to is about SENDING mail, it has nothing todo
with RECEIVING mail.

Anyway, it's about a very simple logic, really. Or, otherwise you
have to draw a better sampling frame from any email machines on this planet,
NOT only from your machines.

There are only three lies: lies, damn lies and statistics :-)

Regards,

P.Y. Adi Prasaja

[Uwe Ohse]

Post by adi
No, you should shut up. Your data tells nothing. Bandwidth saving
by using multiple rcpt to is about SENDING mail, it has nothing todo
with RECEIVING mail.

are you seriously suggesting that markus' numbers about the mails
received by his servers do not tell something about the number of
bits per month he'd waste if all the (few) multiple rcpt-to mails
would have been sent as single rcpt-to mails?

Post by adi
Anyway, it's about a very simple logic, really.

Yeah, it's about logic. Logic tells me that you are either a clone
of the list troll or an idiot.

Be gone.

[adi]

Post by Uwe Ohse
are you seriously suggesting that markus' numbers about the mails
received by his servers do not tell something about the number of
bits per month he'd waste if all the (few) multiple rcpt-to mails
would have been sent as single rcpt-to mails?

He has to take a considerable good sampling frame if he think
that his data is a representative of GENERAL cases.

Well, enough said. I'm out.

Thank you.

Regards,

P.Y. Adi Prasaja

[Markus Stumpf]

Post by adi
No, you should shut up. Your data tells nothing. Bandwidth saving
by using multiple rcpt to is about SENDING mail, it has nothing todo
with RECEIVING mail.

Ah. And where do you send your mail to without anyone receiving it?
And why do you send it at all, if there is nobody receiving it? You are
telling bullshit. get it?

Post by adi
Anyway, it's about a very simple logic, really. Or, otherwise you
have to draw a better sampling frame from any email machines on this planet,
NOT only from your machines.
There are only three lies: lies, damn lies and statistics :-)

Yeah, and there are clueless idiots like you initiating new lies, like
"mail is about sending and not receiving".

\Maex

[adi]

Post by Markus Stumpf
Ah. And where do you send your mail to without anyone receiving it?
And why do you send it at all, if there is nobody receiving it? You are
telling bullshit. get it?

Sorry Sir, but, it's about how to save bandwidth with/without using
multiple rcpt to.

On the sending side, for example, one wants to send single mail
to ten recipients: 4 recipients on domain x, 5 recipients on
domain y, and 1 recipient on your machine.

Regards,

P.Y. Adi Prasaja.

[Markus Stumpf]

Post by adi
Sorry Sir, but, it's about how to save bandwidth with/without using
multiple rcpt to.

No. It's about the urban legend that this feature is widely used.

Post by adi
On the sending side, for example, one wants to send single mail
to ten recipients: 4 recipients on domain x, 5 recipients on
domain y, and 1 recipient on your machine.

Ah ... and with two samples of totally different hosts (ours, with
mostly commercial customers and a second from a large university
in the USA, both with > 150000 messages a day) you say both samples
nearly always get the 1 recipient and all else get the 4 and 5.

Ok, why don't you show us your numbers.

\Maex

[Matthias Andree]

Post by Markus Stumpf

Post by adi
Sorry Sir, but, it's about how to save bandwidth with/without using
multiple rcpt to.

No. It's about the urban legend that this feature is widely used.

The feature is in use and it is guaranteed by the protocol, and the
protocol doesn't care whether you wince or jump when somebody claims
multi-RCPT is indispensable.

To recall the Subject to the discussion, goodrcptto v7, as described by
Eben, no longer has the problem of rejecting the mail for "good"
recipient mailboxes. I haven't looked at the new code yet.

[Markus Stumpf]

Post by Matthias Andree

Post by Markus Stumpf
No. It's about the urban legend that this feature is widely used.

The feature is in use and it is guaranteed by the protocol,

1) this is wrong. it is not /guaranteed/, but it is a option the
protocol offers.
RFC 2821 - 7.7 Scope of Operation of SMTP Servers pretty much
outrules a lot of MUSTs in the previous sections.
E.g. I MUST have a RCPT TO buffer that holds 100 recipients and
accept them, unless for any operational or technical reason that make
sense to me as the site providing the receiving server.
2) And exactly how does this contradict to my statement you've quoted?

Post by Matthias Andree
and the
protocol doesn't care whether you wince or jump when somebody claims
multi-RCPT is indispensable.

"At night it's colder than outside."
Didn't your pills work yet?

\Maex

[Matthias Andree]

Post by Markus Stumpf

Post by Matthias Andree

Post by Markus Stumpf
No. It's about the urban legend that this feature is widely used.

The feature is in use and it is guaranteed by the protocol,

1) this is wrong. it is not /guaranteed/, but it is a option the
protocol offers.
RFC 2821 - 7.7 Scope of Operation of SMTP Servers pretty much
outrules a lot of MUSTs in the previous sections.
E.g. I MUST have a RCPT TO buffer that holds 100 recipients and
accept them, unless for any operational or technical reason that make
sense to me as the site providing the receiving server.

Section 7.7 doesn't overthrow anything, it doesn't use capitalized
MUST/MAY/... keywords. You must also read the full section,

"(...)However, cooperation among sites and installations makes the
Internet possible. If sites take excessive advantage of the right
to reject traffic, the ubiquity of email availability (one of the
strengths of the Internet) will be threatened; considerable care
should be taken and balance maintained if a site decides to be
selective about the traffic it will accept and process.

In recent years, use of the relay function through arbitrary sites
has been used as part of hostile efforts to hide the actual origins
of mail.(...)"

Post by Markus Stumpf
Didn't your pills work yet?

When did you eat a child for supper the last time?

[Markus Stumpf]

Post by Matthias Andree
Section 7.7 doesn't overthrow anything, it doesn't use capitalized
MUST/MAY/... keywords. You must also read the full section,

So what?
It clearly states it's up to the admin to decide what he wants to accept.

\Maex

[Louis Theran]

Post by Eben
That was written about v6.

Previous versions aren't available, and you don't describe what changed
or why you changed it. If you don't want readers to assume that your
descriptions of your patch are correct, then be clear about which
version you are describing and when you intentionally made major
changes. (This will make supporting your patch easier as well.)

^L

[Eben]

Post by Louis Theran

Post by Eben
That was written about v6.

Previous versions aren't available, and you don't describe what changed

The older versions had sharp edges.
They are unavailable so that people don't hurt themselves.

Post by Louis Theran
or why you changed it. If you don't want readers to assume that your
descriptions of your patch are correct, then be clear about which
version you are describing and when you intentionally made major
changes. (This will make supporting your patch easier as well.)

The date of that post was before the date on the current patch, correct?
The text of the current patch always describes how that version works.
See the code for details.

Isn't this thread dead yet?

[george reaver]

Hello there...somehow I am being copied on these types of
messages...probably for about 2 days now...Could I somehow be on the
list server as below...If so would you have me taken off....Thanks very
much...George

-----Original Message-----
From: Louis Theran [mailto:***@cs.umass.edu]
Sent: Wednesday, July 23, 2003 3:44 PM
To: ***@list.cr.yp.to
Subject: Re: The "goodrcptto" patch causes problems for multi-recipient
messages and prevents pipelining

Post by Eben
That was written about v6.

Previous versions aren't available, and you don't describe what changed
or why you changed it. If you don't want readers to assume that your
descriptions of your patch are correct, then be clear about which
version you are describing and when you intentionally made major
changes. (This will make supporting your patch easier as well.)

^L