Jakub Nadolny | 5 Dec 11:35

Restrict senders for particular e-mail address

Hi,

I have some collective e-mail aliases like:
all-people-in-company <at> company-domain.pl

I need to limit senders to this address to few authorised people only. So, in
other words: 

What is the best way to allow users: some.name1 <at> company-domain.pl,
some.name2 <at> company-domain.pl send e-mails to
all-people-in-company <at> company-domain.pl, while all other users will not be
allowed to do it?

I was trying to achieve it by header_checks, but I could not find if there is
any way to do something like:

if /^To: .*all-people-in-company <at> company-domain.pl/ 
 if /^From: .*some.name1 <at> company-domain.pl/ or /^From: .*some.name2 <at> company-domain.pl/ OK
 else REJECT You are not authorised to send e-mail to this address.
endif

(I know this is not proper construction in header_checks but it should show my
intention).

How can I do it?

Thank you in advance,
Jakub

(Continue reading)

mouss | 5 Dec 08:42
Favicon

Re: Spam Help Forged headers

Chris Funk a écrit :
> 
> How would I  
> 
> <<Place the check after permitting your networks, SASL auth'd clients, and
> reject_unauth_destination.
> 
> Will the smtpd_*_restrictions  work on headers?
> 

no.

Re: Testing SASL HOWTO using telnet/Postfix/dovecot?

Magnus Bäck wrote:
> On Wednesday, December 03, 2008 at 23:06 CET,
>      "Roderick A. Anderson" <raanders <at> cyber-office.net> wrote:
> 
>> Magnus Bäck wrote:
> 
> [...]
> 
>>> You can choose any username you like as long as it matches whatever
>>> is in your credential database. So far we don't know anything about
>>> that. MySQL, sasldb, LDAP, what?
>> smtpd_sasl_type = dovecot
> 
> Yes, but how does Dovecot store the credentials? But never mind, let's
> see some logs from the failed authentication attempt.

Thanks for the help.  I'm going to have to back-burner this for a bit.
Until I get the server set up the way it should be instead of my kludged
setup.

Rod
> 
>>> Why do you insist on testing this with telnet? You will introduce
>>> another possible error source (incorrect encoding of the credentials)
>>> and it's a use case that you're supposedly not really interested in.
>> Because I can do it one step at a time and see the results that
>> Postfix sends back.  I hadn't thought of telnet possibly munging
>> base64 encoded values.  They looked like ASCII-only to me.
> 
> Telnet won't munge your encoded credentials (they are indeed pure ASCII),
(Continue reading)

Duane Hill | 4 Dec 21:49

Re: Sender = Receiver?

On Thu, 4 Dec 2008, Sturgis, Grant wrote:

> On Thu, 2008-12-04 at 12:05 -0700, Christian Desrochers wrote:
>> Hi,
>>
>> Thanks for you reply. Where can I read the archives, please?
>>
>> Christian
>
> Have you tried Google?

postfix.org is a good place too. You don't even need to search for them. 
http://www.postfix.org/lists.html shows these list archives:

    http://archives.neohapsis.com/archives/postfix/
    http://news.gmane.org/index.php?prefix=gmane.mail.postfix
    http://groups.yahoo.com/group/postfix-users/
    http://groups.google.com/group/list.postfix.users
    http://marc.theaimsgroup.com/?l=postfix-users
    http://archive.netbsd.se/

mouss | 4 Dec 16:22
Favicon

Re: Visibility of Postfix docs,

M. Fioretti a écrit :
> [snip] On one hand, I know enough these days to
> (almost) never create personally the problem we're talking about. On
> the other hand, I am not skilled enough to compile such a list,
> certainly not as much as Wietse or others here who probably already
> have such a list in their mind and/or could write it down in very
> little time.
> 
> If I don't create the problem and don't know enough to *implement* the
> solution myself and both of these things were already said, why should
> you think that *I* could be the one able to *implement* it myself,
> only because I'm the one who *suggested* it (***)?
> 

don't take it personally. it's a common reply that generally means
"sure, but it requires volunteers".

> It's like if a child saw a big rock blocking the street and,
> suggesting to a passing-by body builder that he may easily remove it,
> were told by a third person "why don't you move it yourself?"
> 
> (***) again, please note that mine was and remains a *suggestion*, I'm
> not demanding that anybody does this now or anything like that.
> 
> Never mind, really, let's move on.
> 
> Marco

yes, it's a good suggestion. unfortunately, writing such list requires
work. otherwise, the list quality would be bad, and thus worst than not
(Continue reading)

Noel Jones | 4 Dec 16:19

Re: Visibility of Postfix docs,

M. Fioretti wrote:
> On Thu, Dec 04, 2008 08:42:34 AM -0500, Charles Marcus wrote:
>> On 12/4/2008, M. Fioretti (mfioretti <at> nexaima.net) wrote:
>>> It would be a very useful service to the community if you or any other
>>> of the real gurus could compile a short list, say one or two pages at
>>> postfix.org, of which howtos are wrong, where and above all why. It
>>> may save further question and confusion in the future.
>> You're not serious?
> 
> Of course. Why not? What's wrong with the idea?
> 
>> That said, I am sure that the website maintainer would be happy to post
>> such a list if you were to provide it...
> 

There is already a list of known useful how-tos at 
http://www.postfix.org/docs.html
Updates for that page are welcome.

I think it's unlikely there will ever be a list on postfix.org 
of "how-tos to avoid".

I think this has gone far enough, over and out.

--

-- 
Noel Jones

Favicon

Re: Domain emails from outside

Gabriel Hahmann wrote:
> Hi all,
>
> I'm new to the list and have a problem with my mail system. Recently
> I'm receiving a lot of spam emails coming from the internet but the
> sender is a user from my domain. Then I tried the same thing directly
> from other system, as described below:
>

The answer to your question is as such.
Add 'check_sender_access pcre:/path/to/config/restrict_internal_domain'
to the end of smtpd_sender_restrictions
(You may use regexp instead of pcre if your postfix does not support it,
use 'postconf -m' to check)

/path/to/config/restrict_internal_domain:
/.*\.example.com/    REJECT external email with an internal sender address

> My configuration is listed below, i just changed the name of the
> domain with testdomain.com <http://testdomain.com> and another domain
> that this machine receive mail with anotherdomain.com
> <http://anotherdomain.com>:
>
We recommend 'postconf -n' to make sure you did not make a typo.
Also, please use example.(com|net|org) instead of making up domain names.
> maximal_queue_lifetime = 4h
This is amazingly short.  I hope you, or the recipient, never have any
network issues.

> virtual_maps = hash:/etc/postfix/virtualusertable
(Continue reading)

Sahil Tandon | 4 Dec 16:15

Re: Domain emails from outside

Gabriel Hahmann <gabriel.hahmann <at> gmail.com> wrote:

> I'm new to the list and have a problem with my mail system. Recently I'm
> receiving a lot of spam emails coming from the internet but the sender is a
> user from my domain. Then I tried the same thing directly from other system,
> as described below:
> 
> telnet mailsystemwithproblem 25
> helo testdomain
> MAIL FROM: <bob <at> testdomain.com>
> RCPT TO: <ann <at> testdomain.com>
> DATA
> test
> .
> 
> I've done this with success, and the machine that i've used to telnet is not
> in the mynetworks or other parameter.

This makes sense; MXs outside your networks should be able to send mail
to your domains.

> The problem is that all my users are receiving spam from themselfs. My
> server is not an open relay because from outside I can't send email to other
> domains, but if somebody connects and send to my own domain it works like I
> said before.

/etc/postfix/main.cf:
smtpd_recipient_restrictions =
	...
	reject_unauth_destination
(Continue reading)

Anant Athavale | 4 Dec 13:19

Re: queue refresh time regarding.

Dear Wietse,

Thanks for the inputs.  Will adhere to your suggestions.

Regards,
ANANT.

Quoting Wietse Venema <wietse <at> porcupine.org>:

> Anant Athavale:
>> Dear List,
>>
>> I have a basic question.  Which is parameter I need to use to change
>> in order to change the mailq refresh time.
>>
>> I have the following problem.
>>
>> Many of my users have their quota filled up and we have set maximum
>> queue lifetime to default 5d.  When postfix refreshes its mailq
>> (equivalent of sendmail -q) all pending mails to due to overquota
>> become active and due to this, access to mails through front end is
>> becoming slow (Load on server).
>>
>> I don't want postfix to run sendmail -q equivalent on its own.  I will
>> run sendmail -q through crontab at specific intervals (if it is OK).
>
> No, you must let Postfix work the queue.  "sendmail -q" attempts
> to deliver all mail at the same time which is bad for performance.
>
> If you let Postfix work the queue it spreads out deliveries over time.
(Continue reading)

Re: Avoiding (trivial) spoofed "mail from"

mouss escribió:
> Roman Medina-Heigl Hernandez a écrit :
>>> Why is the mail not being rejected due to
>>> reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I
>>>  couldn't find it...  :-(
>> I got to solve it by:
>> smtpd_sender_login_maps = $virtual_mailbox_maps
>>
> 
> do not reuse maps this way. use a script to generate each map instead
> (or use
> 
> note that smtpd_sender_login_maps returns one or more logins, while
> virtual_mailbox_maps returns the path to the mailbox.

Since I'm using Cyrus LMTP, I don't have the "path to mailbox" variable, so
I could return whatever in $virtual_mailbox_maps. What I did was to return
the email address (which in turn corresponds to the SASL login).

So now it's perfectly "compatible" to use the same Mysql map for both
variables. I mean:

hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql
# Virtual users (Mysql)
hosts           = unix:/var/run/mysqld/mysqld.sock
user            = postfix
password        = xxxxxxxxxx
dbname          = postfix
query           = select user from user where user = '%s'

(Continue reading)

Wietse Venema | 4 Dec 02:25

Re: Chrooting smtp (non-d) client activity for resolv.conf segregation

brian dodds:
[ Charset ISO-8859-1 unsupported, converting... ]
> So I've done a bit of reading on postfix's internal chrooting
> capabilities and I thought it would fit exactly what I'm trying to do
> perfectly.  Here is the simple desired functionality:
> 
> .  I want outbound email name lookups to use a different set of name
> servers than what the system normally uses in literal /etc/resolv.conf
> 
> To accomplish this, I set the smtp service to chroot in master.cf and
> I moved the resolv libraries into /var/spool/postfix/lib and created a
> /var/spool/postfix/etc/resolv.conf with the nameservers i wanted to
> use.  I'm running Postfix 2.3.3 on CentOS 5.2 (2.6.24) with SELinux.
> I added the chroot capability for the smtp binary to my SELinux
> policy.  Postfix starts uneventfully, save for the warning about
> mismatched resolv.conf files, which is what I expect (in fact, is what
> I want).  This is what I'm now seeing when I send mail:
> 
> .  smtpd runs, accepts the mail (opens literal /etc/resolv.conf vs.
> chroot /etc/resolv.conf and reads that)
> .  proxymap runs next, opens literal /etc/resolv.conf
> .  trivial-rewrite comes next, same resolv.conf
> .  cleanup runs, same resolv.conf
> .  smtp runs, establishes environment, opens literal /etc/resolv.conf
> - not chroot /etc/resolv.conf, reads contents, *then chroots*, then
> performs DNS lookups using the wrong DNS servers
> 
> Why does the chroot happen after the name resolution environment is
> established?  Wouldn't that mean that having the /etc/resolv.conf in
> the chroot is unnecessary? And more importantly, how can I get smtp
(Continue reading)


Gmane