Quite a many of vger's recipients are doing return-path verification
testing for SMTP's MAIL FROM address.
I would not mind that, EXCEPT that those bloody stupid things don't
have any sane caches at all! VGER is sending 300+ messages per
day to 3500+ recipients of linux-kernel list EVERY DAY, and every
outgoing message is now getting oodles of those probes!
Folks, when you deploy that kind of testers, DO VERIFY THAT THEY
HAVE SANE CACHES! A positive result shall be cached for at least
two hours, a negative result shall be cached for at least 30 minutes.
That would send a dozen back-probes towards vger from recipient
system, instead of present 300+ !
/Matti Aarnio -- who considers some cures worse than the original problem...
On Sep 03, 2002 00:50 +0300, Matti Aarnio wrote:
> Quite a many of vger's recipients are doing return-path verification
> testing for SMTP's MAIL FROM address.
>
> I would not mind that, EXCEPT that those bloody stupid things don't
> have any sane caches at all! VGER is sending 300+ messages per
> day to 3500+ recipients of linux-kernel list EVERY DAY, and every
> outgoing message is now getting oodles of those probes!
>
> Folks, when you deploy that kind of testers, DO VERIFY THAT THEY
> HAVE SANE CACHES! A positive result shall be cached for at least
> two hours, a negative result shall be cached for at least 30 minutes.
Do you know if this is one of the default checks from spamassassin?
I would imagine that a lot of people (including myself) have it
installed, so it is possible that it (or some other widely-used tool)
now does this sort of check out-of-the-box, and the people who are
installing them have no idea about the kind of load it generates on vger.
I doubt that there are a large number of people who are independently
misconfiguring their mail setup this way
If it is possible to track what tool is causing the problem and fixing
the default setup of that tool at the source, it will probably solve
99% of the problems in one go (after the list knows to which version
they should upgrade).
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Mon, Sep 02, 2002 at 04:28:37PM -0600, Andreas Dilger wrote:
...
> > Folks, when you deploy that kind of testers, DO VERIFY THAT THEY
> > HAVE SANE CACHES! A positive result shall be cached for at least
> > two hours, a negative result shall be cached for at least 30 minutes.
>
> Do you know if this is one of the default checks from spamassassin?
No idea. I have seen these coming from Exim 4.10, Exim-something,
some sendmail milter (whatever that is), etc..
Apparently the idea (which I have thought of long ago, and rejected
as incomplete) has caught, and has multiple implementations...
> I would imagine that a lot of people (including myself) have it
> installed, so it is possible that it (or some other widely-used tool)
> now does this sort of check out-of-the-box, and the people who are
> installing them have no idea about the kind of load it generates on vger.
> I doubt that there are a large number of people who are independently
> misconfiguring their mail setup this way
I can easily reduce the load impact it causes to vger by
running the smtp server in "accept everything" mode without
analyzing local addresses for existence. With a bit more
work I can throw in local cache.. (which I probably have to do..)
> If it is possible to track what tool is causing the problem and fixing
> the default setup of that tool at the source, it will probably solve
> 99% of the problems in one go (after the list knows to which version
> they should upgrade).
Raise some noise all around, there are multiple implementations
of the idea. Some even with syntactically invalid tester codes
(spaces put in place where they don't belong in RFC 821/2821);
"works with sendmail" is NOT synonymous to "is syntactically
correct."
- a mister at blue-labs.org runs some sendmail-milter which
does testing with invalid protocol syntax
- usw-sf-list1.sourceforge.net use probably their own code
usw-sf-fw2.sourceforge.net too... possibly more systems there..
- quetz.demon.co.uk tests from Exim 4.10
- somebody.symons.net tests from Exim 3.35
Right now something like 5-7 different systems are doing it.
Try to imagine when all 3500 targets do it... BRRRRR...
(Sure, VGER can handle it, no problem, but it is that much
wasted cycles, and network traffic...)
> Cheers, Andreas
> Andreas Dilger
/Matti Aarnio
On Tue, 3 Sep 2002, Matti Aarnio wrote:
> On Mon, Sep 02, 2002 at 04:28:37PM -0600, Andreas Dilger wrote:
> ...
> > > Folks, when you deploy that kind of testers, DO VERIFY THAT THEY
> > > HAVE SANE CACHES! A positive result shall be cached for at least
> > > two hours, a negative result shall be cached for at least 30 minutes.
> >
> > Do you know if this is one of the default checks from spamassassin?
>
> No idea. I have seen these coming from Exim 4.10, Exim-something,
> some sendmail milter (whatever that is), etc..
>
> Apparently the idea (which I have thought of long ago, and rejected
> as incomplete) has caught, and has multiple implementations...
Personally i don't think this kind of tests are going to reduce the spam
that much but a simple lookup in the subscribers database might help
reducing the smtp-test traffic only for non-subscriber addresses.
- Davide
At 02:32 +0300 Matti Aarnio wrote:
>On Mon, Sep 02, 2002 at 04:28:37PM -0600, Andreas Dilger wrote:
>...
>> Do you know if this is one of the default checks from spamassassin?
>
> No idea. I have seen these coming from Exim 4.10, Exim-something,
> some sendmail milter (whatever that is), etc..
>
> Apparently the idea (which I have thought of long ago, and rejected
> as incomplete) has caught, and has multiple implementations...
I only speak (and even then not officially) for Exim's implementation,
which is "verify = sender/callout" in Exim 4. I will check to see what
caches may or may not apply. (I think Exim might not cache this, in which
case I'll try to get this caching onto the wish list.)
Anyway I think this kind of paranoia is just silly. It's trivial to forge
a valid sender address, so why bother checking anything other than a
syntactically valid domain name?
> - usw-sf-list1.sourceforge.net use probably their own code
> usw-sf-fw2.sourceforge.net too... possibly more systems there..
These may well be Exim.
> - quetz.demon.co.uk tests from Exim 4.10
> - somebody.symons.net tests from Exim 3.35
>
> Right now something like 5-7 different systems are doing it.
> Try to imagine when all 3500 targets do it... BRRRRR...
> (Sure, VGER can handle it, no problem, but it is that much
> wasted cycles, and network traffic...)
In Exim's case the network traffic will be minimal:
EHLO host.name
MAIL FROM:<>
RCPT TO:<[email protected]>
RSET
..is about as much as you'll get. The wasted cycles will be more
important.
Sorry for the noise on the list..
On Tue, Sep 03, 2002 at 02:32:30AM +0300, Matti Aarnio wrote:
> some sendmail milter (whatever that is), etc..
I don't know if this helps, but it might:
http://www.milter.org/about.shtml
-Barry K. Nathan <[email protected]>
Matt Bernstein wrote:
>
> Anyway I think this kind of paranoia is just silly. It's trivial to forge
> a valid sender address, so why bother checking anything other than a
> syntactically valid domain name?
>
Because, believe it or not, most spammers don't bother. The main server
that I maintain (_NOT_ where I receive L-K) drops at least 20 messages a
day at RCPT TO: time using this very check. Considering that's 50% of
the spam we drop at RCPT TO: time, I'd say it's worth it.
But I do agree, the systems doing the callouts should cache the results
(I'm an Exim 4.10 user as well).
[Philip Hazel bcced]
[Blue-labs postmaster bcced too]
From: Matti Aarnio <[email protected]>
> On Mon, Sep 02, 2002 at 04:28:37PM -0600, Andreas Dilger wrote:
> ...
Hi folks. Since I've been involved in code in exim, spamassassin, and was
the postmaster for sf.net, I thought I could give some info on all this.
> > > Folks, when you deploy that kind of testers, DO VERIFY THAT THEY
> > > HAVE SANE CACHES! A positive result shall be cached for at least
> > > two hours, a negative result shall be cached for at least 30 minutes.
> >
> > Do you know if this is one of the default checks from spamassassin?
There is no code in spamassassin that does SMTP callbacks and I would
advocate against it if someone were to think about adding it. Callbacks need
to be done once, at SMTP time, not later for each receipient when it's
already too late to bounce the mail if the env from is non reachable.
> No idea. I have seen these coming from Exim 4.10, Exim-something,
> some sendmail milter (whatever that is), etc..
Ok.
So, exim, has since version 3.2x (I think, might be 3.3x) something called
SMTP callbacks (now SMTP callouts).
It's an optional feature where the server does a NULL SMTP connection back
to the envelope and header sender to make sure that the servers would be
willing to accept mail back for those.
Goals are:
1) do not accept mail that you cannot bounce (i.e. limit dead mail/double
bounces in your spool)
2) make sure that mail you accept can be answered (bad header from)
3) Tell people that their envelope is broken (you can only do that by
rejecting the SMTP connection)
4) Refuse mail from morons who refuse null MAIL FROMs
5) and that's only a byproduct: refuse some junk mail/spam
If you want to know how it works in details, I've explained it here:
http://sourceforge.net/docman/display_doc.php?docid=6747&group_id=1
I think someone may eventually have written an SMTP milter to do the same
(I suggested it to Eric Allman when he talked at SVLUG last year)
> Apparently the idea (which I have thought of long ago, and rejected
> as incomplete) has caught, and has multiple implementations...
Not too many yet, and it is turned off by default on exim, however many are
turning it on (for better or for worse)
> I can easily reduce the load impact it causes to vger by
> running the smtp server in "accept everything" mode without
> analyzing local addresses for existence. With a bit more
> work I can throw in local cache.. (which I probably have to do..)
Hopefully it won't come to that.
> > If it is possible to track what tool is causing the problem and fixing
> > the default setup of that tool at the source, it will probably solve
> > 99% of the problems in one go (after the list knows to which version
> > they should upgrade).
As soon as Philip Hazel initially came up with the first implementation I
know in exim, I suggested to him that he should _really_ implement a
positive and negative cache.
Worse, if the header and envelope from are the same, the current code will
still open two SMTP connections back to check them both, even though they
are equal
Unfortunately Philip hasn't had the time to implement this yet, and others
(like me) haven't had the time to do it either and contribute code back.
> Raise some noise all around, there are multiple implementations
> of the idea. Some even with syntactically invalid tester codes
> (spaces put in place where they don't belong in RFC 821/2821);
> "works with sendmail" is NOT synonymous to "is syntactically
> correct."
I only know of the exim implementation, and I believe that one is correct.
> - a mister at blue-labs.org runs some sendmail-milter which
> does testing with invalid protocol syntax
I think I know who it is, he may have written it after he saw the code I put
on sf.net, or he may have gotten it from somewhere else, I'll let him know.
> - usw-sf-list1.sourceforge.net use probably their own code
> usw-sf-fw2.sourceforge.net too... possibly more systems there..
I don't remember the network layout, and it may have changed since I left,
but mail goes to one host which then dispatches it to sf lists or some
users.sf.net alias.
I did change the code a little bit on lists.sf.net to do an additional
postmaster callback because we got tired of having to support people who
filled our spool with crap and didn't accept Email for postmaster when we
tried to contact them and work things out.
The code uses the existing SMTP connection, so it issues an extra RCPT, but
that's very little extra load.
Note too that users.sf.net users aren't really supposed to subscribe to
mailing lists with those aliases. The users.sf.net alias is simply a
redirector you can use and advertize for your projects.
Now in practise, some sf.net users are apparently subscribing to mailing
lists anyway, but the mail server wasn't designed with that in mind.
Please note too that I am not employed by VA Software anymore, so you can
flame me, but I won't be able to do much to fix it. I know the
implementation is imperfect, I was only postmaster for sf.net on my "spare
time" since no one else was there to do it, but it was the best we could do
to handle junk mail, bad bounces, and spam send to several hundred thousand
users all running on mail server, and with no full time mail admin.
I know some things that can be done, I'll list a few here, but I never got
to upgrade to exim 4 with a callback exclude setup (doable with exim 3 too)
because I was layed off a couple of weeks before I'd have rolled out the
implementation.
To contact the sf.net team, you can submit a sf.net support request here:
https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001
If you are not satisfied, you can also contact the site director at this
address: [email protected]
> - quetz.demon.co.uk tests from Exim 4.10
> - somebody.symons.net tests from Exim 3.35
I'm surprized you're not seeing more exim users.
> Right now something like 5-7 different systems are doing it.
> Try to imagine when all 3500 targets do it... BRRRRR...
> (Sure, VGER can handle it, no problem, but it is that much
> wasted cycles, and network traffic...)
Ok, so here's my opinion on this since I studied callbacks extensively
before rolling them out on sf.net and hacking the code:
1) we've had 3 or 4 complaints in 2 years, mostly from people who didn't
like the extra lines in their mail logs
2) The SMTP callback does take a few resources, but they are rather minimal.
If you send lots of mail, you typically have the resources to handle
callbacks from remote sites.
3) Yes, it can get bad for a list server when many receipients start doing
it
What should be done about this:
1) Positive caching with a cache of at least a day, if not a week, should be
in every SMTP callback implementation
2) I'm looking at setting up a DNS list of list servers so that people don't
do callbacks on them. With exim 4, you could then query that list and not
do callbacks if the sending list server's IP is in that list.
Something can probably be done to exclude envelope from domains too.
If you are willing to help me with this, let me know
3) A 3rd, and lesser solution, is to agree on a mail header that tells
receiving servers not to do callbacks.
a) can obviously be faked by spammers, but I still think it'd work for
quite a while: spammers who are smart enough already fake valid
envelope and header froms, so they wouldn't have to add the header
b) exim can trivially add a header on outgoing mail and check for it
before doing callbacks on the receiving side, but I don't know how
trivial it is for other MTAs of sending list servers to add the
header.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger [email protected] for PGP key
Matti, it seems a more productive approach would be to make sure that
vger deliberately trips the idiot spam filters into failing. That way
people will rapidly leave the list or fix their systems.
Alan
[BTW, I didn't specify, please CC me on answers, I'm not on lk anymore]
On Tue, Sep 03, 2002 at 09:05:16AM +0200, Rogier Wolff wrote:
> > a) can obviously be faked by spammers, but I still think it'd work for
> > quite a while: spammers who are smart enough already fake valid
> > envelope and header froms, so they wouldn't have to add the header
>
> This would quickly prevent detection of the problems that you
> intended to catch: Someone will blindly add the header, and before
> you know it, they fill in a bad "sender" somewhere....
That's what I just said, if they bother to add the extra header, they could
just as well fake the envelope from to point to some yahoo account, without
needing to set the said header.
On Tue, Sep 03, 2002 at 05:27:42AM -0700, Kevin P. Fleming wrote:
> This won't work; sender verify callouts (at least in Exim) are done at
> MAIL FROM: time, I believe, in addition to after the headers have been
> delivered.
In exim 3 yes, in exim 4, you can do what I explained
(sorry, I should have been specific about which version)
Details on the exim-users list if needed.
> I think caching is the way to go, no doubt. If noone else mentions that
> they're working on it this week, I'll do so on Friday.
Caching is indeed the number 1 solution, a BL
On Tue, Sep 03, 2002 at 04:14:04PM +0100, Alan Cox wrote:
> Matti, it seems a more productive approach would be to make sure that
> vger deliberately trips the idiot spam filters into failing. That way
> people will rapidly leave the list or fix their systems.
1) exim callbacks are _not_ spam filters, they almost garantee that you only
accept mail that you can reply to and/or bounce. If your envelope from
points to foohost.domain.tld with some non routable IP, my only way to
tell you that I won't be able to send you bounces is to refuse your mail
at SMTP time.
If you send mail from a non existant account (by mistake), same thing.
SMTP callbacks just happen to also catch a lot of badly formatted spam,
but that's not their main goal
2) There aren't many ways you can cause exim callbacks to fail without
refusing real mail.
(you can look at the callback rate in your logs and block the IPs, that's
about it)
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger [email protected] for PGP key
Matti Aarnio <[email protected]> writes:
> some sendmail milter (whatever that is), etc..
mail filter. The filtering API of sendmail 8.12+. You can e.g. attach
SpamAssassin here...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Alan Cox <[email protected]> writes:
>Matti, it seems a more productive approach would be to make sure that
>vger deliberately trips the idiot spam filters into failing. That way
>people will rapidly leave the list or fix their systems.
Internet Mail Wars at eleven.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20