On Wed, Dec 05, 2001 at 03:46:31PM +0000, Drav Sloan wrote:
> 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).
No. I can see from your address where you work. The point is that you can
put IPs on the test list when they connect, and you probe them
asynchronously. Mail delivery is not, and shouldn't be treated as instant
(it normally takes at least 15 minutes to get through the boxes in
question, when I last had cause to use them.)
> 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.
Well, only connect to them once they have connected.
> 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, but you can't actually do the tests you want to do while the dialogue
is going on. To try to do this is insane and stupid.
> > Yes. Most of the sensible databases differentiate between the types of
> > open relays.
What I meant is that almost all of them differentiate between input and
output relays (where output is a smarthost with an open relay behind it).
MAPS refused to add these to the RSS specifically.
> 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.
Sure.
> 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).
I agree with this.
> > > 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.
I didn't say all. But if all your customers use your mail relays, then I
don't see any difference.
> > > 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'.
I'm referring to the fact that just because they're using (E)SMTP to talk
to your mail relays doesn't mean that you can assume that that IP address
is an SMTP listener. And just because it isn't now, doesn't mean that when
it does listen it won't be an open relay. You can't infer anything about
whether or not it is an open relay from that. You might even trigger
someone's firewall rules.
> 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).
Nothing to do with your end. See above.
> 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
You could prioritise the test, but trying to do it within the dialogue
is doomed to failure.
> 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.
Reasonable.
> 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
How does the "proof" work?
> 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. I just don't really think that the way you're proposing to do it is
in any way sensible.
> 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.
So if your test is undecided, then you don't accept the mail and this
function is unfulfilled.
> 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).
qmail will always do this, I believe MSExchange does this too.
These, together make up a large proportion of the internet, and MSE will
be a good proportion of your customers.
> 450 is something that would have to be checked; this would fall into the
> 'allow for now, check later' catagories.
Yes, which is similar for the didn't connect situation.
> > 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'.
Well, you may end up timing out to do it.
Your problem.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
