Forcing postfix to check the MX entry
Damien Robinet
Is there a solution to force postfix to check the MX of a domain name ?
I can not prevent users from adding the domain name in the mail system.
We limit the rights, but the solution is not optimal.
For example, if a user adds the domain "mma.fr" in the mail system, it
will receive all emails from users who are sending to MMA.FR.
The problem is that MMA.FR does not point to the mail server and all
messages are "stolen" by the user with a catchall...
If I knew in advance the fields, I would use the file "transport" ...
But it is impossible :(
I would always force Postfix to send its messages to the outside and
never try to deliver locally emails.
So I'm sure the mail arrives at the inputs of the MX domain name and
no message can be "stolen" locally.
Bests Regards,
Damien
Reindl Harald
Am 11.07.2011 12:03, schrieb Damien Robinet:
> Hi All Postfix Users,
>
> Is there a solution to force postfix to check the MX of a domain name ?
it does normally
> I can not prevent users from adding the domain name in the mail system
> We limit the rights, but the solution is not optimal.
why not
> For example, if a user adds the domain "mma.fr" in the mail system, it
> will receive all emails from users who are sending to MMA.FR.
> The problem is that MMA.FR does not point to the mail server and all
> messages are "stolen" by the user with a catchall...
WTF - why can anybody add a domain to your mailserver?
how should any software fix a broken by design policy?
Damien Robinet
We have many agencies that can use our mail server.
Each agency has one or more domain name. They can add their domain in
our system to receive their emails professionals.
We have already limited the users who have the right to the domain
name in the system, but there are always "failures"...
The last example, a external agency computer has added the domain
"paypal.fr" in our system and have creating an e-mail (catchall).
He received all the messages that our employees have sent to paypal.fr ...
We monitor the domaines added to the system. But we can not monitor
employees who have the right to add domain names.
I am looking for a solution in the Postfix configuration to force it
to always send emails to the outside and not try to deliver them
locally.
Regards,
Damien
Mark Goodge
You are trying to solve a social problem by technical means, which is
rarely effective. In this particular case, you have someone - either an
employee of your company, or a client - who has just committed a very
serious crime using your equipment. That's a matter for the police, not
Postfix.
If you really cannot technically prevent people adding domains that they
do not control, then you need to make it clear in your contracts - both
with your employees and your clients - that doing so is grounds for
instant termination. Otherwise, you are likely to find that you, too,
will be in trouble with the law.
On a more sensible note, the simplest technical solution is to have
separate mail servers for inbound and outbound mail. That way, someone
adding a domain they don't own to the inbound server won't have any
effect on outbound mail.
Mark
--
Sent from my Babbage Difference Engine
http://mark.goodge.co.uk
http://www.ratemyairport.com
Wietse Venema
> For example, if a user adds the domain "mma.fr" in the mail system, it
> will receive all emails from users who are sending to MMA.FR.
> The problem is that MMA.FR does not point to the mail server and all
> messages are "stolen" by the user with a catchall...
Postfix works as designed. The error is that you allow
users to configure arbitrary domains into Postfix.
Wietse
Benny Pedersen
> Is there a solution to force postfix to check the MX of a domain name
> ?
why ?, an a record is fine with me?
> I can not prevent users from adding the domain name in the mail
> system.
> We limit the rights, but the solution is not optimal.
when some fools add domains, ask postm...@example.org or there so new
domain if thay need you to be mx for there domain, do this before
activate mx hosting, did thay even paid you ?
> For example, if a user adds the domain "mma.fr" in the mail system,
> it
> will receive all emails from users who are sending to MMA.FR.
> The problem is that MMA.FR does not point to the mail server and all
> messages are "stolen" by the user with a catchall...
this is not a postfix problem, but a user auth problem your site makes,
its fine to add domains, but plese verify with a email to
hostm...@example.com before its gone in air, most often you will see
problem is gone in postfix that way
> If I knew in advance the fields, I would use the file "transport" ...
> But it is impossible :(
this is a fix for something that is out of your control
> I would always force Postfix to send its messages to the outside and
> never try to deliver locally emails.
> So I'm sure the mail arrives at the inputs of the MX domain name and
> no message can be "stolen" locally.
exactly ask domain owner first
Бак Микаел
> Hi Harald,
>
> We have many agencies that can use our mail server.
> Each agency has one or more domain name. They can add their domain in
> our system to receive their emails professionals.
>
> We have already limited the users who have the right to the domain
> name in the system, but there are always "failures"...
> The last example, a external agency computer has added the domain
> "paypal.fr" in our system and have creating an e-mail (catchall).
> He received all the messages that our employees have sent to paypal.fr ...
>
> We monitor the domaines added to the system. But we can not monitor
> employees who have the right to add domain names.
> I am looking for a solution in the Postfix configuration to force it
> to always send emails to the outside and not try to deliver them
> locally.
>
Easy!
Fix the software that your trusted users use to add their domain. Make
THAT software check that the domain's MX record points to the right
place BEFORE you actually add it to the database.
Problem solved.
M.
Mark Goodge
>
> Easy!
> Fix the software that your trusted users use to add their domain. Make
> THAT software check that the domain's MX record points to the right
> place BEFORE you actually add it to the database.
That's not actually helpful, because if you want to avoid any
interruption to mail delivery you have to add the domain to the new
destination server before you alter the MX to point it there.
Benny Pedersen
>> Easy!
>> Fix the software that your trusted users use to add their domain.
>> Make
>> THAT software check that the domain's MX record points to the right
>> place BEFORE you actually add it to the database.
>
> That's not actually helpful, because if you want to avoid any
> interruption to mail delivery you have to add the domain to the new
> destination server before you alter the MX to point it there.
this is why its important to ask domain owner first
Reindl Harald
Am 11.07.2011 16:12, schrieb Mark Goodge:
> On 11/07/2011 15:02, Бак Микаел wrote:
>>
>> Easy!
>> Fix the software that your trusted users use to add their domain. Make
>> THAT software check that the domain's MX record points to the right
>> place BEFORE you actually add it to the database.
>
> That's not actually helpful, because if you want to avoid any interruption to mail
> delivery you have to add the domain to the new destination server before you alter
> the MX to point it there
for NEW domains this is no problem and for existing domains
it MUST NOT happen that some idiot can add any domain to
a mail-system
what here happens is a backend which allows everything and
normally if this is production you have to shut down
your services because they are not permitted per law
a server software cann never prevent from dumb systems
configured without thinking a single second what it
means if users can add any domain
Wietse Venema
> On 11/07/2011 15:02, ??? ?????? wrote:
> >
> > Easy!
> > Fix the software that your trusted users use to add their domain. Make
> > THAT software check that the domain's MX record points to the right
> > place BEFORE you actually add it to the database.
>
> That's not actually helpful, because if you want to avoid any
> interruption to mail delivery you have to add the domain to the new
It might work, if the system has an out-of-band "approval" procedure
for domains that trigger exceptions (e.g., domain does not (yet)
exist, domain MX does not point to our server, etc.).
Such exceptions could be reviewed by a trusted human, and once
verified to be OK, they could go through.
I think that all domain modifications should be approved by a
trusted human, but then I'm not paying for all this stuff.
Wietse
Rainer Frey
On 11.07.2011, at 12:40, Damien Robinet wrote:
This issue is not to be solved in postfix, but in any kind of front-end
(organizational first, then maybe technical).
> We have many agencies that can use our mail server.
> Each agency has one or more domain name. They can add their domain in
^^^^^^^^^^^^
As Wietse hinted, this is the key to the problem. They can not only add /their/
domains, but /any arbitrary/ domain as well.
Some ideas to solve that:
* remove the possibility for customers to add domains, and let them request
domains through your support / customer care department
* in their (assumedly web) frontend, give customers the ability to register
domains with their account. Validate domain registrations before you activate
them. Allow them to add only activated domains that are linked to their account
* (give each customer a separate postfix instance so that any change affects only
themselves)
Rainer
Mark Goodge
>
>
> Am 11.07.2011 16:12, schrieb Mark Goodge:
>> On 11/07/2011 15:02, Бак Микаел wrote:
>>>
>>> Easy!
>>> Fix the software that your trusted users use to add their domain. Make
>>> THAT software check that the domain's MX record points to the right
>>> place BEFORE you actually add it to the database.
>>
>> That's not actually helpful, because if you want to avoid any interruption to mail
>> delivery you have to add the domain to the new destination server before you alter
>
> for NEW domains this is no problem and for existing domains
> it MUST NOT happen that some idiot can add any domain to
> a mail-system
Well, it's generally OK to add any domains to a recipient mail server,
provided there is no prospect of mail ever actually reaching that server
other than by MX. That is, inbound mail is hosted on a box which is
never used for outbound mail. So long as that's the case, it doesn't
matter if arbitrary domains are added to the system as there will never
be any mail reaching those domains on that server. That's not an
uncommon situation with many hosting suppliers, where you can add a
domain to the hosting system without any prior checks and then re-point
your MX there afterwards. I've just checked, and it's possible on my
main external host, even though I don't actually use it for mail. Heck,
it's even possible to fool Google Apps into accepting mail for some
domains that you don't control - but, of course, Google takes care to
ensure that it never breaks anything for anyone else if you do.
Speaking with my corporate network administrator hat on, I would
absolutely expect to be able to do this if I was considering using some
third-party mail service. That is, I will want to see my domains added
to the supplier's system and correctly handling inbound mail (tested by
means of telnet to port 25 and manually injecting a sample mail) before
I will update the MX records and allow mail to flow normally through the
server. A mail hosting supplier who won't permit that won't get my business.
If you're running a mail service for other people, then you have to
accept that you will, on occasions, find your servers configured to
accept mail that they aren't an MX destination for - not just in the
course of new domains transitioning in, but also because existing
domains will be transitioned away and people will forget to remove them
from the configs. So the solution is not to try prevent that happening
(because you can't), it's to ensure that it doesn't matter if it does.
(Obviously, from an administrative perspective, you want to minimise the
number of domains on your system that you're not actually the MX
destination for, and there are several good ways of going about that.
But minimising isn't the same as preventing, so you can't design a
system around the assumption that you will only ever be configured to
accept mail for which you are the MX destination).
The problem described by the OP is caused by a situation where non-MX
mail (eg, outbound mail from his organisation) shares a server which
handles mail for arbitrary domains added by end-users. That will result
in the outcome he described, where outbound mail is (correctly) routed
by the domain entry to the destination mailbox or forwarding address on
the server. Apart from causing that particular problem, though, that's
also bad because it breaks one of the fundamental rules of service
provision: Keep your customers' data entirely separate to your own. And,
as plenty of people have said in the course of this thread, the solution
isn't to try and make Postfix deal with it, the solution is to use
Postfix as part of a properly designed mail architecture.
Mark
--
Sent from my Babbage Difference Engine
http://mark.goodge.co.uk
Per Jessen
> I am looking for a solution in the Postfix configuration to force it
> to always send emails to the outside and not try to deliver them
> locally.
We have such a setup, but afaik, it's only possible by using two postfix
instances. We have an "inbound" and an "outbound" instance.
/Per Jessen, Zürich
Бак Микаел
> On 11/07/2011 15:02, Бак Микаел wrote:
>>
>> Easy!
>> Fix the software that your trusted users use to add their domain. Make
>> THAT software check that the domain's MX record points to the right
>> place BEFORE you actually add it to the database.
>
> That's not actually helpful, because if you want to avoid any
> interruption to mail delivery you have to add the domain to the new
>
Yep, that's right. Didn't think of existing domains with mail traffic
getting transferred to his server.
Nevermind. This is not a postfix problem anyway.
M.