Rank newbie, patience, please

Long post, reveals my lack of understanding. Moved from FC6 to Ubuntu 3
weeks ago. Never got sendmail to play nice, tried postfix, it's running. I
use both a client, and access .db. In access, one may discard, but not in
client. Spammers love to send to azpry4df@mydomain.com. No such user,
bounces, but the bounce goes to some poor soul who has never emailed in
here. I think this has been termed "backscatter", right? I get 4,5 a week,
from places I have never sent email. I discard mail to unknown users,
rather than bounce it. But, what about the client .db?
I love using zen.spamhaus.org, but, doesn't it 550 the rejects? I don't
know with certainty where these are going, or if the spam is being
propagated using ME as a party to it. Some explanation would be
appreciated.

ray wrote:
> Long post, reveals my lack of understanding. Moved from FC6 to Ubuntu 3
> weeks ago. Never got sendmail to play nice, tried postfix, it's running. I
> use both a client, and access .db. In access, one may discard, but not in
> client. Spammers love to send to azpry4df@mydomain.com. No such user,
> bounces, but the bounce goes to some poor soul who has never emailed in
> here. I think this has been termed "backscatter", right? I get 4,5 a week,
> from places I have never sent email. I discard mail to unknown users,
> rather than bounce it. But, what about the client .db?
> I love using zen.spamhaus.org, but, doesn't it 550 the rejects? I don't
> know with certainty where these are going, or if the spam is being
> propagated using ME as a party to it. Some explanation would be
> appreciated.
>
Set up an SPF record if your ISP will allow it. That tells the rejecting
domain whether the sender was forged. If it was, the rejecting domain
knows not to bother sending the reject message. See:

http://www.kitterman.com/spf/validate.html

for a description of SPF records and testing/configuration tools.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Thank you sir, they won't, policy: NO SERVERS. I am a bit in violation of
the TOS, but, I pay my bill, and if I get run off, there's always other
providers, right?

Just this morning, I have rejected a place called tiscali.it. He hit me 31
times, each time drawing a 550, wasn't he using me to send spam to
some innocent soul? Discarding these violates the RFC, I know, but
I would do that if I could.


On Tue, 18 Sep 2007 12:31:52 +0100, Martin Gregorie wrote:

> ray wrote:
>> Long post, reveals my lack of understanding. Moved from FC6 to Ubuntu 3
>> weeks ago. Never got sendmail to play nice, tried postfix, it's running. I
>> use both a client, and access .db. In access, one may discard, but not in
>> client. Spammers love to send to azpry4df@mydomain.com. No such user,
>> bounces, but the bounce goes to some poor soul who has never emailed in
>> here. I think this has been termed "backscatter", right? I get 4,5 a week,
>> from places I have never sent email. I discard mail to unknown users,
>> rather than bounce it. But, what about the client .db?
>> I love using zen.spamhaus.org, but, doesn't it 550 the rejects? I don't
>> know with certainty where these are going, or if the spam is being
>> propagated using ME as a party to it. Some explanation would be
>> appreciated.
> >
> Set up an SPF record if your ISP will allow it. That tells the rejecting
> domain whether the sender was forged. If it was, the rejecting domain
> knows not to bother sending the reject message. See:
>
> http://www.kitterman.com/spf/validate.html
>
> for a description of SPF records and testing/configuration tools.
>
>

In article <gvqdnedd5aWwHnLbnZ2dnUVZ_sCtnZ2d@comcast.com>, ray wrote:
> use both a client, and access .db. In access, one may discard, but not in
> client. Spammers love to send to azpry4df@mydomain.com. No such user,

In /etc/postfix/main.cf:

smtpd_recipient_restrictions =
...
check_recipient_access hash:/etc/postfix/recipients
...


In /etc/postfix/recipients:

azpry4df@mydomain.com REJECT Bogus address, backscatter, go away!


postmap hash:recipients


> bounces, but the bounce goes to some poor soul who has never emailed in
> here. I think this has been termed "backscatter", right? I get 4,5 a week,
> from places I have never sent email. I discard mail to unknown users,
> rather than bounce it. But, what about the client .db?
> I love using zen.spamhaus.org, but, doesn't it 550 the rejects? I don't

It does what you tell it to do. By default, it rejects it with a 554,
but you can put that in main.cf just for documentation.


smtpd_recipient_restrictions =
...
reject_rbl_client zen.spamhaus.org
...


maps_rbl_reject_code = 554


> know with certainty where these are going, or if the spam is being
> propagated using ME as a party to it. Some explanation would be
> appreciated.

You could put the "reject_rbl_client" in smtpd_client_restrictions.
If you did that, you would never find out (in your log) who the
spammer was trying to send to, and you would reject messages to
postmaster from listed clients, violating RFC2142.
You would also generate queries to Spamhaus for transactions that
might have been blocked by "check_recipient_access" without
generating network traffic. Every DNS query Postfix generates
causes a system call and a context switch. If you are not running
a names cache (aka DNS forwarder aka local name server) on the
same machine, it takes a trip through the network card driver.
So unless you have many thousands of items in your hash tables,
or hundreds of regular expressions in your PCRE or POSIX Regexp tables,
you should put your Postfix internal checks ahead of any DNSBL checks.

The names "smtpd_client_restrictions" and "smtpd_recipient_restrictions"
may give you the wrong idea. They are about when in the transaction
each restriction happens. Not about what the restrictions under
them do.
You can block certain clients in smtpd_recipient_restrictions.
You can't block messages to certain recipients in
smtpd_client_restrictions, because that early in the SMTP dialog
you don't know who the recipients are yet.


BTW, you will get more help if you compose a very specific
subject line. Most people who go to the trouble of answering questions
here are doing it for the benefit of the people who will be looking
for the same answer next month or next year. (It's really not worth
the effort to answer each newbie question one by one; it only becomes
worthwhile if we are answering it "once and for all.") Those people,
we hope, will look in the newsgroup archive before asking a question which
might have been answered recently. They will most likely find the
previous answer if your subject line was really good. This is a
cooperative venture. Your contribution is to write the very best
description ever seen of what your problem is. Tell us where
you looked for the answer before you came here. Tell us exactly
what you tried. Quote the relevant parts of your config files.
Quote whatever error messages you got. Chances are the
authors of any documentation will not believe it was inadequate,
but if enough people hit the same roadblock they might actually
improve it. And in the mean time, your question and my answer
add to the supplementary documentation. If this is a new concept
to you, please read Eric Raymond's essay (google for it)
"How to Ask Questions the Smart Way."


Cameron

ray wrote:
> Thank you sir, they won't, policy: NO SERVERS. I am a bit in violation of
> the TOS, but, I pay my bill, and if I get run off, there's always other
> providers, right?
>
SPF doesn't need another server. Its just an additional record in the
DNS server that defines your domain name (which might be a subdomain
within your ISP's domain).

As for the TOS - there are ways of running Postfix so that your ISP will
never know that its there:

- use fetchmail to retrieve your mail from your mailbox at the ISP via
POP3 and pass it to Postfix. This has the additional benefit of not
requiring a hole in your firewall for incoming SMTP connections.

- Postfix uses SMTP to send outgoing mail. That isn't easily
distinguishable from a mail client using SMTP for the same purpose
provided that Postfix defines "relayhost" to send outgoing mail via
the ISP's mail server.

FWIW I use a pipeline:

fetchmail | spamc | sendmail

so all mail has already been scanned by Spamassassin before it is
forwarded to Postfix by the Postfix sendmail utility. I'm happy that
Spamassassin isn't generating false positives, so it the next week or
two I'll write and install a spam trap so that messages tagged as spam
by Spamassassin are silently discarded before they get to Postfix:

fetchmail | spamc | spamtrap | sendmail

and I'll do it in such a way that fetchmail thinks the spam has been
delivered.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |