[swinog] Metanet Root Server
Hi Is there someone from metanet? Please contact me offlist. Cheers Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Pro / Contra Backup MX?
Heya Swinog We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. Usualy we deny such request, because such a backup MX would bounce all spam which cannot be relayed, and anyway, the sending server usualy queues the email usualy about the same amount of time a backup mx would queue it. So we see not advantage, but a big disatvantage. Now some of our customers complain that 'all other ISP' offers such services. So I wanted to know your opinions: - Why would business customers _need_ their ISP to operate a backup MX for them? - Why can you avoid the disatvantage to generate a shitload of bounces when operating ab backup MX? - Is it true, that most ISP offer this kind of service? Mit freundlichen Grüssen Benoit Panizzon -- I m p r o W a r e A G- __ Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 PrattelnFax +41 61 826 93 02 Schweiz Web http://www.imp.ch __ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Pro / Contra Smarthosting
Heya Another one on about the same topic. Business Customer with own Mailserver. They ofter want to know, which of our mailservers they can use as smarthost. We usualy tell them, that they operate an own fully connected mailserver which does not need any smarthost to deliver email to the world. Some do not agree. The reasons the tell us are: - It Tech XY has told them that sending via a smarthost is much more reliable. - Their previous ISP asked them to use it's smarthost. - Our Server has better 'reputation' than theirs and thus emails are less likely to be considered spam by some spamfilters. - Some seem to see DNS issues which I never could understand (they have correct PTR and MX settings for their mailservers). The problems I see with smarthosting are: - If an email to a recipient does not make it there, we get the blame even on trivias like 'user unknown'. - We have to punch holes in the anti-spam thorttling measures to allow them to send more emails / time than the usual private customer does. - They can generate huge load peaks if they operate newsletters and similar. - They often do relay bounce emails for strange reasons, or cause mail loops which we do not want to be routed via our infrastructure. - The risk that our infrastructure get's blacklisted because of trojan activities on a customers infrastructure increases. So how do other ISP handle such requests? Do customer with an own fully connected mailserver have any reason to use their ISP's email infrastructure as smarthost? Mit freundlichen Grüssen Benoit Panizzon -- I m p r o W a r e A G- __ Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 PrattelnFax +41 61 826 93 02 Schweiz Web http://www.imp.ch __ ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Backup MX?
On Thu, 24 May 2012 16:55:04 +0200 Benoit Panizzon benoit.paniz...@imp.ch wrote: We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. Usualy we deny such request, because such a backup MX would bounce all spam which cannot be relayed, and anyway, the sending server usualy queues the email usualy about the same amount of time a backup mx would queue it. So we see not advantage, but a big disatvantage. The simple advantage is the control. On a backup MX you can enforce your own rules for keeping mail, sending rates, alarming and so on. - Is it true, that most ISP offer this kind of service? An ISP is an ISP - not a mail provider. So why should an pure ISP offer something like a backup MX or a smarthost? But in this world business is not a perfect thing: sometimes you have to offer one service to sell another. But if you don't want to offer such services yourself - be smart and ask another party which has this in their business model included, make a contract and offer it to your customers for a additional fee. So all sides will win. That is the art of making business. So we have no problem to offer a mail service and I'm pretty sure you will find many more here. Regards Oli ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Smarthosting
On Thu, 24 May 2012 17:07:58 +0200 Benoit Panizzon benoit.paniz...@imp.ch wrote: Business Customer with own Mailserver. They ofter want to know, which of our mailservers they can use as smarthost. We usualy tell them, that they operate an own fully connected mailserver which does not need any smarthost to deliver email to the world. Some do not agree. The reasons the tell us are: - It Tech XY has told them that sending via a smarthost is much more reliable. It's a pure thing of implementation which everybody can change to be reliable. - Their previous ISP asked them to use it's smarthost. Traditions are no reason of course - Our Server has better 'reputation' than theirs and thus emails are less likely to be considered spam by some spamfilters. That can matter - blacklisting is not only a technical thing. You know why swinog exists? - Some seem to see DNS issues which I never could understand (they have correct PTR and MX settings for their mailservers). No reason for anything. The problems I see with smarthosting are: - If an email to a recipient does not make it there, we get the blame even on trivias like 'user unknown'. What do you mean with get the blame? - We have to punch holes in the anti-spam thorttling measures to allow them to send more emails / time than the usual private customer does. I don't understand your point: if you don't like the customer: kick him. If you like the customer: sell him something. It's not about deeper technical truths. Many providers which offers services for small companies and private users allow big floods of mails because it doesn't fit in the price calculation. So you should communicate your technical limits in the AGBs and everything is fine. If a customer wants more than that find a partner which does this and make a business of that. Regards Oli ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Backup MX?
On 2012-05-24 16:55 , Benoit Panizzon wrote: Heya Swinog We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. Usualy we deny such request, because such a backup MX would bounce all spam which cannot be relayed, and anyway, the sending server usualy queues the email usualy about the same amount of time a backup mx would queue it. So we see not advantage, but a big disatvantage. You should not configure it as a backup, it should just be a part of the primary, all configured the same, all doing full validation, virus checking etc. You do not have any bounces then as it is fully ready to accept that message, which then can be stored on a backend (disk full is then the only issue you could run into if the storage is a separate thing) This does require that your customers can push their config to you and that your customers reveal their userbase (then again sniff can do so much more) eg, have 3 front-end boxes (which might be loadbalanced) at different network/physical locations: hostA hostB hostC then you configure: $ORIGIN example.com. @ MX10 mx1 MX20 mx2 MX30 mx3 mx1 A h.o.s.tA h::os:tA A h.o.s.tB h::os:tB mx2 A h.o.s.tC h::os:tC A h.o.s.tA h::os:tA mx3 A h.o.s.tB h::os:tB A h.o.s.tC h::os:tC This way, randomly A or B is picked, if they soft-fail (thus not a 500 reject or so), but a connection failure/timeout etc, then most SMTP clients will fail over to the next MX (postfix for instance tries the next address and then all of them) and retry there till they receive a fatal error from the smtp-frontend. The way that the hosts are ordered above gives full chance for things to break into multiple locations without it hurting if one randomly breaks. Btw, dovecot dsync is awesome for these kind of setups ;) Greets, Jeroen ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Smarthosting
On 2012-05-24 17:07 , Benoit Panizzon wrote: Heya Another one on about the same topic. Business Customer with own Mailserver. They ofter want to know, which of our mailservers they can use as smarthost. We usualy tell them, that they operate an own fully connected mailserver which does not need any smarthost to deliver email to the world. Some do not agree. The reasons the tell us are: - It Tech XY has told them that sending via a smarthost is much more reliable. Then you setup a box which acts as that and let them pay for it too ;) After explaining them why it does not matter of course... Smarthosts can be very useful if their mailsystem is located on a unstable DSL link for instance which might have a random IP that belongs to others at times. - Their previous ISP asked them to use it's smarthost. Explain that the previous ISP only wanted their cash and data. - Our Server has better 'reputation' than theirs and thus emails are less likely to be considered spam by some spamfilters. That can be a valid argument, but typically if you share an outgoing system you also might have another customer that is sending spam which gets that outgoing system blocked, thus if it is really valid argument, not sure. - Some seem to see DNS issues which I never could understand (they have correct PTR and MX settings for their mailservers). Some admins are * and do not check/monitor their settings and configuration, bad things happen that way ;) The problems I see with smarthosting are: - If an email to a recipient does not make it there, we get the blame even on trivias like 'user unknown'. - We have to punch holes in the anti-spam thorttling measures to allow them to send more emails / time than the usual private customer does. - They can generate huge load peaks if they operate newsletters and similar. Yep, but they are paying thus these should not be an issue. - They often do relay bounce emails for strange reasons, or cause mail loops which we do not want to be routed via our infrastructure. That is a configuration issue that can be avoided. - The risk that our infrastructure get's blacklisted because of trojan activities on a customers infrastructure increases. You should keep your own infra separate from your customer infra. You could even go as far as giving every user their own Virtual Machine and IP with their own configured mailserver. If you use something ala LXC you could host thousands of these backups on the same gear very cheaply. Of course Xen/KVM/vmware allows you to accomplish the same. The advantage of course of VMs is the ability to move them around to other hardware where needed. So how do other ISP handle such requests? Do customer with an own fully connected mailserver have any reason to use their ISP's email infrastructure as smarthost? Them hosting it on an unstable link with changing IPs might be the only thing... Greets, Jeroen ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Backup MX?
Hello Benoit On 24.05.2012 16:55, Benoit Panizzon wrote: We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. Usualy we deny such request, because such a backup MX would bounce all spam which cannot be relayed, and anyway, the sending server usualy queues the email usualy about the same amount of time a backup mx would queue it. So we see not advantage, but a big disatvantage. I do not speak from an ISP point of view, but I hope that my input may be helpful too. I would only run a backup MX for customers (or anybody else), if the master MX does not reject any e-mails from the backup MX at the SMTP communication level. And it should also be possible for the backup MX to know all valid users which the master MX will accept e-mail for. Postfix does support Recipient address verification [1] (see about 1/3 down the page), even with saving the results locally. An other option is, if the customer is somehow providing regular updates to the list of valid recipients. [1] http://www.postfix.org/ADDRESS_VERIFICATION_README.html bye Fabian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Smarthosting
Hello Benoit On 24.05.2012 17:07, Benoit Panizzon wrote: Some do not agree. The reasons the tell us are: - It Tech XY has told them that sending via a smarthost is much more reliable. And the customer is loosing the possibility to check on his own, if an e-mail has been delivered or is still in the queue. - Our Server has better 'reputation' than theirs and thus emails are less likely to be considered spam by some spamfilters. Then they are sending out e-mails (intentional or not), which helped to give a bad reputation... - Some seem to see DNS issues which I never could understand (they have correct PTR and MX settings for their mailservers). It also helps, if the sending MTA does use the same hostname in the SMTP helo/ehlo, which is configured for the A and PTR DNS record of the sending IP address. bye Fabian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Pro / Contra Backup MX?
Hi Benoit, On Thu, May 24, 2012 at 04:55:04PM +0200, Benoit Panizzon wrote: We have business customers with an own mailservers asking us to provide a backup MX for their mailserver. I'm not working for an ISP but for company helping to implement business customers to set up their own MX. I allways advise my customers *not* to use any external backup MX. As you said, it is not necessary as external mailsystems queue anyway and we set up redundant MTAs. And as most current anti-spam systems depend (not exclusively of course) on the IP address connecting to the system, it is not very helpfull to see your backup MX connecting to you. HTH. Best regards, Matthias ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
