> > It's doing what you're asking... "REJECT"
> > means bounce the message. You
> > probably want to "DISCARD" it.
> > 
> DISCARD means nobody will receive the bounce message, right? If any
> bodies mails is rejected from our server he/she will never know what
> was the issue. 

Right, which is why you should be very careful about where you apply
that rule. Specifically here you are making a policy to the effect of,
"If mail claiming to to be from one of our users did, in fact, arrive
from a foreign server then we do not want to send a bounce message."
That is the rule you are asking how to enforce. Now that you know what
it means you can make a decision about whether to do it.

> > There *MAY BE* legitimate reasons for for mail to come into
> > your network
> > from a server outsite the network addressed to one of your
> > users and
> > purporting to be from that user. For example, test messages
> > from remote
> > workers sending through their home ISP. Just so that you
> > are aware of
> > the other side of the issue.
> > 
> It means that we can not do any thing for that kind of mails at the
> Postfix level. We have to receive those *SPAM* Mails in which from
> and to address are same or spams coming from our one of the email
> addresses to any users, right? If these types of mails can be
> rejected by the Postfix then please let me know how or any pointer
> any docs will be very useful to me.

http://www.postfix.org/access.5.html

The key is *where* you place the DISCARD action...

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_unauth_destination
 YOUR CHECKS HERE

You've already permitted mail originating from your domain, so if you
discard mail with addresses from your domain in your checks it only
affects people claiming to be your users originating mail outside your
network. That can include remote workers relaying through their home
ISP's network.

If, however, you make a policy that your users are not to originate mail
"from" their accounts outside of your network then you are not dropping
any legitimate mail. The wisdom of the policy is outside the scope of
the list, but there's no shortage of people who will either tell you
"Don't do it," or "Fine, but you need to provide a way (auth) for users
to follow the policy."

Chris Babcock

Attachment: signature.asc
Description: PGP signature

Reply via email to