On Saturday, June 30, 2012 11:04:02 PM Michael J. Tubby B.Sc G8TIC wrote:
> On 01/07/2012 01:06, Chris Knadle wrote:
> > On Saturday, June 30, 2012 09:12:59 PM Michael J. Tubby B.Sc G8TIC wrote:
> >> Chris,
> >>
> >> While your idea is interesting its not necessarily scalable, I have 800+
> >> domains each with 1-1000 addresses...
> >
> > Absolutely. This solution is definitely not meant for that kind of scale.
> >
> > For the kind of scale you're dealing with, one of the things I've done in
> > the past is email routing via LDAP lookups and then using several
> > multi-master LDAP servers that keep each other in sync, and where the
> > respective local email administrators update their local LDAP server for
> > the domains they control. This solution makes the general assumption
> > that you can trust the other admins though, so it might be a solution
> > relegated to a single organization and it's subsidiaries.
> >
> > It think it's interesting to consider whether this kind of thing could
> > possibly be used cooperatively between organizations, though. It's not
> > unheard of even in large multi-organizations for there to be a combined
> > email solution. [I remember reading about a large Exchange solution used
> > by Ford Motor Company combined with others, which really sounded like
> > trouble to me.]
> >
> >> I use recipient verify, i.e. I call out to the next hop host and verify
> >> the recipient. The host is usually present, however if it is not
> >> contactable then I default to accepting the mail and queuing it. This
> >> means there's a slightly higher chance of them getting spam (backscatter
> >> spam) while their host is offline.
> >
> > Yes, although your mail server(s) will be serving the backscatter spam
> > when
> > that inevitably happens. That's what happened to me when I tried using
> > this solution, and that's why I didn't like it. :-/ Unfortunately there
> > were several service interruptions on the mail servers for relay domains
> > which forced me to come up with some kind of solution.
> >
> >> I think this compromise is acceptable and avoids me having to know my
> >> clients' email addresses.
> >
> > Having to know and/or deal with your clients' email addresses isn't a fun
> > thing, but backscatter spam is worth trying to avoid if possible.
>
> I can think of a hybrid that might be interesting to investigate, it
> works a bit like a grey-list:
>
> You "auto learn" your client's email addresses, thus:
>
> * you accept or reject mail addresses that you have cached in a
> local database (eg. MySQL)
>
> * for new email messages not already in the database you perform
> recipient verify
>
> * if recipient verify succeeds, you add to the database a
> 'positive' record and process mail
> * if recipient verify fails (actively rejected) you add to the
> database a 'negative' record and reject the mail
> * if recipient verify fails (host unavailable) then you return
> a defer (421) to the sender
>
> * you can timestamp each email address with a "last seen" and
> expire ones over X months old
I considered something like this setup earlier, except I didn't think of
returning a defer (421) to the sender at the time. I tend to focus on black-
and-white "pass only what's good", which is why I've tended to work with a
definitive list of valid email addresses and hard rejecting anything else.
The other concern I had with the idea in general (before considering a "421"
response) was how well it would work out in combination with wildcard email
addressing.
Adding deferment, I think I like your idea and I think it would work. For
wildcard addresses there will be several entries instead of a single regex,
but that's probably okay.
The only tiny twist I see is that if an address has still been seen recently
that had previously been rejected but now would normally be accepted, that
might require manual intervention to update and mail to that address would be
rejected in the meantime. This is probably a very rare case, though. The
expiry idea is a nice addition as it gives the database some agility.
--
-- Chris
Chris Knadle
Chris.Knadle@???
