Hi,

Just wonder how one can set up Sendmail not to send bounce or reject
messages to spam sending machines?

Simon Gao

Simon Gao wrote:
> Hi,
>
> Just wonder how one can set up Sendmail not to send bounce or reject
> messages to spam sending machines?
>
> Simon Gao

In the default configuration Sendmail rejects mail, based on the access
and virtuser tables, (if configured) DNSBLs and other mechanisms. None
of these generate bounce messages, because Sendmail doesn't want to
send a bounce message to a possibly forged from address.

A rejection has no downside - the connecting host is responsible for
contacting the sender and spammers don't ever bother doing that.
Sendmail doesn't generate the rejection notice, it simply issues an
error code to the connecting host. The connecting host is usually an
"owned" PC and wouldn't even have the software to respond to a
rejection in that way. Only legitimate hosts bother to process the
rejection into a bounce message.

If you don't want to reject or bounce, then the access map accepts a
"DISCARD" option but it is not recommended because it will cause the
loss of mail without notice to the sender. I don't think you can tell
virtusertable or the DNSBL feature to discard. I suppose you could move
your anti-spam processing to the mail delivery agent (procmail, for
example) and discard messages thought to be spam, but there is an
important loss. Any legitimate message mistaken for spam will be lost,
while for a rejected message from a legitimate connecting host the
sender will get a DSN notice from the legitimate host. This will avoid
the inefficiency and embarrassment of a lost message. This works
because universally, spammers discard rejection notices, while
legitimate hosts do not. In this was rejection and bounce notices are
very different.

Daniel Feenberg
feenberg is at nber dotte org

Simon Gao wrote:
> Hi,
>
> Just wonder how one can set up Sendmail not to send bounce or reject
> messages to spam sending machines?
>
> Simon Gao

Depending on the size of your organization you might want to use
virtusertable.

user1@yourdomain.com user1
user2@yourdomain.com user2
..
..
..
@yourdomain.com bitbucket


then in your /etc/aliases have an entry

bitbucket /dev/null

In article <jl94h.419$sf2.73@newsfe12.lga> "J.R0wan"
<allspammerssuck@nomail.com> writes:
>Simon Gao wrote:
>> Hi,
>>
>> Just wonder how one can set up Sendmail not to send bounce or reject
>> messages to spam sending machines?
>>
>> Simon Gao
>
>Depending on the size of your organization you might want to use
>virtusertable.
>
>user1@yourdomain.com user1
>user2@yourdomain.com user2
>.
>.
>.
>@yourdomain.com bitbucket
>
>
>then in your /etc/aliases have an entry
>
>bitbucket /dev/null

This is of course a very bad solution, for the reasons described in
the other followup (which has the *correct* solution - i.e. reject the
message before it gets to the point where you have to send a bounce).
A simple typo in the address will make a message from a legitimate
sender disappear without notice.

--Per Hedeland
per@hedeland.org

Simon,

It is possible to set up entries in your access database for all those
users that exist on your domain. Since the access database is
processed during SMTP (ie. before procmail or any local mailer gets a
hold of it) any rejection within this database means a bounce back
message will not be generated. Your server will simply send an SMTP
rejection with a reason code.

For example:

**ACCESS DB code**
To:user1@yourdomain.com RELAY
To:user2@yourdomain.com RELAY

To:yourdomain.com error:5.1.1:"550 User unknown"
************************

Don't forget to hash your access file after amending it.

makemap hash /etc/mail/access.db < /etc/mail/access

Cheers
Chirag Gandhi

Per Hedeland wrote:
> In article <jl94h.419$sf2.73@newsfe12.lga> "J.R0wan"
> <allspammerssuck@nomail.com> writes:
>> Simon Gao wrote:
>>> Hi,
>>>
>>> Just wonder how one can set up Sendmail not to send bounce or reject
>>> messages to spam sending machines?
>>>
>>> Simon Gao
>> Depending on the size of your organization you might want to use
>> virtusertable.
>>
>> user1@yourdomain.com user1
>> user2@yourdomain.com user2
>> .
>> .
>> .
>> @yourdomain.com bitbucket
>>
>>
>> then in your /etc/aliases have an entry
>>
>> bitbucket /dev/null
>
> This is of course a very bad solution, for the reasons described in
> the other followup (which has the *correct* solution - i.e. reject the
> message before it gets to the point where you have to send a bounce).
> A simple typo in the address will make a message from a legitimate
> sender disappear without notice.
>
> --Per Hedeland
> per@hedeland.org
I agree that the bitbucket approach is the wrong way of handling email,
that messages can and will be lost if the address is slightly off. My
virtusertable has
@yourdomain.com error:nouser 550 Invalid recipient. Check name and resend.

I then take the /var/log/maillog looking for Invalid recipient flagged
messages, build a MySQL table with the source IP address, bogus email
address, FQDN and timestamp of the message. Where there are repeated
bogus emails from the same IP address I add that IP address to my
IPTables firewall droping any subsequent packets from that address.

I review the entries in the MySQL database sorting on the bogus email
address field looking for potentially valid but mis-typed addresses. I
then correct the firewall. I've seen a 90% drop in emails addressed to
non-existent addresses.

I know some people will not like this solution but it works for me.