I have a strange one this morning.

We received an email, to a valid user, from a domain say ( example.net )
which we thought was blacked by our access DB.

our access.db says

example.net 550 example.net denied
To:validuser [at] ourdomain.com OK
To:.ourdomain.com REJECT
To:ourdomain.com REJECT

our .mc file says

FEATURE(`access_db')dnl Host Access DB
FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
dnl FEATURE(`delay_checks')dnl Delay Checks disabled

How did it get through?

NPG <nathan [at] cmpublishers.com> writes:

> I have a strange one this morning.
>
> We received an email, to a valid user, from a domain say ( example.net )
> which we thought was blacked by our access DB.
>
> our access.db says
>
> example.net 550 example.net denied
> To:validuser [at] ourdomain.com OK
> To:.ourdomain.com REJECT
> To:ourdomain.com REJECT
>
> our .mc file says
>
> FEATURE(`access_db')dnl Host Access DB
> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>
> How did it get through?

Was it supposed to be blocked based on envelope sender or sending host?

blocking based on sending host => there may be "not closed" loop of
PTR-A dns records.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
No friendship is so cordial or so delicious as that of girl for girl;
no hatred so intense or immovable as that of woman for woman.
-- Landor

* Andrzej Adam Filip wrote:
> NPG <nathan [at] cmpublishers.com> writes:
>
>> I have a strange one this morning.
>>
>> We received an email, to a valid user, from a domain say ( example.net )
>> which we thought was blacked by our access DB.
>>
>> our access.db says
>>
>> example.net 550 example.net denied
>> To:validuser [at] ourdomain.com OK
>> To:.ourdomain.com REJECT
>> To:ourdomain.com REJECT
>>
>> our .mc file says
>>
>> FEATURE(`access_db')dnl Host Access DB
>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>>
>> How did it get through?
>
> Was it supposed to be blocked based on envelope sender or sending host?
Both

Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
like this would block both the envelope sender and connecting hosts from
example.net.

example.net 550 example.net denied

We block connections from example.net at our border. The message was
passed to our primary MX from the backup MX which we have no control
over. So in this case I don't think connection blocking is the issue.

>
> blocking based on sending host => there may be "not closed" loop of
> PTR-A dns records.
>

NPG <nathan [at] cmpublishers.com> writes:

> * Andrzej Adam Filip wrote:
>> NPG <nathan [at] cmpublishers.com> writes:
>>
>>> I have a strange one this morning.
>>>
>>> We received an email, to a valid user, from a domain say ( example.net )
>>> which we thought was blacked by our access DB.
>>>
>>> our access.db says
>>>
>>> example.net 550 example.net denied
>>> To:validuser [at] ourdomain.com OK
>>> To:.ourdomain.com REJECT
>>> To:ourdomain.com REJECT
>>>
>>> our .mc file says
>>>
>>> FEATURE(`access_db')dnl Host Access DB
>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>>>
>>> How did it get through?
>>
>> Was it supposed to be blocked based on envelope sender or sending host?
> Both
>
> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
> like this would block both the envelope sender and connecting hosts from
> example.net.
>
> example.net 550 example.net denied
>
> We block connections from example.net at our border. The message was
> passed to our primary MX from the backup MX which we have no control
> over. So in this case I don't think connection blocking is the issue.
>
>>
>> blocking based on sending host => there may be "not closed" loop of
>> PTR-A dns records.

Could you post the real access db entry and real log file entries?
[ from= and to= lines ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Wedding is destiny, and hanging likewise.
-- John Heywood

* Andrzej Adam Filip wrote:
> NPG <nathan [at] cmpublishers.com> writes:
>
>> * Andrzej Adam Filip wrote:
>>> NPG <nathan [at] cmpublishers.com> writes:
>>>
>>>> I have a strange one this morning.
>>>>
>>>> We received an email, to a valid user, from a domain say ( example.net )
>>>> which we thought was blacked by our access DB.
>>>>
>>>> our access.db says
>>>>
>>>> example.net 550 example.net denied
>>>> To:validuser [at] ourdomain.com OK
>>>> To:.ourdomain.com REJECT
>>>> To:ourdomain.com REJECT
>>>>
>>>> our .mc file says
>>>>
>>>> FEATURE(`access_db')dnl Host Access DB
>>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
>>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
>>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>>>>
>>>> How did it get through?
>>> Was it supposed to be blocked based on envelope sender or sending host?
>> Both
>>
>> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
>> like this would block both the envelope sender and connecting hosts from
>> example.net.
>>
>> example.net 550 example.net denied
>>
>> We block connections from example.net at our border. The message was
>> passed to our primary MX from the backup MX which we have no control
>> over. So in this case I don't think connection blocking is the issue.
>>
>>> blocking based on sending host => there may be "not closed" loop of
>>> PTR-A dns records.
>
> Could you post the real access db entry and real log file entries?
> [ from= and to= lines ]
>
No as this list is trolled by spammers.
The access db was posted with only user and host names changed to
protect the guilty.

I'll do the same for the log entries.

Aug 14 18:03:43 gw1 sendmail[3491]: l7EM3VGA003491:
from=<SRS0=f0VA=NL=example.net
=other.person [at] srs.bmx.net>, size=2677, class=0, nrcpts=1,
msgid=<9d6a1ae6070814
1503q4b9a8e1l4ab61e9bc855131f [at] mail.example.net>, proto=ESMTP,
daemon=MTA, relay=backup-mx.bmx.net [IP.IP.IP.IP]
Aug 14 18:03:52 gw1 sendmail[3529]: l7EM3VGA003491:
to=<validuser [at] ourdomain.com>, delay=00:00:15, xdelay=00:00:02,
mailer=relay, pri=122677, relay=host.ourdomain.com. [IP.IP.IP.IP],
dsn=2.0.0, stat=Sent (l7EM3o0x004244 Message accepted for delivery)

In article <f9vpnr$nj6$1 [at] cs2.cmpublishers.com>,
NPG <nathan [at] cmpublishers.com> wrote:

> * Andrzej Adam Filip wrote:
> > NPG <nathan [at] cmpublishers.com> writes:
> >
> >> * Andrzej Adam Filip wrote:
> >>> NPG <nathan [at] cmpublishers.com> writes:
> >>>
> >>>> I have a strange one this morning.
> >>>>
> >>>> We received an email, to a valid user, from a domain say ( example.net )
> >>>> which we thought was blacked by our access DB.
> >>>>
> >>>> our access.db says
> >>>>
> >>>> example.net 550 example.net denied
> >>>> To:validuser [at] ourdomain.com OK
> >>>> To:.ourdomain.com REJECT
> >>>> To:ourdomain.com REJECT
> >>>>
> >>>> our .mc file says
> >>>>
> >>>> FEATURE(`access_db')dnl Host Access DB
> >>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
> >>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
> >>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
> >>>>
> >>>> How did it get through?
> >>> Was it supposed to be blocked based on envelope sender or sending host?
> >> Both
> >>
> >> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
> >> like this would block both the envelope sender and connecting hosts from
> >> example.net.
> >>
> >> example.net 550 example.net denied
> >>
> >> We block connections from example.net at our border. The message was
> >> passed to our primary MX from the backup MX which we have no control
> >> over. So in this case I don't think connection blocking is the issue.
> >>
> >>> blocking based on sending host => there may be "not closed" loop of
> >>> PTR-A dns records.
> >
> > Could you post the real access db entry and real log file entries?
> > [ from= and to= lines ]
> >
> No as this list is trolled by spammers.
> The access db was posted with only user and host names changed to
> protect the guilty.
>
> I'll do the same for the log entries.
>
> Aug 14 18:03:43 gw1 sendmail[3491]: l7EM3VGA003491:
> from=<SRS0=f0VA=NL=example.net
> =other.person [at] srs.bmx.net>, size=2677, class=0, nrcpts=1,
> msgid=<9d6a1ae6070814
> 1503q4b9a8e1l4ab61e9bc855131f [at] mail.example.net>, proto=ESMTP,
> daemon=MTA, relay=backup-mx.bmx.net [IP.IP.IP.IP]
> Aug 14 18:03:52 gw1 sendmail[3529]: l7EM3VGA003491:
> to=<validuser [at] ourdomain.com>, delay=00:00:15, xdelay=00:00:02,
> mailer=relay, pri=122677, relay=host.ourdomain.com. [IP.IP.IP.IP],
> dsn=2.0.0, stat=Sent (l7EM3o0x004244 Message accepted for delivery)

Neither the envelope sender or the client hostname is in the example.net
domain.

--
Now where did I hide that website...

* Bill Cole wrote:
> In article <f9vpnr$nj6$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>> * Andrzej Adam Filip wrote:
>>> NPG <nathan [at] cmpublishers.com> writes:
>>>
>>>> * Andrzej Adam Filip wrote:
>>>>> NPG <nathan [at] cmpublishers.com> writes:
>>>>>
>>>>>> I have a strange one this morning.
>>>>>>
>>>>>> We received an email, to a valid user, from a domain say ( example.net )
>>>>>> which we thought was blacked by our access DB.
>>>>>>
>>>>>> our access.db says
>>>>>>
>>>>>> example.net 550 example.net denied
>>>>>> To:validuser [at] ourdomain.com OK
>>>>>> To:.ourdomain.com REJECT
>>>>>> To:ourdomain.com REJECT
>>>>>>
>>>>>> our .mc file says
>>>>>>
>>>>>> FEATURE(`access_db')dnl Host Access DB
>>>>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
>>>>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
>>>>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>>>>>>
>>>>>> How did it get through?
>>>>> Was it supposed to be blocked based on envelope sender or sending host?
>>>> Both
>>>>
>>>> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
>>>> like this would block both the envelope sender and connecting hosts from
>>>> example.net.
>>>>
>>>> example.net 550 example.net denied
>>>>
>>>> We block connections from example.net at our border. The message was
>>>> passed to our primary MX from the backup MX which we have no control
>>>> over. So in this case I don't think connection blocking is the issue.
>>>>
>>>>> blocking based on sending host => there may be "not closed" loop of
>>>>> PTR-A dns records.
>>> Could you post the real access db entry and real log file entries?
>>> [ from= and to= lines ]
>>>
>> No as this list is trolled by spammers.
>> The access db was posted with only user and host names changed to
>> protect the guilty.
>>
>> I'll do the same for the log entries.
>>
>> Aug 14 18:03:43 gw1 sendmail[3491]: l7EM3VGA003491:
>> from=<SRS0=f0VA=NL=example.net
>> =other.person [at] srs.bmx.net>, size=2677, class=0, nrcpts=1,
>> msgid=<9d6a1ae6070814
>> 1503q4b9a8e1l4ab61e9bc855131f [at] mail.example.net>, proto=ESMTP,
>> daemon=MTA, relay=backup-mx.bmx.net [IP.IP.IP.IP]
>> Aug 14 18:03:52 gw1 sendmail[3529]: l7EM3VGA003491:
>> to=<validuser [at] ourdomain.com>, delay=00:00:15, xdelay=00:00:02,
>> mailer=relay, pri=122677, relay=host.ourdomain.com. [IP.IP.IP.IP],
>> dsn=2.0.0, stat=Sent (l7EM3o0x004244 Message accepted for delivery)
>
> Neither the envelope sender or the client hostname is in the example.net
> domain.
>
I wondered if that was going to be the case as I was posting this last
night. Since it came through our backup MX connection blocking doesn't
apply.

My mail reader shows it as
From: "Other Person" <other.person [at] example.net>
The message headers show it as coming from example.net to my backup MX
then to my primary MX.

What is going on with that envelope sender and all those = signs?
Oh SRS ?!

I have never encountered it before, but under the circumstances my
opinion of it just plummeted.

In article <fa2nca$68u$1 [at] cs2.cmpublishers.com>,
NPG <nathan [at] cmpublishers.com> wrote:

> * Bill Cole wrote:
> > In article <f9vpnr$nj6$1 [at] cs2.cmpublishers.com>,
> > NPG <nathan [at] cmpublishers.com> wrote:
> >
> >> * Andrzej Adam Filip wrote:
> >>> NPG <nathan [at] cmpublishers.com> writes:
> >>>
> >>>> * Andrzej Adam Filip wrote:
> >>>>> NPG <nathan [at] cmpublishers.com> writes:
> >>>>>
> >>>>>> I have a strange one this morning.
> >>>>>>
> >>>>>> We received an email, to a valid user, from a domain say ( example.net
> >>>>>> )
> >>>>>> which we thought was blacked by our access DB.
> >>>>>>
> >>>>>> our access.db says
> >>>>>>
> >>>>>> example.net 550 example.net denied
> >>>>>> To:validuser [at] ourdomain.com OK
> >>>>>> To:.ourdomain.com REJECT
> >>>>>> To:ourdomain.com REJECT
> >>>>>>
> >>>>>> our .mc file says
> >>>>>>
> >>>>>> FEATURE(`access_db')dnl Host Access DB
> >>>>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
> >>>>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
> >>>>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
> >>>>>>
> >>>>>> How did it get through?
> >>>>> Was it supposed to be blocked based on envelope sender or sending host?
> >>>> Both
> >>>>
> >>>> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
> >>>> like this would block both the envelope sender and connecting hosts from
> >>>> example.net.
> >>>>
> >>>> example.net 550 example.net denied
> >>>>
> >>>> We block connections from example.net at our border. The message was
> >>>> passed to our primary MX from the backup MX which we have no control
> >>>> over. So in this case I don't think connection blocking is the issue.
> >>>>
> >>>>> blocking based on sending host => there may be "not closed" loop of
> >>>>> PTR-A dns records.
> >>> Could you post the real access db entry and real log file entries?
> >>> [ from= and to= lines ]
> >>>
> >> No as this list is trolled by spammers.
> >> The access db was posted with only user and host names changed to
> >> protect the guilty.
> >>
> >> I'll do the same for the log entries.
> >>
> >> Aug 14 18:03:43 gw1 sendmail[3491]: l7EM3VGA003491:
> >> from=<SRS0=f0VA=NL=example.net
> >> =other.person [at] srs.bmx.net>, size=2677, class=0, nrcpts=1,
> >> msgid=<9d6a1ae6070814
> >> 1503q4b9a8e1l4ab61e9bc855131f [at] mail.example.net>, proto=ESMTP,
> >> daemon=MTA, relay=backup-mx.bmx.net [IP.IP.IP.IP]
> >> Aug 14 18:03:52 gw1 sendmail[3529]: l7EM3VGA003491:
> >> to=<validuser [at] ourdomain.com>, delay=00:00:15, xdelay=00:00:02,
> >> mailer=relay, pri=122677, relay=host.ourdomain.com. [IP.IP.IP.IP],
> >> dsn=2.0.0, stat=Sent (l7EM3o0x004244 Message accepted for delivery)
> >
> > Neither the envelope sender or the client hostname is in the example.net
> > domain.
> >
> I wondered if that was going to be the case as I was posting this last
> night. Since it came through our backup MX connection blocking doesn't
> apply.
>
> My mail reader shows it as
> From: "Other Person" <other.person [at] example.net>

A From header is not necessarily related to the envelope sender or the
client hostname. Sendmail itself does not normally filter based on From
headers.

> The message headers show it as coming from example.net to my backup MX
> then to my primary MX.
>
> What is going on with that envelope sender and all those = signs?
> Oh SRS ?!

Run away from that MX operator fast.

Even if one thinks SRS is a potentially good idea, applying it to mail
that is only being relayed (not forwarded) is WRONG. Why anyone would
come up with the idea of doing that is hard to imagine without positing
malice or deep incompetence.


> I have never encountered it before, but under the circumstances my
> opinion of it just plummeted.

The root problem is having the backup MX that you do not control. That
was sometimes a useful practice in the days when connectivity problems
were chronic and widespread. It is a virtually useless practice today,
and using a backup MX that has the administrative wisdom issues you are
seeing cannot be a positive thing.

--
Now where did I hide that website...

* Bill Cole wrote:
> In article <fa2nca$68u$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>> * Bill Cole wrote:
>>> In article <f9vpnr$nj6$1 [at] cs2.cmpublishers.com>,
>>> NPG <nathan [at] cmpublishers.com> wrote:
>>>
>>>> * Andrzej Adam Filip wrote:
>>>>> NPG <nathan [at] cmpublishers.com> writes:
>>>>>
>>>>>> * Andrzej Adam Filip wrote:
>>>>>>> NPG <nathan [at] cmpublishers.com> writes:
>>>>>>>
>>>>>>>> I have a strange one this morning.
>>>>>>>>
>>>>>>>> We received an email, to a valid user, from a domain say ( example.net
>>>>>>>> )
>>>>>>>> which we thought was blacked by our access DB.
>>>>>>>>
>>>>>>>> our access.db says
>>>>>>>>
>>>>>>>> example.net 550 example.net denied
>>>>>>>> To:validuser [at] ourdomain.com OK
>>>>>>>> To:.ourdomain.com REJECT
>>>>>>>> To:ourdomain.com REJECT
>>>>>>>>
>>>>>>>> our .mc file says
>>>>>>>>
>>>>>>>> FEATURE(`access_db')dnl Host Access DB
>>>>>>>> FEATURE(`lookupdotdomain')dnl Generalize host lookup in access.db
>>>>>>>> FEATURE(`blacklist_recipients')dnl Block recipients in Access DB
>>>>>>>> dnl FEATURE(`delay_checks')dnl Delay Checks disabled
>>>>>>>>
>>>>>>>> How did it get through?
>>>>>>> Was it supposed to be blocked based on envelope sender or sending host?
>>>>>> Both
>>>>>>
>>>>>> Bat Book 2nd Ed. p. 316 3rd paragraph seems to indicate that doing it
>>>>>> like this would block both the envelope sender and connecting hosts from
>>>>>> example.net.
>>>>>>
>>>>>> example.net 550 example.net denied
>>>>>>
>>>>>> We block connections from example.net at our border. The message was
>>>>>> passed to our primary MX from the backup MX which we have no control
>>>>>> over. So in this case I don't think connection blocking is the issue.
>>>>>>
>>>>>>> blocking based on sending host => there may be "not closed" loop of
>>>>>>> PTR-A dns records.
>>>>> Could you post the real access db entry and real log file entries?
>>>>> [ from= and to= lines ]
>>>>>
>>>> No as this list is trolled by spammers.
>>>> The access db was posted with only user and host names changed to
>>>> protect the guilty.
>>>>
>>>> I'll do the same for the log entries.
>>>>
>>>> Aug 14 18:03:43 gw1 sendmail[3491]: l7EM3VGA003491:
>>>> from=<SRS0=f0VA=NL=example.net
>>>> =other.person [at] srs.bmx.net>, size=2677, class=0, nrcpts=1,
>>>> msgid=<9d6a1ae6070814
>>>> 1503q4b9a8e1l4ab61e9bc855131f [at] mail.example.net>, proto=ESMTP,
>>>> daemon=MTA, relay=backup-mx.bmx.net [IP.IP.IP.IP]
>>>> Aug 14 18:03:52 gw1 sendmail[3529]: l7EM3VGA003491:
>>>> to=<validuser [at] ourdomain.com>, delay=00:00:15, xdelay=00:00:02,
>>>> mailer=relay, pri=122677, relay=host.ourdomain.com. [IP.IP.IP.IP],
>>>> dsn=2.0.0, stat=Sent (l7EM3o0x004244 Message accepted for delivery)
>>> Neither the envelope sender or the client hostname is in the example.net
>>> domain.
>>>
>> I wondered if that was going to be the case as I was posting this last
>> night. Since it came through our backup MX connection blocking doesn't
>> apply.
>>
>> My mail reader shows it as
>> From: "Other Person" <other.person [at] example.net>
>
> A From header is not necessarily related to the envelope sender or the
> client hostname. Sendmail itself does not normally filter based on From
> headers.
Now that you mention it, ... DOH!!!
>
>> The message headers show it as coming from example.net to my backup MX
>> then to my primary MX.
>>
>> What is going on with that envelope sender and all those = signs?
>> Oh SRS ?!
>
> Run away from that MX operator fast.
>
> Even if one thinks SRS is a potentially good idea, applying it to mail
> that is only being relayed (not forwarded) is WRONG. Why anyone would
> come up with the idea of doing that is hard to imagine without positing
> malice or deep incompetence.
>
I'll vote for deep incompetence.
>
>> I have never encountered it before, but under the circumstances my
>> opinion of it just plummeted.
>
> The root problem is having the backup MX that you do not control. That
> was sometimes a useful practice in the days when connectivity problems
> were chronic and widespread. It is a virtually useless practice today,
> and using a backup MX that has the administrative wisdom issues you are
> seeing cannot be a positive thing.
>
I'll agree there.
Do you know where we can find a good backup MX?

In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
NPG <nathan [at] cmpublishers.com> wrote:

> * Bill Cole wrote:
[...]
> >
> > The root problem is having the backup MX that you do not control. That
> > was sometimes a useful practice in the days when connectivity problems
> > were chronic and widespread. It is a virtually useless practice today,
> > and using a backup MX that has the administrative wisdom issues you are
> > seeing cannot be a positive thing.
> >
> I'll agree there.
> Do you know where we can find a good backup MX?

Do you have a concrete reason to believe that having one is actually
useful for you?

Having a backup MX that you do not control is not likely to be useful
enough to justify the headaches. A second box right next to your
existing one plus inclusion of your mail service in whatever disaster
recovery planning you have is far more likely to give you availability
without spammers using your backup as a back door.

--
Now where did I hide that website...

Bill Cole <bill [at] scconsult.com> writes:

> In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>> * Bill Cole wrote:
> [...]
>> >
>> > The root problem is having the backup MX that you do not control. That
>> > was sometimes a useful practice in the days when connectivity problems
>> > were chronic and widespread. It is a virtually useless practice today,
>> > and using a backup MX that has the administrative wisdom issues you are
>> > seeing cannot be a positive thing.
>> >
>> I'll agree there.
>> Do you know where we can find a good backup MX?
>
> Do you have a concrete reason to believe that having one is actually
> useful for you?
>
> Having a backup MX that you do not control is not likely to be useful
> enough to justify the headaches. A second box right next to your
> existing one plus inclusion of your mail service in whatever disaster
> recovery planning you have is far more likely to give you availability
> without spammers using your backup as a back door.

I personally suggest for *bigger* mail services to use double/multiple
primary MXes located in two+ *separate* locations.

Beside `connectivity problems' there are fires, floods, long power
outages, ... You should expect one of such every few years. It is up to
you to decide if it is cost effective to be prepared for them.

It is waste of resources for small "single office" firm *BUT*
it is *very logical* configuration for big multinational company running
its own VPN and centralized email gateway(s).

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Nature is by and large to be found out of doors, a location where,
it cannot be argued, there are never enough comfortable chairs.
-- Fran Lebowitz

In article <87tzqwdljf.fsf [at] anfi.office-on-the.net>,
Andrzej Adam Filip <anfi [at] onet.eu> wrote:

> Bill Cole <bill [at] scconsult.com> writes:
>
> > In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
> > NPG <nathan [at] cmpublishers.com> wrote:
> >
> >> * Bill Cole wrote:
> > [...]
> >> >
> >> > The root problem is having the backup MX that you do not control. That
> >> > was sometimes a useful practice in the days when connectivity problems
> >> > were chronic and widespread. It is a virtually useless practice today,
> >> > and using a backup MX that has the administrative wisdom issues you are
> >> > seeing cannot be a positive thing.
> >> >
> >> I'll agree there.
> >> Do you know where we can find a good backup MX?
> >
> > Do you have a concrete reason to believe that having one is actually
> > useful for you?
> >
> > Having a backup MX that you do not control is not likely to be useful
> > enough to justify the headaches. A second box right next to your
> > existing one plus inclusion of your mail service in whatever disaster
> > recovery planning you have is far more likely to give you availability
> > without spammers using your backup as a back door.
>
> I personally suggest for *bigger* mail services to use double/multiple
> primary MXes located in two+ *separate* locations.

Certainly, if you have that sort of scale. That's perfectly consistent
with what I wrote.

> Beside `connectivity problems' there are fires, floods, long power
> outages, ... You should expect one of such every few years. It is up to
> you to decide if it is cost effective to be prepared for them.

More commonly, the use of cheap hardware leads to some failure that
knocks out a mail server sitting in an otherwise sound location. That's
why I suggested that having a second box right next to the first (or
maybe across the desk so that the power supply flame-out can't reach
it...) as an alternative to an MX on someone else's machine.


> It is waste of resources for small "single office" firm *BUT*
> it is *very logical* configuration for big multinational company running
> its own VPN and centralized email gateway(s).

I think you did not read what I wrote carefully.

2 of the 3 paragraphs I wrote which you quoted above start with
semantically near-identical startements, and neither conflicts in any
way with the fact that a company with multiple sites can find it very
useful to have mail gateways in multiple sites.

--
Now where did I hide that website...

Bill Cole <bill [at] scconsult.com> writes:

> In article <87tzqwdljf.fsf [at] anfi.office-on-the.net>,
> Andrzej Adam Filip <anfi [at] onet.eu> wrote:
>
>> Bill Cole <bill [at] scconsult.com> writes:
>>
>> > In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
>> > NPG <nathan [at] cmpublishers.com> wrote:
>> >
>> >> * Bill Cole wrote:
>> > [...]
>> >> >
>> >> > The root problem is having the backup MX that you do not control. That
>> >> > was sometimes a useful practice in the days when connectivity problems
>> >> > were chronic and widespread. It is a virtually useless practice today,
>> >> > and using a backup MX that has the administrative wisdom issues you are
>> >> > seeing cannot be a positive thing.
>> >> >
>> >> I'll agree there.
>> >> Do you know where we can find a good backup MX?
>> >
>> > Do you have a concrete reason to believe that having one is actually
>> > useful for you?
>> >
>> > Having a backup MX that you do not control is not likely to be useful
>> > enough to justify the headaches. A second box right next to your
>> > existing one plus inclusion of your mail service in whatever disaster
>> > recovery planning you have is far more likely to give you availability
>> > without spammers using your backup as a back door.
>>
>> I personally suggest for *bigger* mail services to use double/multiple
>> primary MXes located in two+ *separate* locations.
>
> Certainly, if you have that sort of scale. That's perfectly consistent
> with what I wrote.
>
>> Beside `connectivity problems' there are fires, floods, long power
>> outages, ... You should expect one of such every few years. It is up to
>> you to decide if it is cost effective to be prepared for them.
>
> More commonly, the use of cheap hardware leads to some failure that
> knocks out a mail server sitting in an otherwise sound location. That's
> why I suggested that having a second box right next to the first (or
> maybe across the desk so that the power supply flame-out can't reach
> it...) as an alternative to an MX on someone else's machine.
>
>
>> It is waste of resources for small "single office" firm *BUT*
>> it is *very logical* configuration for big multinational company running
>> its own VPN and centralized email gateway(s).
>
> I think you did not read what I wrote carefully.
>
> 2 of the 3 paragraphs I wrote which you quoted above start with
> semantically near-identical startements, and neither conflicts in any
> way with the fact that a company with multiple sites can find it very
> useful to have mail gateways in multiple sites.

So we agree :-) [ Sorry I have not read full thread ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
"There was a boy called Eustace Clarence Scrubb, and he almost deserved it."
-- C. S. Lewis, "The Chronicles of Narnia"

* Bill Cole wrote:
> In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>> * Bill Cole wrote:
> [...]
>>> The root problem is having the backup MX that you do not control. That
>>> was sometimes a useful practice in the days when connectivity problems
>>> were chronic and widespread. It is a virtually useless practice today,
>>> and using a backup MX that has the administrative wisdom issues you are
>>> seeing cannot be a positive thing.
>>>
>> I'll agree there.
>> Do you know where we can find a good backup MX?
>
> Do you have a concrete reason to believe that having one is actually
> useful for you?
>
> Having a backup MX that you do not control is not likely to be useful
> enough to justify the headaches. A second box right next to your
> existing one plus inclusion of your mail service in whatever disaster
> recovery planning
a.k.a
a backup MX
Are their other options? ( please not UUCP ) :-)
> you have is far more likely to give you availability
> without spammers using your backup as a back door.
>
If we owned our backup MX it would be different. Since we don't all we
expect from a third party backup MX is relaying.
If we were a backup MX for someone, all we would do is relay their mail.
Spam, backscatter, legitimate mail etc.
Isn't that what a third party backup MX should do. Relay it, not touch
it. As opposed to what my current backup MX did.

In article <faa5ot$j5r$1 [at] cs2.cmpublishers.com>,
NPG <nathan [at] cmpublishers.com> wrote:

> * Bill Cole wrote:
> > In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
> > NPG <nathan [at] cmpublishers.com> wrote:
> >
> >> * Bill Cole wrote:
> > [...]
> >>> The root problem is having the backup MX that you do not control. That
> >>> was sometimes a useful practice in the days when connectivity problems
> >>> were chronic and widespread. It is a virtually useless practice today,
> >>> and using a backup MX that has the administrative wisdom issues you are
> >>> seeing cannot be a positive thing.
> >>>
> >> I'll agree there.
> >> Do you know where we can find a good backup MX?
> >
> > Do you have a concrete reason to believe that having one is actually
> > useful for you?
> >
> > Having a backup MX that you do not control is not likely to be useful
> > enough to justify the headaches. A second box right next to your
> > existing one plus inclusion of your mail service in whatever disaster
> > recovery planning
> a.k.a
> a backup MX
> Are their other options? ( please not UUCP ) :-)

When I say "disaster recovery" I mean whatever your contingency plan is
if your existing facilities are burnt to the ground.

A backup MX is more than a DR tactic in that it is always active, and
without mail store (e.g. POP3 or IMAP) functionality it is not a DR
tactic at all because you still can't get your mail until you have a
primary back online. It's not a solution to the destruction of your
facilities, only a minor assistance in the event of a temporary
disconnection.

A lightweight DR tactic might be to identify a hosting provider where
you can bring up your own replacement mail system fast. A more robust
approach would be a contract with a serious DR service provider (e.g.
SunGard) and a plan for getting all of your offsite backup tapes (you
have those, right?) to the provider when your disaster hits.

Having someone willing to relay mail to a smoking hole is not a solution
to anything. If you cannot think up a circumstance where having that
backup MX actually does you good, don't have it.

> > you have is far more likely to give you availability
> > without spammers using your backup as a back door.
> >
> If we owned our backup MX it would be different. Since we don't all we
> expect from a third party backup MX is relaying.
> If we were a backup MX for someone, all we would do is relay their mail.
> Spam, backscatter, legitimate mail etc.
> Isn't that what a third party backup MX should do. Relay it, not touch
> it. As opposed to what my current backup MX did.

A backup MX that blindly relays your mail is still a problem in the day
of mail being 90% spam. It takes a lot of work and a close relationship
with your provider to avoid that setup being the source of backscatter,
and somewhere you will either create a blackhole for mail or send
backscatter with such an arrangement.

--
Now where did I hide that website...

* Bill Cole wrote:
> In article <faa5ot$j5r$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>> * Bill Cole wrote:
>>> In article <fa8diq$444$1 [at] cs2.cmpublishers.com>,
>>> NPG <nathan [at] cmpublishers.com> wrote:
>>>
>>>> * Bill Cole wrote:
>>> [...]
>>>>> The root problem is having the backup MX that you do not control. That
>>>>> was sometimes a useful practice in the days when connectivity problems
>>>>> were chronic and widespread. It is a virtually useless practice today,
>>>>> and using a backup MX that has the administrative wisdom issues you are
>>>>> seeing cannot be a positive thing.
>>>>>
>>>> I'll agree there.
>>>> Do you know where we can find a good backup MX?
>>> Do you have a concrete reason to believe that having one is actually
>>> useful for you?
>>>
>>> Having a backup MX that you do not control is not likely to be useful
>>> enough to justify the headaches. A second box right next to your
>>> existing one plus inclusion of your mail service in whatever disaster
>>> recovery planning
>> a.k.a
>> a backup MX
>> Are their other options? ( please not UUCP ) :-)
>
> When I say "disaster recovery" I mean whatever your contingency plan is
> if your existing facilities are burnt to the ground.
When I say "disaster recovery" I mean whatever your contingency plan is
if your existing internet connections are burnt to the ground.
>
> A backup MX is more than a DR tactic in that it is always active, and
> without mail store (e.g. POP3 or IMAP) functionality it is not a DR
> tactic at all because you still can't get your mail until you have a
> primary back online. It's not a solution to the destruction of your
> facilities, only a minor assistance in the event of a temporary
> disconnection.
Which is what we use it for.
>
> A lightweight DR tactic might be to identify a hosting provider where
> you can bring up your own replacement mail system fast. A more robust
> approach would be a contract with a serious DR service provider (e.g.
> SunGard) and a plan for getting all of your offsite backup tapes (you
> have those, right?) to the provider when your disaster hits.
>
> Having someone willing to relay mail to a smoking hole is not a solution
> to anything. If you cannot think up a circumstance where having that
> backup MX actually does you good, don't have it.
minor assistance in the event of a temporary disconnection.
>
>>> you have is far more likely to give you availability
>>> without spammers using your backup as a back door.
>>>
>> If we owned our backup MX it would be different. Since we don't all we
>> expect from a third party backup MX is relaying.
>> If we were a backup MX for someone, all we would do is relay their mail.
>> Spam, backscatter, legitimate mail etc.
>> Isn't that what a third party backup MX should do. Relay it, not touch
>> it. As opposed to what my current backup MX did.
>
> A backup MX that blindly relays your mail is still a problem in the day
> of mail being 90% spam.
But less of a problem than our current backup MX is doing ( SRS,
applying it to mail that is only being relayed (not forwarded) is WRONG.) ).
> It takes a lot of work and a close relationship
> with your provider to avoid that setup being the source of backscatter,
The current situation probably already is. However, as it is their
machine, figuring out what to do with a message that our primary MX
rejects is their problem.
> and somewhere you will either create a blackhole for mail or send
> backscatter with such an arrangement.
>
Understood
Again
If we were a backup MX for someone, we would blackhole anything the
primary MX permanently rejected.
That is what we would expect our backup MX to do.

The situation summary is this

1 - We want a backup MX.
2 - We are not impressed with our current backup MX provider due to
their application of SRS to relayed mail.
3 - We are looking for a backup MX that will only relay our mail, and
blackhole what our primary MX rejects.
4 - Until we find that, our solution to the original problem will be,

srs.bmx.net 550 srs.bmx.net denied

added to our access.db.

Again
Do you know where we can find a good backup MX?

In article <fadj7s$5lg$1 [at] cs2.cmpublishers.com>,
NPG <nathan [at] cmpublishers.com> wrote:


> The situation summary is this
>
> 1 - We want a backup MX.

Apparently that's an article of faith for you.

I can't see the value in it on the modern net unless you control the
backup system or have very special circumstances.

> 2 - We are not impressed with our current backup MX provider due to
> their application of SRS to relayed mail.
> 3 - We are looking for a backup MX that will only relay our mail, and
> blackhole what our primary MX rejects.
> 4 - Until we find that, our solution to the original problem will be,
>
> srs.bmx.net 550 srs.bmx.net denied
>
> added to our access.db.
>
> Again
> Do you know where we can find a good backup MX?

You can put your own machine (or lease someone else's) in a colo
somewhere and set it up to

If all you buy is relaying through someone else's MTA, you're paying for
a negative.

--
Now where did I hide that website...

* Bill Cole wrote:
> In article <fadj7s$5lg$1 [at] cs2.cmpublishers.com>,
> NPG <nathan [at] cmpublishers.com> wrote:
>
>
>> The situation summary is this
>>
>> 1 - We want a backup MX.
>
> Apparently that's an article of faith for you.
>
> I can't see the value in it on the modern net unless you control the
> backup system or have very special circumstances.
>
I respect your opinions, I just don't share this one.

Agree to disagree? :-)
>> 2 - We are not impressed with our current backup MX provider due to
>> their application of SRS to relayed mail.
>> 3 - We are looking for a backup MX that will only relay our mail, and
>> blackhole what our primary MX rejects.
>> 4 - Until we find that, our solution to the original problem will be,
>>
>> srs.bmx.net 550 srs.bmx.net denied
>>
>> added to our access.db.
>>
>> Again
>> Do you know where we can find a good backup MX?
>
> You can put your own machine (or lease someone else's) in a colo
> somewhere and set it up to
>
> If all you buy is relaying through someone else's MTA, you're paying for
> a negative.
>
It doesn't cost us anything in dollars right now, just nuisance, the
amount of which is negligible, compared to the general nuisances /
responsibilities involved with being connected in the first place.

Seriously, the script kiddies' hacking raids against us have more of an
effect than our backup MX does, and they are just a nuisance.

In article <fadj7s$5lg$1 [at] cs2.cmpublishers.com> NPG
<nathan [at] cmpublishers.com> writes:
>* Bill Cole wrote:
>> It takes a lot of work and a close relationship
>> with your provider to avoid that setup being the source of backscatter,
>The current situation probably already is. However, as it is their
>machine, figuring out what to do with a message that our primary MX
>rejects is their problem.

You're mistaken on that point - it is very much *your* problem, see
below. (Aside: Your messages will be a lot more readable if you leave an
empty line between the quoted text and your own).

>> and somewhere you will either create a blackhole for mail or send
>> backscatter with such an arrangement.
>>
>Understood
>Again
>If we were a backup MX for someone, we would blackhole anything the
>primary MX permanently rejected.
>That is what we would expect our backup MX to do.

Please elaborate on how you would implement that. First of all what is
the "anything"? - Will you blackhole the recipient address, the sender
address, the SMTP client, something in the message content, or something
else? The MX has no reliable way of determining the reason for the
rejection, except possibly in the case of a plain "User unknown".

Second, how can the backup MX know what the primary rejects? The very
reason for it having messages to deliver to the primary is that the
primary is down (assuming that the MX is doing something useful - which
you apparently expect it to do - and isn't just forwarding spam
intentionally sent to a lower-prio MX). I.e. it won't get any
information from the primary at that point, but has to queue all mail,
which leads to an exceedingly bad case of the problem Bill describes
above.

Bottom line, the *only* responsible way to have a backup MX in today's
email world is to have it closely track both the set of known users and
the spam policy of the primary. If you can find a third-party MX that
does that (yes I know that you were actually asking for
recommendations:-), great, but otherwise running your own off-site as
already suggested is the best bet - assuming that you really see any
advantage with having one at all, you still haven't explained why you
think so AFAICS.

--Per Hedeland
per [at] hedeland.org

* Per Hedeland wrote:
> In article <fadj7s$5lg$1 [at] cs2.cmpublishers.com> NPG
> <nathan [at] cmpublishers.com> writes:
>> * Bill Cole wrote:
>>> It takes a lot of work and a close relationship
>>> with your provider to avoid that setup being the source of backscatter,
>> The current situation probably already is. However, as it is their
>> machine, figuring out what to do with a message that our primary MX
>> rejects is their problem.
>
> You're mistaken on that point - it is very much *your* problem, see
> below. (Aside: Your messages will be a lot more readable if you leave an
> empty line between the quoted text and your own).
>

Good Idea, I never thought of that. Thanks.

>>> and somewhere you will either create a blackhole for mail or send
>>> backscatter with such an arrangement.
>>>
>> Understood
>> Again
>> If we were a backup MX for someone, we would blackhole anything the
>> primary MX permanently rejected.
>> That is what we would expect our backup MX to do.
>
> Please elaborate on how you would implement that.

Please hang myself, I was already going back & forth with Bill ( who
knows a lot more than myself ), I am not sure if I want to make a
complete fool of myself. :-)

> First of all what is
> the "anything"? - Will you blackhole the recipient address, the sender
> address, the SMTP client, something in the message content, or something
> else?

Maybe blackhole wasn't the best term to use. What I meant was that the
whole message would just disappear into our system.

After applying RFC 2821 to my brain, it appears that I have already hung
myself with that statement.

> The MX has no reliable way of determining the reason for the
> rejection, except possibly in the case of a plain "User unknown".
>
> Second, how can the backup MX know what the primary rejects? The very
> reason for it having messages to deliver to the primary is that the
> primary is down (assuming that the MX is doing something useful - which
> you apparently expect it to do - and isn't just forwarding spam
> intentionally sent to a lower-prio MX). I.e. it won't get any
> information from the primary at that point, but has to queue all mail,
> which leads to an exceedingly bad case of the problem Bill describes
> above.
>

Here is the scenario I was thinking of.

1 Say I am a backup MX for example.com.
2 Their primary MX goes down.
3 Their mail queues up on my server
4 Their primary MX comes back up.
5 My server starts sending them their mail.
6 Their MX rejects a recipient with 550.
7 My server drops the message.
8 My server does not send a bounce to the sender.

So basically
1 They get mail that their primary MX accepts.
2 I drop mail their primary MX rejects.
3 I don't send backscatter.

> Bottom line, the *only* responsible way to have a backup MX in today's
> email world is to have it closely track both the set of known users and
> the spam policy of the primary.

What is irresponsible about my idea. If I was a backup for someone. It
is none of my business who their users are, or what their spam policy
is. All I am responsible for is handing them their mail. If they
reject it with a 550 there is no way I am going to be able to deliver it.
They are the primary MX. Once I have tried to deliver it, and they don't
want it, it is no longer my problem. At this point I could send a
bounce or drop it. Dropping it seems to be the right thing to do.

a.k.a Be liberal in what you receive, strict in what you send.

> If you can find a third-party MX that
> does that (yes I know that you were actually asking for
> recommendations:-),

Thanks, at least someone does. :-)

> great, but otherwise running your own off-site as
> already suggested is the best bet

It would be nice if we could.

> - assuming that you really see any
> advantage with having one at all, you still haven't explained why you
> think so AFAICS.
>

Because I am the admin here and I want one. :-)

On the flip side you are the admin there and Bill is the admin over
there. You guys don't want them, and therefore don't have them.
Nothing I have to say would change your minds on the subject anyways.
To be honest I wouldn't even try. :-)
Seriously, its your site run it how you want.
As I said to Bill.
I respect your opinions, I just don't share this one.

> --Per Hedeland
> per [at] hedeland.org
>
>

In article <favdp2$6ib$1 [at] cs2.cmpublishers.com> NPG
<nathan [at] cmpublishers.com> writes:
>* Per Hedeland wrote:
>> First of all what is
>> the "anything"? - Will you blackhole the recipient address, the sender
>> address, the SMTP client, something in the message content, or something
>> else?
>
>Maybe blackhole wasn't the best term to use. What I meant was that the
>whole message would just disappear into our system.
>
>After applying RFC 2821 to my brain, it appears that I have already hung
>myself with that statement.

Well, these days no-one will claim that the RFCs are the "law" when it
comes to e-mail processing - however I think that from all perspectives,
it is an extremely important goal to not let the spam-fighting cause
legitimate mail to be completely *lost*. And of course we must try to
avoid backscatter...

>Here is the scenario I was thinking of.
>
>1 Say I am a backup MX for example.com.
>2 Their primary MX goes down.
>3 Their mail queues up on my server
>4 Their primary MX comes back up.
>5 My server starts sending them their mail.
>6 Their MX rejects a recipient with 550.
>7 My server drops the message.
>8 My server does not send a bounce to the sender.

Which means that a typo'ed address on a legitimate message will cause
the message to go down a black hole(!:-) - not acceptable in my book.

>> Bottom line, the *only* responsible way to have a backup MX in today's
>> email world is to have it closely track both the set of known users and
>> the spam policy of the primary.
>
>What is irresponsible about my idea.

See above. Well, maybe "irresponsible" isn't the right word, I guess
you're in some sense responsible to the users of the system you admin,
and if those users think it's OK that mail from their correspondents
just disappears occasionally, I guess you're not being irresponsible...

> If I was a backup for someone. It
>is none of my business who their users are, or what their spam policy
>is. All I am responsible for is handing them their mail. If they
>reject it with a 550 there is no way I am going to be able to deliver it.
>They are the primary MX. Once I have tried to deliver it, and they don't
>want it, it is no longer my problem. At this point I could send a
>bounce or drop it. Dropping it seems to be the right thing to do.

No. Bouncing it is wrong. Dropping it is wrong. Rejecting it in the SMTP
session where you (i.e. the MX) receive it is right. Which means that
you need to know whether the primary will reject it without asking at
that point. Of course, I'm not saying that it's wrong for someone to
offer backup MX service of the form that you describe (provided you do
describe it) - but it's wrong to use it.

>> great, but otherwise running your own off-site as
>> already suggested is the best bet
>
>It would be nice if we could.

Co-located (virtual) server isn't economically feasible, or what?

>> - assuming that you really see any
>> advantage with having one at all, you still haven't explained why you
>> think so AFAICS.
>>
>
>Because I am the admin here and I want one. :-)
>
>On the flip side you are the admin there and Bill is the admin over
>there. You guys don't want them, and therefore don't have them.
>Nothing I have to say would change your minds on the subject anyways.
>To be honest I wouldn't even try. :-)
>Seriously, its your site run it how you want.
>As I said to Bill.
>I respect your opinions, I just don't share this one.

Well, discussion can be useful even if no (participant) minds are
changed. I would really be interested in hearing a good motivation (or
*any* motivation) for having a backup MX of the form you expect, since I
can't see that it buys you anything other than a significantly increased
risk of losing mail when your primary is down. Of course I will probably
try to shoot down your arguments, but you're free to not change your
mind because of that.:-)

--Per Hedeland
per [at] hedeland.org

* Per Hedeland wrote:
> In article <favdp2$6ib$1 [at] cs2.cmpublishers.com> NPG
> <nathan [at] cmpublishers.com> writes:
>> * Per Hedeland wrote:
>>> First of all what is
>>> the "anything"? - Will you blackhole the recipient address, the sender
>>> address, the SMTP client, something in the message content, or something
>>> else?
>> Maybe blackhole wasn't the best term to use. What I meant was that the
>> whole message would just disappear into our system.
>>
>> After applying RFC 2821 to my brain, it appears that I have already hung
>> myself with that statement.
>
> Well, these days no-one will claim that the RFCs are the "law" when it
> comes to e-mail processing - however I think that from all perspectives,
> it is an extremely important goal to not let the spam-fighting cause
> legitimate mail to be completely *lost*. And of course we must try to
> avoid backscatter...
>

Agreed.

>> Here is the scenario I was thinking of.
>>
>> 1 Say I am a backup MX for example.com.
>> 2 Their primary MX goes down.
>> 3 Their mail queues up on my server
>> 4 Their primary MX comes back up.
>> 5 My server starts sending them their mail.
>> 6 Their MX rejects a recipient with 550.
>> 7 My server drops the message.
>> 8 My server does not send a bounce to the sender.
>
> Which means that a typo'ed address on a legitimate message will cause
> the message to go down a black hole(!:-) - not acceptable in my book.
>

Good point.

>>> Bottom line, the *only* responsible way to have a backup MX in today's
>>> email world is to have it closely track both the set of known users and
>>> the spam policy of the primary.
>> What is irresponsible about my idea.
>
> See above. Well, maybe "irresponsible" isn't the right word, I guess
> you're in some sense responsible to the users of the system you admin,
> and if those users think it's OK that mail from their correspondents
> just disappears occasionally, I guess you're not being irresponsible...
>

:-)

>> If I was a backup for someone. It
>> is none of my business who their users are, or what their spam policy
>> is. All I am responsible for is handing them their mail. If they
>> reject it with a 550 there is no way I am going to be able to deliver it.
>> They are the primary MX. Once I have tried to deliver it, and they don't
>> want it, it is no longer my problem. At this point I could send a
>> bounce or drop it. Dropping it seems to be the right thing to do.
>
> No. Bouncing it is wrong. Dropping it is wrong. Rejecting it in the SMTP
> session where you (i.e. the MX) receive it is right. Which means that
> you need to know whether the primary will reject it without asking at
> that point.

I see, so
Bouncing it is wrong because I have already taken responsibility for it.
Dropping it is wrong because there is a chance that it might have been a
legitimate ( but misaddressed ) message.

I see, the receiver should Accept it, and then deliver it, or should
reject it.

> Of course, I'm not saying that it's wrong for someone to
> offer backup MX service of the form that you describe (provided you do
> describe it) - but it's wrong to use it.
>

It is definitely not the nest solution.

>>> great, but otherwise running your own off-site as
>>> already suggested is the best bet
>> It would be nice if we could.
>
> Co-located (virtual) server isn't economically feasible, or what?
>

Basically, yes.
We are a small company, not a backbone provider. :-)

>>> - assuming that you really see any
>>> advantage with having one at all, you still haven't explained why you
>>> think so AFAICS.
>>>
>> Because I am the admin here and I want one. :-)
>>
>> On the flip side you are the admin there and Bill is the admin over
>> there. You guys don't want them, and therefore don't have them.
>> Nothing I have to say would change your minds on the subject anyways.
>> To be honest I wouldn't even try. :-)
>> Seriously, its your site run it how you want.
>> As I said to Bill.
>> I respect your opinions, I just don't share this one.
>
> Well, discussion can be useful even if no (participant) minds are
> changed. I would really be interested in hearing a good motivation (or
> *any* motivation) for having a backup MX of the form you expect, since I
> can't see that it buys you anything other than a significantly increased
> risk of losing mail when your primary is down.

All we would lose is what the primary wouldn't accept anyway.
Senders would lose their bounces if their mail went through the backup
MX. ( Their typo, their problem. )

> Of course I will probably
> try to shoot down your arguments, but you're free to not change your
> mind because of that.:-)

:-)

>
> --Per Hedeland
> per [at] hedeland.org

In article <fb47h5$af7$1 [at] cs2.cmpublishers.com> NPG
<nathan [at] cmpublishers.com> writes:
>* Per Hedeland wrote:
>>
>> No. Bouncing it is wrong. Dropping it is wrong. Rejecting it in the SMTP
>> session where you (i.e. the MX) receive it is right. Which means that
>> you need to know whether the primary will reject it without asking at
>> that point.
>
>I see, so
>Bouncing it is wrong because I have already taken responsibility for it.

No, bouncing it is wrong because that can be backscatter. If it wasn't
for the &% [at] )(%) [at] #?* spammers, it would be perfectly fine, and it was
what every mail system on the planet did before the age of spam. It is
also perfectly fine as far as the RFCs are concerned - one point where
they differ from reality.

>Dropping it is wrong because there is a chance that it might have been a
>legitimate ( but misaddressed ) message.

Yes. Or maybe your spam filters did a false positive - your "fault" of
course, but without the blackholing MX, the legitimate sender would have
received a bounce to that effect, and could try changing the content
and/or tell you to fix your filters and/or use some other means of
communication.

>I see, the receiver should Accept it, and then deliver it, or should
>reject it.

In the age of spam, yes.

>> Co-located (virtual) server isn't economically feasible, or what?
>>
>
>Basically, yes.
>We are a small company, not a backbone provider. :-)

Actually, I think such services are pretty cheap these days as long as
your processing and bandwidth needs are moderate.

>> Well, discussion can be useful even if no (participant) minds are
>> changed. I would really be interested in hearing a good motivation (or
>> *any* motivation) for having a backup MX of the form you expect, since I
>> can't see that it buys you anything other than a significantly increased
>> risk of losing mail when your primary is down.
>
>All we would lose is what the primary wouldn't accept anyway.

But that is obviously not an argument for having a backup, only a claim
that it wouldn't actually cause any harm. And that claim is even
invalid, because:

>Senders would lose their bounces if their mail went through the backup
>MX. ( Their typo, their problem. )

No, you should assume that the sender and recipient both have an
interest in reliable delivery of legitimate mail. The lost mail might
have been something very important for one of your users to receive -
after a while he gets p*ssed off at the sender for not sending it and
calls him up to complain - at which point the sender claims that he
*did* send it, and might even be able to produce log entries showing
your MX accepting it. Now who will your user be p*ssed off at?

>> Of course I will probably
>> try to shoot down your arguments, but you're free to not change your
>> mind because of that.:-)
>
>:-)

I'm still waiting for any actual pro arguments.:-)

--Per Hedeland
per [at] hedeland.org

* Per Hedeland wrote:
> In article <fb47h5$af7$1 [at] cs2.cmpublishers.com> NPG
> <nathan [at] cmpublishers.com> writes:
>> * Per Hedeland wrote:
>>> No. Bouncing it is wrong. Dropping it is wrong. Rejecting it in the SMTP
>>> session where you (i.e. the MX) receive it is right. Which means that
>>> you need to know whether the primary will reject it without asking at
>>> that point.
>> I see, so
>> Bouncing it is wrong because I have already taken responsibility for it.
>
> No, bouncing it is wrong because that can be backscatter. If it wasn't
> for the &% [at] )(%) [at] #?* spammers, it would be perfectly fine, and it was
> what every mail system on the planet did before the age of spam. It is
> also perfectly fine as far as the RFCs are concerned - one point where
> they differ from reality.
>

So it is a case of the bad guys ruining a good thing for everyone due to
their misuse of it.

>> Dropping it is wrong because there is a chance that it might have been a
>> legitimate ( but misaddressed ) message.
>
> Yes. Or maybe your spam filters did a false positive - your "fault" of
> course, but without the blackholing MX, the legitimate sender would have
> received a bounce to that effect, and could try changing the content
> and/or tell you to fix your filters and/or use some other means of
> communication.
>

Correct

>> I see, the receiver should Accept it, and then deliver it, or should
>> reject it.
>
> In the age of spam, yes.
>
>>> Co-located (virtual) server isn't economically feasible, or what?
>>>
>> Basically, yes.
>> We are a small company, not a backbone provider. :-)
>
> Actually, I think such services are pretty cheap these days as long as
> your processing and bandwidth needs are moderate.
>

I'll definitely look around. Recommendations are welcome.

>>> Well, discussion can be useful even if no (participant) minds are
>>> changed. I would really be interested in hearing a good motivation (or
>>> *any* motivation) for having a backup MX of the form you expect, since I
>>> can't see that it buys you anything other than a significantly increased
>>> risk of losing mail when your primary is down.
>> All we would lose is what the primary wouldn't accept anyway.
>
> But that is obviously not an argument for having a backup, only a claim
> that it wouldn't actually cause any harm. And that claim is even
> invalid, because:
>
>> Senders would lose their bounces if their mail went through the backup
>> MX. ( Their typo, their problem. )
>
> No, you should assume that the sender and recipient both have an
> interest in reliable delivery of legitimate mail. The lost mail might
> have been something very important for one of your users to receive -
> after a while he gets p*ssed off at the sender for not sending it and
> calls him up to complain - at which point the sender claims that he
> *did* send it, and might even be able to produce log entries showing
> your MX accepting it. Now who will your user be p*ssed off at?
>

Point Scored.

>>> Of course I will probably
>>> try to shoot down your arguments, but you're free to not change your
>>> mind because of that.:-)
>> :-)
>
> I'm still waiting for any actual pro arguments.:-)
>

You are not going to get any.
Our DNS has spoken :-)

> --Per Hedeland
> per [at] hedeland.org

* NPG wrote:
> * Per Hedeland wrote:

>> I'm still waiting for any actual pro arguments.:-)
>>
>
> You are not going to get any.

I thought up one.

At our border we block all traffic from any address that has sent us
hostile traffic. aka hacking, spam, packet floods etc. This is
followed by a "very slow" APEWS type escalation in the event that more
addresses nearby cause us trouble. However certain ISP's whose
customers have caused us too much trouble get their space blocked on
site. ( Comcast, Road Runner )

If for instance
1 Your network or address got into our blocklist
2 You needed to communicate with us in the future
3 Email would not work for communications

We had a backup MX so that people in this situation could still email
us if necessary. For instance, a subcontractor or customer in bad space
could email us in order to get access to our site. We will be glad to
restore access to blocked space providing their is a demonstrable need
to communicate. ( today, we unblocked an /18 for a /32 we want to hear
from )
I understand that our blocking policy is aggressive. However a few
hours per week maintaining a blocklist is less expensive than being
owned. Been there, cleaned up after that. Lost three days of my life
in the process.

So that was my reason.

I will admit
1 It had good intentions behind it.
2 In practice it didn't work too well because
1 Spammers misused it.
2 Our former backup MX made it worse by applying SRS to relayed mail.

So in our current configuration. ( which you and Bill seem to favor )
If you are in our blocklist, you can forget about email.

Somehow our current state seems worse than what we had, or what I
proposed. ( the missing bounces from our backup MX )

> Our DNS has spoken :-)

Finally the new zone has propagated.

>
>> --Per Hedeland
>> per [at] hedeland.org