Matthew Byng-Maddick wrote:
> 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 cannot see the difference save a delay of maybee upto a minute
or so the first time you send mail; we are _not_ awaiting an 'open
relay test email' to be delivered back by them; we are looking for
'obvious' cases of where a box accepts mail for a 3rd party via
SMTP dialogue at the time they are sending mail. Whether this is a
correct thing to assume will either by verified by a list of
'suspected' hosts and also by 'returned' test open relay messages.
> > 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.
So why wait 4 hours to go and check it? In that time the spam has gone
through and you are dealing with alot of underliverable mail, undeliverable
bounces, undeliverable bounces of bounces yada yada yada. When your
average queue is 1,000,000+ recipients per host and 70% of it is spam
you have to do something about it; and the earlier I stop people sending
spam the better.
> 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.
See another post I sent; I see this as the crux of your arguement.
> > > 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.
Agreed. But seeing as the mail address they have 'x@???'
MXs go via a 'relay' service (the MX records for *.demon.co.uk) and we
provide SMTP as the main delivery method (POP3 secondary), a good
percentage of our customers run MTAs. Yes not all of them will be up
at point of sending and these have to be assumed to be okay.
> And just because it isn't now, doesn't mean that when
> it does listen it won't be an open relay.
That wasn't what I was saying. I was wanting to do it at that time
because of the case of that instance of the mail you are
accepting was an earlier injected spam with thousands of
recipients ; I'd rather not take it and list the IP and check later
only to find out that the damage had already been done.
> You can't infer anything about
> whether or not it is an open relay from that. You might even trigger
> someone's firewall rules.
We have part of our AUP states that customers should trust the mail
cluster /24. ANd if a host accepts a mail for a 3rd party email address
we own; we can assume it is an open relay and verfiy this as so later.
> You could prioritise the test, but trying to do it within the dialogue
> is doomed to failure.
I don't see why, it's not foolproof and would require maintenance, but
would be a step towards eradicating 3rd party spam via our customers
and then delivering it ourselves.
> > 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?
We have an abuse team who deal with open relays on a daily basis. Added
to which as an example; Id send a mail to <dsloan@???> via your
host and it delivers it to me what more proof do you require? :)
> So if your test is undecided, then you don't accept the mail and this
> function is unfulfilled.
But for the onces we are decided upon, we stop the flow of possible spam
until they remedy their host. I'm sure it would catch alot more than
you may first credit; most of the 'open relay' test web pages do
a very similar test...
> > 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.
Older versions; later ones handle if differently from what I've been
told. BUt hence the 'verifcation' step; did the mail bounce that
we tested or actually get delivered.
> These, together make up a large proportion of the internet, and MSE will
> be a good proportion of your customers.
Our customer base is mainly windows and mac users yes. It's not
something that would be put in overnight and would also have to
proove to work; if it causes more work than it's worth then I'm not
going to use it. Hence me asking if anybody who could point me in
the right direction (had somebody done this before, or 'use this feature
to get perl to check x y and z'... etc etc) and the specifics I'd work on
myself :)
> > 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.
Yup yup. I'm not trying to be facist at the end of the day. Ones we can
block and verify as being open relays I want to catch; but not at the
expense of all the other customers or those on the 'grey fuzzy line'.
Regards,
D.
--
David Sloan - Senior Mail and News Systems Admin - Platform Management
Tel: +44 845 272 0666 Fax: +44 20 8371 1167 Email: dsloan@???
