Matthew Byng-Maddick wrote:
> Right. In which case you can run continual relay probes, rather than every
> time they connect. And accepting the probes can be part of your AUP.
!!! Are you mad? :) We have _alot_ of IPs (I work for a large UK ISP).
I would more inclined to see this as intruding on the customer, connecting
to all your customers is something I'm not willing to contemplate.
Where as dealing with hosts *as they connect to you* seems fair, they
are using your service your checking that as part of there AUP they
are not operating Open mail relays.
> Yes. Most of the sensible databases differentiate between the types of
> open relays.
Even the popular 'brands' of blacklists would often add us and we would
either
a) have to keep continually mailing them
b) get ignored
c) get alot more volume of mail via postmaster because of 'appearing'
on these lists.
I'm all for blacklists, do not get me wrong; I'm just more intresting in
stopping our customers being used for UCE/UBE distribution (it has
recently started getting very badly out of control).
> > If the machine is sending mail to us, there is a good chance you can
> > connect back; if they are not responding the mail is 4xx'ed on
>
> That's not necessarily true.
Most certainly, but this is less traffic than going around attempting
to connect to all your customers on a regular basis.
> > the envelope RCPT TO. Any that accepts are taken as 'okay' but a valid
> > return address is used which can be then used to manually add 'additions'
> > to this database.
>
> I'd do *only* that, and completely asynchronously with respect to the SMTP
> dialogue. After all, you're not required to accept SMTP to emit it. Even
> under the Demon AUP.
I'm confused with 'you're not required to accept SMTP to emit it'.
Are you saying we have choice in either accpeting mail (and possibly
deffering via 4xx) or are you saying we should been seen to accept
all mail? I'm a bit lost (I assume you mean the former).
> > I'm not adding headers, I'm not using third party lists. I'm mainating
> > a db of people who 'Connect to me who are open relays'.
>
> I'm pointing out an example of where someone who did the tests got it
> seriously wrong. The point, as I tried to explain to sharun, in another
> post, is that there are multiple ways of relaying, and the blacklists
> you're trying to avoid will test all of them, and what you actually
> want to do is run your tests and compile your own database offline, not
> during connections.
See above for my reasoning otherwise; we have alot of traffic - if
we are adding to this connecting to all customers (and finding them
when they are online I hasten to add) to get whether they relaying
or not seems a convoluted way of finding it out soemthing that
could be done 'as it happens'.
Once a record created it cached and can be removed by manual
intervention or when a predecided 'ttl' is reached. This way we
can stop alot of the insertion of spam at the point where it
was going to be handled by us.
> > > 4) you will waste enormous amounts of bandwidth.
> > Not if the values are cached.
>
> OK. So how is your cacheing policy going to work? after all, they may have
> fixed a relay, or the boss has gone on holiday and doesn't want to change
> the laptop configuration and suddenly they're an open relay again.
A daily cached record is a value I'd probably think of; any body who
is an open relay can contact us to have this record removed once they've
proved they have fixed the open relay. If they fix it they will be able
to use it by the next day. A similar policy is already in place
for reports via abuse. Anyone who is likely to change MTA will more than
likely use it for a while before changing. This would be enough to
ensure a good enough percentage of spam is intercepted. (I'd rather
prefer not to accept any spam rather than having to deal with the mess
it creates afterwards).
> Sure. What I'm saying, though is that my mailer doesn't initially "trust"
> someone who sends it mail. It therefore issues a 450 every time they
> connect until a certain amount of time (dependent on various things) has
> elapsed since they did the first connect. Then it will pass them through
> to the real mailer.
Okay, but in practical terms I cannot afford to do this with the volume of
mail we have; as well as customers complaining about having to 'continually
having to resend my mail'. Remeber our function is a smarthost; a place
to offload mail so that you can log off and leave it to deal with it.
The only sticking point I've thought of so far is any MTA that will
accept the mail and reject later; this is rather evil, but I'm sure an
exceptions database could be maintained (and every so often these checked
also via a manual check).
> > ?? You mean it will have to verify you before it verifies itself? This
> > would be understandable. Once a host is verified the value of 'an okay'
> > box is put in the db, and future delivery is instananeous.
>
> Right. That's not what I'm saying. If I'm running my delayware, and you
> try and do your relay test to me, your relay test is completely inconclusive,
> because the delay stage happens before the relay test. So all you get is a
> 450. This doesn't help you in the slightest.
450 is something that would have to be checked; this would fall into the
'allow for now, check later' catagories.
> I would do it outside the mail dialogue.
*nods* In terms of our operations I'm convinced the best place is
within te dialogue; but as with anything SMTP related it's not something
that would be suitable for the 'internet in general'.
Regards,
D.
--
David Sloan - Senior Mail and News Systems Admin - Platform Management
Tel: +44 845 272 0666 Fax: +44 20 8371 1167 Email: dsloan@???
