Giganews Newsgroups

Rejecting messages that purport to come from recipient

This is a discussion on Rejecting messages that purport to come from recipient within the mailing.postfix.users forums, part of the Mail Servers and Related category; Does anyone know of a method whereby we can reject messages that are being relayed that are supposedly coming from ...


Go Back   Usenet Forums > Mail Servers and Related > mailing.postfix.users

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 12-19-2006
Trix
 
Posts: n/a
Default Rejecting messages that purport to come from recipient

Does anyone know of a method whereby we can reject messages that are
being relayed that are supposedly coming from the recipient? Eg: sender
= user@domain.com; recipient = user@domain.com. Any such restriction
would come after permit_mynetworks, since of course we don't mind if
people send to themselves internally.

I was thinking of header checks, but since they're evaluated
line-by-line, perhaps it's not possible. And if we can, I wouldn't have
the faintest clue where to start. Does anyone have any ideas?

Reply With Quote
  #2 (permalink)  
Old 12-19-2006
Mark-Tim Junghanns
 
Posts: n/a
Default Re: Rejecting messages that purport to come from recipient


"Trix" <trixtah@gmail.com> schrieb im Newsbeitrag
news:1166518121.110983.54000@80g2000cwy.googlegrou ps.com...
> Does anyone know of a method whereby we can reject messages that are
> being relayed that are supposedly coming from the recipient? Eg: sender
> = user@domain.com; recipient = user@domain.com. Any such restriction
> would come after permit_mynetworks, since of course we don't mind if
> people send to themselves internally.


We have a pop-before-smtp mechanism and SMTP-Auth in place. These two
instances are working perfectly. The pop-before-smtp mechanism is based on a
database, which is keeping a list of all clients that have successfully been
authenticated against the pop3/imap daemon. Once a client is trying to use
SMTP, the postfix daemon will first check the permit_mynetworks entry in its
config file. Then it will go through the pop-before-smtp database and look
whether the SMTP-client has already been authenticated. If so, the
SMTP-client will be granted permission to send.

If there are any clients that are generally trusted and that need the
ability to send (such as automated scripts on webservers to send forms or
stuff like that), you can just bypass pop-before-smtp by adding these hosts
to your permit_mynetworks line.

>
> I was thinking of header checks, but since they're evaluated
> line-by-line, perhaps it's not possible. And if we can, I wouldn't have
> the faintest clue where to start. Does anyone have any ideas?
>


If you play around with above setup, you may find, that the pop-before-smtp
or a SMTP-Auth installation will solve your
"sender-is-receiver-on-my-box-spam" as well, since it does not care about
where is the sending domain hosted, but it will grant access based on
authorization.


Reply With Quote
  #3 (permalink)  
Old 12-19-2006
Trix
 
Posts: n/a
Default Re: Rejecting messages that purport to come from recipient

On Dec 19, 10:49 pm, "Mark-Tim Junghanns" <m...@markjunghanns.de>
wrote:
> "Trix" <trix...@gmail.com> schrieb im Newsbeitragnews:1166518121.110983.54000@80g2000cwy .googlegroups.com...
>
> > Does anyone know of a method whereby we can reject messages that are
> > being relayed that are supposedly coming from the recipient?

> We have a pop-before-smtp mechanism and SMTP-Auth in place. These two
> instances are working perfectly.


Thanks very much for the suggestions. Unfortunately, neither of those
are useful for our requirements, since I neglected to mention the fact
that the Postfix servers are internet-facing gateway MTAs for our
organisation. They don't hold any mailboxes, and users don't connect to
them.

What I've decided to do is put in an smtpd_sender_restriction (after
permit_mynetworks and permit_sasl_authenticated, since we do have that
for "private" networks in our organisation), and use that to
reject_unlisted_sender for *all* senders purporting to be from our
domain.

Reply With Quote
  #4 (permalink)  
Old 12-19-2006
Greg Hackney
 
Posts: n/a
Default Re: Rejecting messages that purport to come from recipient

Trix wrote:
> Does anyone know of a method whereby we can reject messages that are
> being relayed that are supposedly coming from the recipient? Eg: sender
> = user@domain.com; recipient = user@domain.com. Any such restriction
> would come after permit_mynetworks, since of course we don't mind if
> people send to themselves internally.
>
> I was thinking of header checks, but since they're evaluated
> line-by-line, perhaps it's not possible. And if we can, I wouldn't have
> the faintest clue where to start. Does anyone have any ideas?


I think you are talking about rejecting email from the Internet
where the FROM address is forged, pretending to be a valid local user?

If so:

List all your domain names in a file called /etc/postfix/rejectmydomains:
domain1.com REJECT
domain2.com REJECT

Configure smtpd_sender_restrictions to be something like this:

smtpd_sender_restrictions = reject_non_fqdn_sender,
check_sender_access proxy:hash:/etc/postfix/senders,
reject_non_fqdn_sender,
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access proxy:hash:/etc/postfix/rejectmydomains,
reject_unknown_sender_domain,
permit

This will reject email that uses your domain names in the sender address,
unless they match permit_mynetworks or permit_sasl_authenticated. Additionally,
the /etc/postfix/senders file can be used for exclusions. Or you can insert a
smtpd_client_restrictions map ahead of rejectmydomains, and allow exclusions
based on IP addresses.

--
Greg



Reply With Quote
  #5 (permalink)  
Old 12-20-2006
Trix
 
Posts: n/a
Default Re: Rejecting messages that purport to come from recipient


Greg Hackney wrote:

> I think you are talking about rejecting email from the Internet
> where the FROM address is forged, pretending to be a valid local user?
>


Thanks Greg, that's exactly right. What you provided is a slightly
simpler mechanism to what I dreamed up, and it works perfectly. :-)

Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 02:11 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0