On 12 Jun 2011, at 11:23, Wiebe Cazemier wrote: > ----- Original Message ----- >> From: "Reindl Harald" <h.rei...@thelounge.net> >> To: postfix-users@postfix.org >> Sent: Sunday, 12 June, 2011 10:04:02 AM >> Subject: Re: unverified_recipient_tempfail_action = permit >> >> >> >> Am 12.06.2011 09:06, schrieb Wiebe Cazemier: >>>> so you do not need any backup-MX because if your primary >>>> is not available the deferring happens on the sender >>>> >>>> this is the way smtp works >>> >>> Default defer time for most SMTP servers is only 3 to 5 days, that >>> is not long enough for me. >> >> jokingly if you are longer than 3 times down with your primary MX >> you should consider outsourving you mailservices! > > Well, I also have some private servers and if I'm on vacation, I have a hard > time fixing broken hardware. At this time, I have no cloud platform or other > redundant platform in place. > > Plus, people sending me mail will get a defer notice. I'd rather prevent that. > >> >> really - in the last ten years our longest outage of the mailserver >> was 10 hours bcause a hardware-failure, so why does it bother >> me how long is the defer time out there and if our server si longer >> than 5 days down my smallest problem are a hand of mails bouncing >> back to the sender >> >>>>> So if you would accept mail when the primary is down, you may >>>>> very >>>>> briefly >>>>> create backscatter, but it allows you to operate a backup MX >>>>> server >>>>> without >>>>> syncing recipient maps, or have any other knowledge about it >>>> >>>> nut the backup-mx is really useless if it depends on the primary >>>> one >>>> for >>>> proper working and in the reality a backup-mx is useless, really >>> >>> I kind of disagree. It doesn't rely on the primary for proper >>> functioning, >>> it just makes use of knowledge of the primary when it can. >> >> IT DOES >> >> normally the backup-mx will get no messages as long as the primary is >> available >> so there are no valid/ivalid RCPT cached > > That is in a world where there is no spam. In a world where there is no spam, > I don't need recipient address verification to reject mail on the backup to > begin with. So when the primary is down, all is well. > > The only reason I do need recipient address verification is spam. And having > the abused backup MX verify at the primary side, for me, is a good enough way > to prevent backscatter. > >> >> if your primary si down your backup-mx does know nothing and is a >> backscatter >> so cinfigure your mailservices properly or consider outsourcing them >> to anybody >> who can do this and makes a service level agreement where your mx is >> not down >> for some days > > I understand your point of view, but I think it should be possible to > configure a MX server as backup for anyone who wants to use it, without > maintaining extra address information, at the cost of creating backscatter > when the primary is down (which can partly be avoided by installing good spam > filtering).
Possible backscatter is no argument against this extra option. This has to be dealt with on the backup mx anyways. Outsourcing is not a fix either. We're talking about small-scale operations here. People who mostly run their servers for privacy reasons to avoid putting all their data in the iCloud. It already happened to me that I was on a ship for some days and found the primary mail server unresponsive for some reason. With a backup mx just blindly accepting everything in such a case, I just need to fix the primary and flush the backup mx to get all the mail delivered properly. I also kept a list of valid recipients on my backup mx for quite some time, but this is no elegant solution. I need to collect the list from various SLQ- and LDAP sources every few hours. Of course it works but when there is a new setup on the primary server, it's the first thing to be forgotten. Allowing unverified_recipient_tempfail_action=permit would help greatly with these smaller operations where: -emails should be accepted by _SOME_ server at all cost to prevent defer-messages. -the main server is not 100% reliable (because it's on a private ADSL-connection or so) -database replication for keeping a list of recipients isn't really worth it -but we still want some verification to prevent spam from piling up.
