Backscatter Details requested
AnswerPlus
blacklist. I've attempted to track down the issue, however our web
and email hosting is taken care of by another company and we only have
shared hosting. The best i could do to combat backscatter was to
redirect all invalid emails to a catch-all account so that our server
gives no response to ANY non-deliverable email messages. I then paid
to be removed form the list, only to find the ip back on the list 2
days later. Since the Backscatter database is by IP address, and
we're on shared hosting, it's fair to assume that there could be an
issue with any of the domains being hosted on this server (i.e. not
just my own). I've contacted my service provider but they can't find
anything leading them to the source of this problem.
I've read through many of the posts on this group and many people seem
to be upset about being listed (understandably so), but i'm just
trying to get to the bottom of this. Would it at all be possible to
obtain a sample message or mail header that would have led to the
listing of my ip address? I understand the problem and would just
like a bit of information to help me to fix it.
Many thanks,
nageeb
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
AnswerPlus
MrD
> I guess I should have specified the IP address - 24.213.67.25
Note that the only effect this listing *should* have is that bounces and
vaction auto-responses to addresses at mail-realms that use the list
might not get delivered. Normal mail should be unaffected.
>> I've contacted my service provider but they can't find anything
>> leading them to the source of this problem.
I wonder how many customers are using that machine as a mailserver. It
only takes one to get the machine listed.
--
MrD.
http://ipquery.org
DevilsPGD
<mrdem...@jackpot.invalid> was claimed to have wrote:
>AnswerPlus wrote:
>> I guess I should have specified the IP address - 24.213.67.25
>
>Note that the only effect this listing *should* have is that bounces and
>vaction auto-responses to addresses at mail-realms that use the list
>might not get delivered. Normal mail should be unaffected.
In an ideal world. Personally, I'm giving serious consideration to
scoring based on backscatter listings on the grounds that a poorly
managed server is more likely to spew then a well managed one.
I wouldn't outright block on backscatterer listings, nor would I mention
in any reject messages that backscatterer was a factor, but it does seem
like a potentially useful approach.
MrD
> In message <h7mak5$rbg$1...@news.eternal-september.org> MrD
> <mrdem...@jackpot.invalid> was claimed to have wrote:
>
>> AnswerPlus wrote:
>>> I guess I should have specified the IP address - 24.213.67.25
>> Note that the only effect this listing *should* have is that
>> bounces and vaction auto-responses to addresses at mail-realms that
>> use the list might not get delivered. Normal mail should be
>> unaffected.
>
> In an ideal world. Personally, I'm giving serious consideration to
> scoring based on backscatter listings on the grounds that a poorly
> managed server is more likely to spew then a well managed one.
As far as I've been able to tell, a hit on backscatterer is roughly
useless for distinguishing spam from good mail. So as far as my own
system goes, I would definitely not do that (at least, not until I
understand my own statistics better!)
>
> I wouldn't outright block on backscatterer listings, nor would I
> mention in any reject messages that backscatterer was a factor, but
> it does seem like a potentially useful approach.
I'd be interested to know what happens.
--
MrD.
http://ipquery.org
Rob
>>Note that the only effect this listing *should* have is that bounces and
>>vaction auto-responses to addresses at mail-realms that use the list
>>might not get delivered. Normal mail should be unaffected.
>
> In an ideal world. Personally, I'm giving serious consideration to
> scoring based on backscatter listings on the grounds that a poorly
> managed server is more likely to spew then a well managed one.
When looking at the logs in an unbiased way, it appears that a listing
on backscatterer actually should be scoring negative points for spam
blocking. I.e. a server on backscatterer is less likely to send spam
than a server not on backscatterer.
D. Stussy
news:h7p344$aj2$1...@news.eternal-september.org...
> DevilsPGD wrote:
> > In message <h7mak5$rbg$1...@news.eternal-september.org> MrD
> > <mrdem...@jackpot.invalid> was claimed to have wrote:
> >
> >> AnswerPlus wrote:
> >>> I guess I should have specified the IP address - 24.213.67.25
> >> Note that the only effect this listing *should* have is that
> >> bounces and vaction auto-responses to addresses at mail-realms that
> >> use the list might not get delivered. Normal mail should be
> >> unaffected.
> >
> > In an ideal world. Personally, I'm giving serious consideration to
> > scoring based on backscatter listings on the grounds that a poorly
> > managed server is more likely to spew then a well managed one.
>
> As far as I've been able to tell, a hit on backscatterer is roughly
> useless for distinguishing spam from good mail. So as far as my own
> system goes, I would definitely not do that (at least, not until I
> understand my own statistics better!)
I don't believe that anyone ever said it was a spam-source list. So, why
would anyone use it for such?
E-Mail Sent to this address will be added to the BlackLists
> When looking at the logs in an unbiased way, it appears
> that a listing on backscatterer actually should be
> scoring negative points for spam blocking.
> I.e. a server on backscatterer is less likely to send
> spam than a server not on backscatterer.
Lees likely to send other kinds of spam than the backscatter
flavors? (Shrug) Perhaps.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
MrD
> "MrD" <mrdem...@jackpot.invalid> wrote in message
> news:h7p344$aj2$1...@news.eternal-september.org...
>> DevilsPGD wrote:
>>> In message <h7mak5$rbg$1...@news.eternal-september.org> MrD
>>> <mrdem...@jackpot.invalid> was claimed to have wrote:
>>>
>>>> AnswerPlus wrote:
>>>>> I guess I should have specified the IP address - 24.213.67.25
>>>>>
>>>> Note that the only effect this listing *should* have is that
>>>> bounces and vaction auto-responses to addresses at mail-realms
>>>> that use the list might not get delivered. Normal mail should
>>>> be unaffected.
>>> In an ideal world. Personally, I'm giving serious consideration
>>> to scoring based on backscatter listings on the grounds that a
>>> poorly managed server is more likely to spew then a well managed
>>> one.
>> As far as I've been able to tell, a hit on backscatterer is roughly
>> useless for distinguishing spam from good mail. So as far as my
>> own system goes, I would definitely not do that (at least, not
>> until I understand my own statistics better!)
>
> I don't believe that anyone ever said it was a spam-source list. So,
> why would anyone use it for such?
>
>
exactly that way, and to whom I was replying).
--
MrD.
http://ipquery.org
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>DevilsPGD <Death...@crazyhat.net> wrote:
>>>Note that the only effect this listing *should* have is that bounces and
>>>vaction auto-responses to addresses at mail-realms that use the list
>>>might not get delivered. Normal mail should be unaffected.
>>
>> In an ideal world. Personally, I'm giving serious consideration to
>> scoring based on backscatter listings on the grounds that a poorly
>> managed server is more likely to spew then a well managed one.
>
>When looking at the logs in an unbiased way, it appears that a listing
>on backscatterer actually should be scoring negative points for spam
>blocking. I.e. a server on backscatterer is less likely to send spam
>than a server not on backscatterer.
My suspicion is that backscatter listings will almost never be zombies,
they'll generally be real mail servers, so they'll be more likely to
send good mail then bad mail vs every other IP address.
I'm more interested in knowing if backscatterer listings are more or
less likely to spew spam then other known-to-be-mail-server IPs. My
guess is that someone who is backscatterering is less likely to have
outbound filtering or rate limiting of their own, is less likely to
require strong passwords, and is less likely to notice spamruns from
compromised credentials.
When it comes to scoring, I'm all about looking at data in an unbiased
fashion, and I'm entirely willing to apply a negative score if that's
how things work out. I focus more on identifying and delivering good
mail, the more legitimate mail I can pull out first the less false
positive risk.
I should also note that I offer BATV to my customers, so backscatter is
a nonissue (unless a user turns BATV off) backscatterer listing or not.
DevilsPGD
<sp...@bde-arc.ampr.org> was claimed to have wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:h7p344$aj2$1...@news.eternal-september.org...
>> DevilsPGD wrote:
>> > In message <h7mak5$rbg$1...@news.eternal-september.org> MrD
>> > <mrdem...@jackpot.invalid> was claimed to have wrote:
>> >
>> >> AnswerPlus wrote:
>> >>> I guess I should have specified the IP address - 24.213.67.25
>> >> Note that the only effect this listing *should* have is that
>> >> bounces and vaction auto-responses to addresses at mail-realms that
>> >> use the list might not get delivered. Normal mail should be
>> >> unaffected.
>> >
>> > In an ideal world. Personally, I'm giving serious consideration to
>> > scoring based on backscatter listings on the grounds that a poorly
>> > managed server is more likely to spew then a well managed one.
>>
>> As far as I've been able to tell, a hit on backscatterer is roughly
>> useless for distinguishing spam from good mail. So as far as my own
>> system goes, I would definitely not do that (at least, not until I
>> understand my own statistics better!)
>
>I don't believe that anyone ever said it was a spam-source list. So, why
>would anyone use it for such?
I'm not using it as a spam-source list, I'm thinking about using it as a
poorly-run-mailserver list.
In other words, I won't be blocking outright, but I might be treating
their mail with more suspicion.
Rob
> In message <slrnh9vqgm...@xs7.xs4all.nl> Rob
> <nom...@example.com> was claimed to have wrote:
>
>>DevilsPGD <Death...@crazyhat.net> wrote:
>>>>Note that the only effect this listing *should* have is that bounces and
>>>>vaction auto-responses to addresses at mail-realms that use the list
>>>>might not get delivered. Normal mail should be unaffected.
>>>
>>> In an ideal world. Personally, I'm giving serious consideration to
>>> scoring based on backscatter listings on the grounds that a poorly
>>> managed server is more likely to spew then a well managed one.
>>
>>When looking at the logs in an unbiased way, it appears that a listing
>>on backscatterer actually should be scoring negative points for spam
>>blocking. I.e. a server on backscatterer is less likely to send spam
>>than a server not on backscatterer.
>
> My suspicion is that backscatter listings will almost never be zombies,
> they'll generally be real mail servers, so they'll be more likely to
> send good mail then bad mail vs every other IP address.
I have written this before on this newsgroup.
It was ridiculed.
But I still think it is true.
> I'm more interested in knowing if backscatterer listings are more or
> less likely to spew spam then other known-to-be-mail-server IPs. My
> guess is that someone who is backscatterering is less likely to have
> outbound filtering or rate limiting of their own, is less likely to
> require strong passwords, and is less likely to notice spamruns from
> compromised credentials.
This is unwarranted.
The servers of my ISP have all those kinds of antispam measures but
still they are on backscatterer.org
Like many ISP mailservers in this country.
Usually the providers offer features like mailforwarding, autoreply,
maildelivery by SMTP, etc. This means they will always have at least
one misdirected DSN per month, and are always listed. Whatever they do
to avoid it. They probably don't want to spend the (unreasonable)
effort to get rid of all the possible mishaps just to get off the list
of a single group of fanatics.
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>DevilsPGD <Death...@crazyhat.net> wrote:
>> In message <slrnh9vqgm...@xs7.xs4all.nl> Rob
>> <nom...@example.com> was claimed to have wrote:
>>
>>>DevilsPGD <Death...@crazyhat.net> wrote:
>>>>>Note that the only effect this listing *should* have is that bounces and
>>>>>vaction auto-responses to addresses at mail-realms that use the list
>>>>>might not get delivered. Normal mail should be unaffected.
>>>>
>>>> In an ideal world. Personally, I'm giving serious consideration to
>>>> scoring based on backscatter listings on the grounds that a poorly
>>>> managed server is more likely to spew then a well managed one.
>>>
>>>When looking at the logs in an unbiased way, it appears that a listing
>>>on backscatterer actually should be scoring negative points for spam
>>>blocking. I.e. a server on backscatterer is less likely to send spam
>>>than a server not on backscatterer.
>>
>> My suspicion is that backscatter listings will almost never be zombies,
>> they'll generally be real mail servers, so they'll be more likely to
>> send good mail then bad mail vs every other IP address.
>
>I have written this before on this newsgroup.
>It was ridiculed.
>But I still think it is true.
It makes a lot of sense. However, if you run against PBL/DULs/etc first
and exclude those hits, this may reduce backscatterer's effectiveness as
a list of likely-to-be-legitimate mail servers.
It's also worth considering that spammers do use null return paths for
junk at least some percentage of the time, so zombies may well end up on
backscatter lists unless care is taken to filter out non-DSN types of
null-return-path mail.
>> I'm more interested in knowing if backscatterer listings are more or
>> less likely to spew spam then other known-to-be-mail-server IPs. My
>> guess is that someone who is backscatterering is less likely to have
>> outbound filtering or rate limiting of their own, is less likely to
>> require strong passwords, and is less likely to notice spamruns from
>> compromised credentials.
>
>This is unwarranted.
>The servers of my ISP have all those kinds of antispam measures but
>still they are on backscatterer.org
>Like many ISP mailservers in this country.
>
>Usually the providers offer features like mailforwarding, autoreply,
>maildelivery by SMTP, etc. This means they will always have at least
>one misdirected DSN per month, and are always listed. Whatever they do
>to avoid it. They probably don't want to spend the (unreasonable)
>effort to get rid of all the possible mishaps just to get off the list
>of a single group of fanatics.
I offer all of those to my users without sending anything that would get
me a backscatterer listing.
Auto-responders are the weakest link, but by applying fairly strict spam
filters before allowing autoresponders out I'm pretty comfortable in
saying that I spew very little junk to innocents, if any.
There is plenty of mail that I'm willing to deliver that wouldn't
generate an autoresponder, SPF softfail, DK/DKIM signature fails (even
without ADSP), slightly spammy "stuff", rDNS failures, dynamic senders,
etc.
Beyond autoresponders, I don't send automatic responses to
unauthenticated senders for mail-forwarding failures, or outbound
delivery failures, or any of the other common ways of getting listed.
E-Mail Sent to this address will be added to the BlackLists
> Usually the providers offer features like mailforwarding,
> autoreply, maildelivery by SMTP, etc.
> This means they will always have at least one misdirected
> DSN per month, and are always listed.
> Whatever they do to avoid it.
> They probably don't want to spend the (unreasonable)
> effort to get rid of all the possible mishaps just to get
> off the list of a single group of fanatics.
I don't buy that.
"one misdirected DSN per month"
... and that one just happens to hit a spam trap?
Rather more likely, if you have one DSN per month hitting
a spam trap, you are sending a thousand "misdirected DSN
per month".
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
--
Shmuel (Seymour J.) Metz
09/01/2009
at 11:54 PM, AnswerPlus <aplu...@gmail.com> said:
>Recently my company have found ourselves on the Backscatter
>blacklist. I've attempted to track down the issue, however our web and
>email hosting is taken care of by another company and we only have shared
>hosting.
In that case you can only solve your problem by either getting your
provider to act or by changing providers.
>Would it at all be possible to obtain a sample message or mail
>header that would have led to the listing of my ip address?
I'm not sure whether UCEPROTECT can give you those data without
compromising their spam traps. Have you received any complaints about
misdirected bounces? Has your service provider?If so, perhaps one of the
recipients would be willing to provide headers.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
Shmuel (Seymour J.) Metz
09/02/2009
at 04:07 PM, AnswerPlus <aplu...@gmail.com> said:
>I guess I should have specified the IP address - 24.213.67.25
So your provider is Mountain Cablevision LTD.?
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
D. Stussy
<Nu...@BlackList.Griffin-Technologies.invalid> wrote in message
news:h84f1r$94v$1...@news.eternal-september.org...
> Rob wrote:
> > Usually the providers offer features like mailforwarding,
> > autoreply, maildelivery by SMTP, etc.
> > This means they will always have at least one misdirected
> > DSN per month, and are always listed.
> > Whatever they do to avoid it.
> > They probably don't want to spend the (unreasonable)
> > effort to get rid of all the possible mishaps just to get
> > off the list of a single group of fanatics.
>
> I don't buy that.
>
> "one misdirected DSN per month"
>
> ... and that one just happens to hit a spam trap?
>
>
> Rather more likely, if you have one DSN per month hitting
> a spam trap, you are sending a thousand "misdirected DSN
> per month".
Why should any DSN (or NDR) hit a spamtrap mailbox?
If that mailbox is not used for sending messages EVER, then there will
never be any DSNs generated to hit it.
If the mailbox is used for sending only by spammers, then the only way an
NDR from a PROPERLY behaving recipient MTA will hit that mailbox is if it's
UNPROTECTED by the forgery detection methods. However, as the spamtrap
mailbox is unprotected, that means ANYONE may use it as a sender identity,
which means that messages ARE sent using it - and are AUTHORIZED to be
sent. (If they weren't authorized, then the forgery detection methods
would be used to tell the recipient such, and the properly behaving
recipient would have rejected the forgeries before even considering the
generation of an NDR.)
Conclusion: Spamtrap mailboxes, in order to fulfill their function as
spamtraps, MUST BE PROTECTED by forgery detection methods (SPF and/or DK).
Recipient systems, to be considered as properly behaving, MUST CHECK for
forgeries and reject them during SMTP or discard them after acceptance
(rejection is more efficient).
Rob
> Auto-responders are the weakest link, but by applying fairly strict spam
> filters before allowing autoresponders out I'm pretty comfortable in
> saying that I spew very little junk to innocents, if any.
Irrelevant. There is no such thing as "nearly not listed on
backscatterer.org". It does not provide a rating figure. You are either
listed or not listed. When you handle a lot of mail, every tiny little
mistake will get you listed, and there is no such thing as a nearly
perfect solution. Only a perfect solution counts in the world of
backscatterer.org.
As this is usually not achievable, one can just as well ingnore the whole
issue and be listed anyway.
Shmuel (Seymour J.) Metz
at 03:46 AM, DevilsPGD <Death...@crazyhat.net> said:
>I'm more interested in knowing if backscatterer listings are more or less
>likely to spew spam then other known-to-be-mail-server IPs.
Well, the backscater is spam, for starters.
>When it comes to scoring,
What matters is the traffic coming into *your* network. There is no one
size fits all.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Fred Mobach
> As this is usually not achievable, one can just as well ingnore the
> whole issue and be listed anyway.
That's correct, as backscatterer.org should only be used to block
bounces. If backscatterer.org is used in this way it wouldn't hurt
anyone.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Rob
> Rob wrote:
>
>> As this is usually not achievable, one can just as well ingnore the
>> whole issue and be listed anyway.
>
> That's correct, as backscatterer.org should only be used to block
> bounces. If backscatterer.org is used in this way it wouldn't hurt
> anyone.
The problem is that the service is misunderstood and applied in the
wrong way. This then leads to lots of people trying to get delisted.
When the service was used correctly, nobody would care to get delisted.
Fred Mobach
> Fred Mobach <fr...@mobach.nl> wrote:
>> Rob wrote:
>>
>>> As this is usually not achievable, one can just as well ingnore the
>>> whole issue and be listed anyway.
>>
>> That's correct, as backscatterer.org should only be used to block
>> bounces. If backscatterer.org is used in this way it wouldn't hurt
>> anyone.
>
> The problem is that the service is misunderstood and applied in the
> wrong way. This then leads to lots of people trying to get delisted.
>
> When the service was used correctly, nobody would care to get
> delisted.
Which is strange, as it is clearly stated on the Usage page
(http://www.backscatterer.org/index.php?target=usage) :
"As long as you are not a BOFH nor having the intention to boycott such
servers we strongly recommend to use ips.backscatterer.org in SAFE MODE
to prevent false positives.
SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or
postmaster only."
Me starts questioning the BOFH status of those asking for expedited
delisting. Assumes they even might be unaware of what that is. ;-)
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
Shmuel (Seymour J.) Metz
at 02:23 PM, Rob <nom...@example.com> said:
>The problem is that the service is misunderstood and applied in the wrong
>way.
No; it's up to the admin to determine what works best for him.
>When the service was used correctly, nobody would care to get delisted.
If mail servers were configured properly, nobody would be listed.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
E-Mail Sent to this address will be added to the BlackLists
> Fred Mobach <fr...@mobach.nl> wrote:
>> Rob wrote:
>>> As this is usually not achievable, one can just as well
>>> ingnore the whole issue and be listed anyway.
>>
>> That's correct, as backscatterer.org should only be used
>> to block bounces.
>> If backscatterer.org is used in this way it wouldn't hurt
>> anyone.
>
> The problem is that the service is misunderstood and
> applied in the wrong way.
> This then leads to lots of people trying to get delisted.
>
> When the service was used correctly, nobody would care to
> get delisted.
That is correct.
The same is true of Country Code DNSbls, RIR DNSbls, ASN DNSbls,
ISP DNSbls, DNSwls, Testing DNSbls, ....
DNSbl queries, and what is done with the responses,
implemented not as intended by the DNSbl,
get results not as the DNSbl intended.
Not all DNS lists are about Spammer's IP addresses.
{In fact probably most are not specifically about a Spammer's IP.}
{At least dozens, if not hundred of different listing reasons.}
Some list Open Relays, Open Proxies, Trojaned PCs,
Dynamic IPs, ...
Some list by ISP
verizon.blackholes.us, ...
Some list by AS
AS26294.rbl.cluecentral.net
AS19262.rbl.cluecentral.net
AS7021.rbl.cluecentral.net
...
Some list by Country
us.rbl.cluecentral.net
us.countries.nerd.dk
zz.countries.nerd.dk
...
Some list by by Region
lacnic.spamblocked.com
...
some list misconfigured DNS
bogons.dnsiplists.completewhois.com
dsn.rfc-ignorant.org
bogusmx.rfc-ignorant.org
badconf.rhsbl.sorbs.net
bogons.cymru.com
some list misconfigured whois
invalidipwhois.dnsiplists.completewhois.com
whois.rfc-ignorant.org
abuse.rfc-ignorant.org
postmaster.rfc-ignorant.org
bl.deadbeef.com
some list hijacked IPs / ASs
hijacked.dnsiplists.completewhois.com
zombie.dnsbl.sorbs.net
some list people who don't want to be tested by the
list maintainers, block.dnsbl.sorbs.net
some list as requested by their owners, as never to be used to send mail
nomail.rhsbl.sorbs.net
some are WhiteLists (or pretend to be)
hul.habeas.com
query.bondedsender.org
whitelist.spamblocked.com
whitelist.sci.kun.nl
exemptions.ahbl.org
accept.the-carrot-and-the-stick.com
trust.trustmymail.org
spf.trusted-forwarder.org
some list all IPv4 (0.0.0.0 - 255.255.255.255)
nofalsenegatives.stopspam.samspade.org
blocked.secnap.net
ipv4.fahq2.com FAHQ2
some list none of IPv4
nofalsepositive.stopspam.samspade.org
some list Random IPs
random.bl.gweep.ca
Information is just information, you should always consider
the source, and make your own decisions.
There may be as many reason as there are lists?
{Yes many have similar listing reasons, however between all
the SubAggregateZones / ReturnCodes there are a lot
of different flavors.}
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
D. Stussy
message news:4aaa9dc3$2$fuzhry+tra$mr2...@news.patriot.net...
> In <slrnhajurq...@xs7.xs4all.nl>, on 09/11/2009
> at 02:23 PM, Rob <nom...@example.com> said:
>
> >The problem is that the service is misunderstood and applied in the
wrong
> >way.
>
> No; it's up to the admin to determine what works best for him.
>
> >When the service was used correctly, nobody would care to get delisted.
>
> If mail servers were configured properly, nobody would be listed.
WRONG! Properly configured mail servers can still get listed. That's the
problem with the list.
Rob
>> When the service was used correctly, nobody would care to get
>> delisted.
>
> Which is strange, as it is clearly stated on the Usage page
> (http://www.backscatterer.org/index.php?target=usage) :
> "As long as you are not a BOFH nor having the intention to boycott such
> servers we strongly recommend to use ips.backscatterer.org in SAFE MODE
> to prevent false positives.
> SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or
> postmaster only."
I think this may be because of two things:
1. it coins a self-invented term, "SAFE MODE", which probably is not
understood by many readers and is not presented as an option in the
software they use.
2. backscatterer probably ended up on some lists of blocklists that
are applied by newbie administrators, without even visiting the
webpage where the list is explained. the admin assumes the
blocklist is about blocking spam without even checking.
> Me starts questioning the BOFH status of those asking for expedited
> delisting. Assumes they even might be unaware of what that is. ;-)
Please note that the admin of the mailserver using the backscatterer.org
list for (incorrectly) blocking spam and the admin trying to get delisted
are two different people. So the BOFH that is wrongly using backscatterer
is not the person asking for delisting.
I'm surprised that this "mistake" is so often made. Especially some of
the regulars here on the newsgroup (which are almost all in my killfile
by now) play the same record again and again: when you don't like the
blocklist then don't use it. But they completely ignore the fact that
the user of the blacklist and the one complaining about it are not the
same person.
Or in fact, I think they are well aware of this and just like to stir
things up a bit by posting those witty comments. That is why I choose
to ignore them. Same thing about playing word-games instead of discussing
the actual matter, thus discriminating people that are not native English
speakers.
MrD
> "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid>
> wrote in message
> news:4aaa9dc3$2$fuzhry+tra$mr2...@news.patriot.net...
>> In <slrnhajurq...@xs7.xs4all.nl>, on 09/11/2009 at 02:23
>> PM, Rob <nom...@example.com> said:
>>
>>> The problem is that the service is misunderstood and applied in
>>> the
> wrong
>>> way.
>> No; it's up to the admin to determine what works best for him.
>>
>>> When the service was used correctly, nobody would care to get
>>> delisted.
>> If mail servers were configured properly, nobody would be listed.
>
> WRONG! Properly configured mail servers can still get listed.
FSVO "properly".
> That's the problem with the list.
I guess that means that lists that list all of Korea share the same problem.
The list lists what it says it lists; as long as that remains true, any
problems that people have with it aren't problems with the list, but
problems with someone's configuration.
--
MrD.
http://ipquery.org
MrD
>
> I'm surprised that this "mistake" is so often made. Especially some
> of the regulars here on the newsgroup (which are almost all in my
> killfile by now) play the same record again and again: when you don't
> like the blocklist then don't use it. But they completely ignore the
> fact that the user of the blacklist and the one complaining about it
> are not the same person.
If they aren't the same person, then the person complaining has no
standing to complain *about the list*. He should direct his complaint to
the user of the list. And good luck to him.
> Or in fact, I think they are well aware of this and just like to stir
> things up a bit by posting those witty comments. That is why I
> choose to ignore them. Same thing about playing word-games instead
> of discussing the actual matter, thus discriminating people that are
> not native English speakers.
Is Stussy a non-native speaker? I hadn't realised. That might explain
his bizarre English usage.
--
MrD.
http://ipquery.org
Claus v. Wolfhausen
> WRONG! Properly configured mail servers can still get listed. That's the
> problem with the list.
We (tinw) know that you have a problem to see the reality as it is in real.
If a server gets listed that is proof for it is NOT properly configured.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
Martijn Lievaart
> D. Stussy wrote:
>
>> WRONG! Properly configured mail servers can still get listed. That's
>> the problem with the list.
>
> We (tinw) know that you have a problem to see the reality as it is in
> real.
>
> If a server gets listed that is proof for it is NOT properly configured.
The only way not to get listed is to turn of NDRs completely, or always
5xx even if delivery to some recipients failed while others succeeded in
the data phase. With current SMTP NDRs are unavoidable, even if they can
(and MUST) be minimized in occurrence.
I currently believe all NDRs can be avoided (at the cost of dropping some
mail in very rare situations, except when delivery fails to some of
multiple recipients. Obviously, you could suppress NDRs in that
situation, but I believe the usefulness of those NDRs outweighs the
backscatter problem it creates (which is tiny in the total backscatter
spectrum we see).
So no, a server that is properly configured may still get listed. It
should be quite rare, but it can occur.
And, obviously, most mail server software do not allow the amount of
tweaking (at least not without a considerable amount of customizing) that
is needed to suppress backscatter in more common situations, but that can
and must be solved.
M4
Fred Mobach
> D. Stussy wrote:
>
>> WRONG! Properly configured mail servers can still get listed.
>> That's the problem with the list.
>
> We (tinw) know that you have a problem to see the reality as it is in
> real.
>
> If a server gets listed that is proof for it is NOT properly
> configured.
Or a server behind the listed server is not properly configured.
Experienced that when an already warned customer decided it was better
to turn off "allow non delivery reports" because he was relisted in
backscatterer.org. :-)
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
D. Stussy
> D. Stussy wrote:
> > "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid>
> > wrote in message
> > news:4aaa9dc3$2$fuzhry+tra$mr2...@news.patriot.net...
> >> In <slrnhajurq...@xs7.xs4all.nl>, on 09/11/2009 at 02:23
> >> PM, Rob <nom...@example.com> said:
> >>
> >>> The problem is that the service is misunderstood and applied in
> >>> the
> > wrong
> >>> way.
> >> No; it's up to the admin to determine what works best for him.
> >>
> >>> When the service was used correctly, nobody would care to get
> >>> delisted.
> >> If mail servers were configured properly, nobody would be listed.
> >
> > WRONG! Properly configured mail servers can still get listed.
>
> FSVO "properly".
>
> > That's the problem with the list.
>
> I guess that means that lists that list all of Korea share the same
problem.
Those lists don't claim to list only backscatterers.
> The list lists what it says it lists; as long as that remains true, any
> problems that people have with it aren't problems with the list, but
> problems with someone's configuration.
As previously demonstrated, the list can list MORE than what it says it
lists. I do agree that there won't be any false negatives according to the
analysis of its rules. Unfortunately, the stated rules are incomplete and
thus open to false positive listings when comparing the rules against their
goal.
Shmuel (Seymour J.) Metz
at 04:18 PM, Rob <nom...@example.com> said:
>play the same record again and again
PKB.
>Please note that the admin of the mailserver using the backscatterer.org
>list for (incorrectly) blocking spam and the admin trying to get
>delisted are two different people.
He didn't claim otherwise. ICBW, but he seemed to be referring to admins
who requested express delisting without first fixing their servers. Don't
confuse his statement with the text he quoted.
>thus discriminating people that are not native English speakers.
Some of the people disagreeing with you are not native Anglophones. Your
problem is not your English.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Seth
Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>The only way not to get listed is to turn of NDRs completely, or always
>5xx even if delivery to some recipients failed while others succeeded in
>the data phase.
Why not 4xx, and use some cleverness on the retry? (E.g. accept for
those users where delivery succeeded, but don't redeliver; then 5xx
the failures, or even try again and 4xx if any succeeds.)
> With current SMTP NDRs are unavoidable, even if they can
>(and MUST) be minimized in occurrence.
They can also be avoided.
>I currently believe all NDRs can be avoided (at the cost of dropping some
>mail in very rare situations, except when delivery fails to some of
>multiple recipients. Obviously, you could suppress NDRs in that
>situation, but I believe the usefulness of those NDRs outweighs the
>backscatter problem it creates (which is tiny in the total backscatter
>spectrum we see).
That case can also be avoided.
>So no, a server that is properly configured may still get listed. It
>should be quite rare, but it can occur.
Not for _my_ value of "properly configured".
>And, obviously, most mail server software do not allow the amount of
>tweaking (at least not without a considerable amount of customizing) that
>is needed to suppress backscatter in more common situations, but that can
>and must be solved.
That's a smop.
Seth
D. Stussy
message news:h8kopa$316$1...@ulm.shuttle.de...
> D. Stussy wrote:
>
> > WRONG! Properly configured mail servers can still get listed. That's
the
> > problem with the list.
>
> We (tinw) know that you have a problem to see the reality as it is in
real.
>
> If a server gets listed that is proof for it is NOT properly configured.
Only in your mind.
A server is properly configured if it follows all RFCs and standards in
place at the time. These standards currently include situations where
REQUIRED NDRs are sent off-host to non-forged senders of an original
message. However, your listing criteria FAILS to account that such NDRs
are legitimate (as STD 10 says), thus resulting in false positive listings
as these servers are NOT misbehaving.
Compliance with the published standards of the Internet is not
misbehavior that is cause for listing anyone on any blacklist.
You have two choices to eliminate the potential of false positives:
1) Publish your own RFC to get the standards changed so that off-host NDRs
are forbidden.
2) Add to your listing criteria that you will only accept backscatterer
referrals from mailboxes protected by forgery detection methods (currently
SPF and/or DK/DKIM), and follow through by implementing such.
Either of those steps will fix the DEFECT in your listing requirements as
compared to the goal you claim they enforce. Otherwise, your list remains
open to false positives as noted and therefore, it is disingenuous.
I have told you the problem with your criteria. I have told you the
solution, too. Why won't you implement the solution? It's easy....
D. Stussy
news:4aaf69c8$0$283$1472...@news.sunsite.dk...
> Or a server behind the listed server is not properly configured.
Thus a false positive - as it's listing the WRONG "misbehaving" server.
"Martijn Lievaart" <m...@rtij.nl.invlalid> wrote in message
news:50i2o6-...@news.rtij.nl...
> So no, a server that is properly configured may still get listed. It
> should be quite rare, but it can occur.
Again, a false positive listing - misidentifying its [mis-]behavior.
> The only way not to get listed is to turn of NDRs completely,
Whch is CONTRARY to STD 10 which acknowledges (even in RFC 5321) that there
are some NDRs that MUST be sent.
> I currently believe all NDRs can be avoided (at the cost of dropping some
> mail in very rare situations, [sic, parenthetical not closed] ...
I do disagree with this - as demonstrated by the race condition regarding a
"mailbox full" condition where at least one of the delivering messages will
fit but not all. A mailbox full NDR returned to a non-forged sender in
response to non-spam/virusmail is a required NDR that must be sent and
cannot be avoided. Dropping is clearly inappropriate.
> ... With current SMTP NDRs are unavoidable, even if they can
> (and MUST) be minimized in occurrence.
I do agree with this statement, and have already stated such - by
performing all possible checks during SMTP (before message acceptance).
However, zero NDRs cannot be guarenteed.
As noted in another reply, a change in either STD 10 (via the RFC process)
or a correction in the listing criteria of the backscatterer list are the
only two ways the false positive problem will be resolved.
Martijn Lievaart
>> I currently believe all NDRs can be avoided (at the cost of dropping
>> some mail in very rare situations, [sic, parenthetical not closed] ...
>
> I do disagree with this - as demonstrated by the race condition
> regarding a "mailbox full" condition where at least one of the
> delivering messages will fit but not all. A mailbox full NDR returned
> to a non-forged sender in response to non-spam/virusmail is a required
> NDR that must be sent and cannot be avoided. Dropping is clearly
> inappropriate.
I already showed in another posting that your race condition is very
easily solved. In fact I would say that your mailserver is misconfigured
if it allows this race condition.
M4
Fred Mobach
> "Fred Mobach" <fr...@mobach.nl> wrote in message
> news:4aaf69c8$0$283$1472...@news.sunsite.dk...
>> Or a server behind the listed server is not properly configured.
>
> Thus a false positive - as it's listing the WRONG "misbehaving"
> server.
In the case I noticed the listed server had a public IP adress, the
server behind it a private IP address. Seen from backscatterer.org it
listed the _correct_ server which had sent the backscatter to the
internet.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
--
MrD
> "MrD" <mrdem...@jackpot.invalid> wrote in message
> news:h8jd36$j3b$1...@news.eternal-september.org...
>> D. Stussy wrote:
>>> "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid>
>>> wrote in message
>>> news:4aaa9dc3$2$fuzhry+tra$mr2...@news.patriot.net...
>>>> In <slrnhajurq...@xs7.xs4all.nl>, on 09/11/2009 at
>>>> 02:23 PM, Rob <nom...@example.com> said:
>>>>
>>>>> The problem is that the service is misunderstood and applied
>>>>> in the
>>> wrong
>>>>> way.
>>>> No; it's up to the admin to determine what works best for him.
>>>>
>>>>> When the service was used correctly, nobody would care to get
>>>>> delisted.
>>>> If mail servers were configured properly, nobody would be
>>>> listed.
>>> WRONG! Properly configured mail servers can still get listed.
>> FSVO "properly".
>>
>>> That's the problem with the list.
>> I guess that means that lists that list all of Korea share the same
>>
> problem.
>
> Those lists don't claim to list only backscatterers.
They list what they say they list. Backscatterer says it lists machines
that send from <> to a spamtrap.
> As previously demonstrated, the list can list MORE than what it says
> it lists. I do agree that there won't be any false negatives
> according to the analysis of its rules.
You mean "according to their published listing criteria", I guess.
Unfortunately, the stated rules are incomplete
In your opinion. What it comes down to is that you think the list should
have different policies from what the list-ops think.
You're entitled to an opinion. But you're unlikely to change the views
of the list-ops, even after banging on about it for a month.
> and thus open to false positive listings when comparing the rules
> against their goal.
That's "their goal" as re-interpreted for them by you.
--
MrD.
http://ipquery.org
Martijn Lievaart
> In article <50i2o6-...@news.rtij.nl>, Martijn Lievaart
> <m...@rtij.nl.invlalid> wrote:
>
>>The only way not to get listed is to turn of NDRs completely, or always
>>5xx even if delivery to some recipients failed while others succeeded in
>>the data phase.
>
> Why not 4xx, and use some cleverness on the retry? (E.g. accept for
> those users where delivery succeeded, but don't redeliver; then 5xx the
> failures, or even try again and 4xx if any succeeds.)
Clever! However then _all_ senders will get the NDR (from their own mail
server, so a wanted one) and in the case of a permanent failure probably
some warnings about delayed delivery as well. So although it will work,
it is not a solution that will sit well with customers.
>> With current SMTP NDRs are unavoidable, even if they can
>>(and MUST) be minimized in occurrence.
>
> They can also be avoided.
I was refering to the case above, so I son;t understand your also.
(snip)
>>And, obviously, most mail server software do not allow the amount of
>>tweaking (at least not without a considerable amount of customizing)
>>that is needed to suppress backscatter in more common situations, but
>>that can and must be solved.
>
> That's a smop.
Ah, yes, but most mailadmins are not programmers. I am, so I did create
the appropriate modules for Courier, but this is beyond 99% of mail
admins and beyond 95% of organisations. Of course they could do it, but
it would be much better if mail server software was more mature on this
point.
M4
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"Claus v. Wolfhausen" <use-reply-...@remove-this.com> wrote in
>message news:h8kopa$316$1...@ulm.shuttle.de...
>> D. Stussy wrote:
>>
>> > WRONG! Properly configured mail servers can still get listed. That's
>the
>> > problem with the list.
>>
>> We (tinw) know that you have a problem to see the reality as it is in
>real.
>>
>> If a server gets listed that is proof for it is NOT properly configured.
>
>Only in your mind.
Somebody who long-short wraps quoted lines the way you do is clearly
not an expert on properly configuring.
backscatterer.org has a lot more users than your DNSBL. Apparently,
many admins think it's more useful than yours.
>A server is properly configured if it follows all RFCs and standards in
>place at the time. These standards currently include situations where
>REQUIRED NDRs are sent off-host to non-forged senders of an original
>message.
Which is irrelevant to backscatterer.org, because it lists only for
responses to *forged* messages.
> However, your listing criteria FAILS to account that such NDRs
>are legitimate (as STD 10 says), thus resulting in false positive listings
>as these servers are NOT misbehaving.
You just keeps attempting to redefine "forged" in a way that you can't
support by appeals to a dictionary, RFC, logic, or general usage.
That makes your definition non-standard and non-useful.
> Compliance with the published standards of the Internet is not
>misbehavior that is cause for listing anyone on any blacklist.
Compliance with wrong definitions is not required behavior.
>You have two choices to eliminate the potential of false positives:
>
>1) Publish your own RFC to get the standards changed so that off-host NDRs
>are forbidden.
>
>2) Add to your listing criteria
So you admit that they currently list according to their listing
criteria. Therefore, by definition, there are no incorrect entries.
>Either of those steps will fix the DEFECT in your listing requirements as
>compared to the goal you claim they enforce.
They meet their goal quite accurately. They do not meet what _you_
want _their_ goal to be, and they have no desire to meet what you want
their goal to be.
> Otherwise, your list remains
>open to false positives as noted and therefore, it is disingenuous.
Yet you have never given any example of such.
>I have told you the problem with your criteria.
They don't consider it a problem, and neither do their *users*. Why
should they make their list less useful to the *users* of their list
merely in order to comply with your incorrect definition?
> I have told you the
>solution, too. Why won't you implement the solution? It's easy....
Why should they go to any effort that will at best result in their
list being less useful to them and to their users?
Seth
DevilsPGD
<sp...@bde-arc.ampr.org> was claimed to have wrote:
>I do disagree with this - as demonstrated by the race condition regarding a
>"mailbox full" condition where at least one of the delivering messages will
>fit but not all. A mailbox full NDR returned to a non-forged sender in
>response to non-spam/virusmail is a required NDR that must be sent and
>cannot be avoided. Dropping is clearly inappropriate.
This one is still the easiest of all to fix, enforce quotas at the
SMTP-inbound phase rather then on the filesystem.
Rob
> In message <h8pf26$4te$1...@snarked.org> "D. Stussy"
> <sp...@bde-arc.ampr.org> was claimed to have wrote:
>
>>I do disagree with this - as demonstrated by the race condition regarding a
>>"mailbox full" condition where at least one of the delivering messages will
>>fit but not all. A mailbox full NDR returned to a non-forged sender in
>>response to non-spam/virusmail is a required NDR that must be sent and
>>cannot be avoided. Dropping is clearly inappropriate.
>
> This one is still the easiest of all to fix, enforce quotas at the
> SMTP-inbound phase rather then on the filesystem.
Again a solution that assumes that the admin of every mailsystem is a
programmer that can fix the software. Not very realistic. Most of us
have to live with whatever software is widely available. Any solution
has to be found within the capabilities of this software, not by
modification.
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>DevilsPGD <Death...@crazyhat.net> wrote:
>> In message <h8pf26$4te$1...@snarked.org> "D. Stussy"
>> <sp...@bde-arc.ampr.org> was claimed to have wrote:
>>
>>>I do disagree with this - as demonstrated by the race condition regarding a
>>>"mailbox full" condition where at least one of the delivering messages will
>>>fit but not all. A mailbox full NDR returned to a non-forged sender in
>>>response to non-spam/virusmail is a required NDR that must be sent and
>>>cannot be avoided. Dropping is clearly inappropriate.
>>
>> This one is still the easiest of all to fix, enforce quotas at the
>> SMTP-inbound phase rather then on the filesystem.
>
>Again a solution that assumes that the admin of every mailsystem is a
>programmer that can fix the software. Not very realistic. Most of us
>have to live with whatever software is widely available. Any solution
>has to be found within the capabilities of this software, not by
>modification.
Well then the obvious choice would be to buy better software, or to
harass your vendor into updating their software to not cause you to be
blacklisted.
William Reitwiesner
Rob <nom...@example.com> wrote:
> DevilsPGD <Death...@crazyhat.net> wrote:
> > In message <h8pf26$4te$1...@snarked.org> "D. Stussy"
> > <sp...@bde-arc.ampr.org> was claimed to have wrote:
> >
> >>I do disagree with this - as demonstrated by the race condition regarding a
> >>"mailbox full" condition where at least one of the delivering messages will
> >>fit but not all. A mailbox full NDR returned to a non-forged sender in
> >>response to non-spam/virusmail is a required NDR that must be sent and
> >>cannot be avoided. Dropping is clearly inappropriate.
> >
> > This one is still the easiest of all to fix, enforce quotas at the
> > SMTP-inbound phase rather then on the filesystem.
>
> Again a solution that assumes that the admin of every mailsystem is a
> programmer that can fix the software. Not very realistic. Most of us
> have to live with whatever software is widely available. Any solution
> has to be found within the capabilities of this software, not by
> modification.
Actually it's the other way around. If you hook a piece of crap to the
public Internet, then you'll reap what you sow.
Perhaps your company's business would be better served by *not* trying
to participate in the public Internet, at least not until all of you
know what you're doing.
Blarg's .sig is appropriate here:
Current Peeve: The mindset that the Internet is some
sort of school for novice sysadmins and that everyone
-not- doing stupid dangerous things should act like
patient teachers with the ones who are. -- Bill Cole, NANAE
D. Stussy
> On Wed, 16 Sep 2009 17:24:01 +0000, D. Stussy wrote:
> >> I currently believe all NDRs can be avoided (at the cost of dropping
> >> some mail in very rare situations, [sic, parenthetical not closed] ...
> >
> > I do disagree with this - as demonstrated by the race condition
> > regarding a "mailbox full" condition where at least one of the
> > delivering messages will fit but not all. A mailbox full NDR returned
> > to a non-forged sender in response to non-spam/virusmail is a required
> > NDR that must be sent and cannot be avoided. Dropping is clearly
> > inappropriate.
>
> I already showed in another posting that your race condition is very
> easily solved. In fact I would say that your mailserver is misconfigured
> if it allows this race condition.
And I showed you that your solution to the race condition rejects messages
that could have been accepted, thus causing another problem - false message
rejection.
D. Stussy
news:j3d2b51o4qvvfreij...@4ax.com...
> In message <h8pf26$4te$1...@snarked.org> "D. Stussy"
> <sp...@bde-arc.ampr.org> was claimed to have wrote:
> >I do disagree with this - as demonstrated by the race condition
regarding a
> >"mailbox full" condition where at least one of the delivering messages
will
> >fit but not all. A mailbox full NDR returned to a non-forged sender in
> >response to non-spam/virusmail is a required NDR that must be sent and
> >cannot be avoided. Dropping is clearly inappropriate.
>
> This one is still the easiest of all to fix, enforce quotas at the
> SMTP-inbound phase rather then on the filesystem.
That does not ELIMINATE the race condition.
Two mail processes can still check simultaneously, find that there is
sufficient space for each message individually (but not both together),
each accepts (because it is unaware of the other), and then when the MDA
phase actually attempts to place the messages into the mailbox, only one
succeeds, and the other gets an NDR.
D. Stussy
> D. Stussy wrote:
> > "Fred Mobach" <fr...@mobach.nl> wrote in message
> > news:4aaf69c8$0$283$1472...@news.sunsite.dk...
> >> Or a server behind the listed server is not properly configured.
> >
> > Thus a false positive - as it's listing the WRONG "misbehaving"
> > server.
>
> In the case I noticed the listed server had a public IP adress, the
> server behind it a private IP address. Seen from backscatterer.org it
> listed the _correct_ server which had sent the backscatter to the
> internet.
It still misidentifies the misbehaving server. Granted, if the misbehaving
server has a private network address, then it can't be listed because it
can't be uniquely identified. The listing that results is still false.
Rob
>> Again a solution that assumes that the admin of every mailsystem is a
>> programmer that can fix the software. Not very realistic. Most of us
>> have to live with whatever software is widely available. Any solution
>> has to be found within the capabilities of this software, not by
>> modification.
>
> Actually it's the other way around. If you hook a piece of crap to the
> public Internet, then you'll reap what you sow.
If you think you are so good, why don't you compile a list of software
that is good and complies to the unwritten rules of the blocklist
maintainers, instead of calling things "a piece of crap" without even
knowing which software it is?
> Perhaps your company's business would be better served by *not* trying
> to participate in the public Internet, at least not until all of you
> know what you're doing.
What makes you think that "my company" is in the position we are
discussing here? I never said that.
Also, you seem to think that companies feel "not well served" by
software that works OK in day to day transactions but has a small
chance of sending a DSN in the wrong direction. Such is not the case.
MrD
> "Fred Mobach" <fr...@mobach.nl> wrote in message
> news:4ab229b8$0$286$1472...@news.sunsite.dk...
>> D. Stussy wrote:
>>> "Fred Mobach" <fr...@mobach.nl> wrote in message
>>> news:4aaf69c8$0$283$1472...@news.sunsite.dk...
>>>> Or a server behind the listed server is not properly
>>>> configured.
>>> Thus a false positive - as it's listing the WRONG "misbehaving"
>>> server.
>> In the case I noticed the listed server had a public IP adress, the
>> server behind it a private IP address. Seen from backscatterer.org
>> it listed the _correct_ server which had sent the backscatter to
>> the internet.
>
> It still misidentifies the misbehaving server. Granted, if the
> misbehaving server has a private network address, then it can't be
> listed because it can't be uniquely identified. The listing that
> results is still false.
That is obviously linked to what "true" might mean. In this context, a
listing amounts to an assertion that mail with specified properties was
received directly from X. How it got to X probably isn't a question of
great interest to the automated listing engine that sits behind the
spamtraps.
So a "false listing" would have to be an entry for which no such message
was received.
Well, that's how I'd interpret the phrase "false listing" in the context
of an automated list driven by spamtraps.
Your concerns about where X might have got the message from looks to me
like a smokescreen, designed to support your untenable claim that a
backscatter list must implement your preferred selection of FUSSPs,
despite the obvious fact that such a list would be less useful than
BACKSCATTERER.
--
MrD.
http://ipquery.org
Shmuel (Seymour J.) Metz
at 01:03 PM, Rob <nom...@example.com> said:
>If you think you are so good, why don't you compile a list of software
>that is good and complies to the unwritten rules of the blocklist
>maintainers, instead of calling things "a piece of crap" without even
>knowing which software it is?
He made the mistake of believing your description of the software's
limitations.
>Also, you seem to think that companies feel "not well served" by
>software that works OK in day to day transactions but has a small chance
>of sending a DSN in the wrong direction. Such is not the case.
It's not my dog.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Rob
>>Again a solution that assumes that the admin of every mailsystem is a
>>programmer that can fix the software. Not very realistic. Most of us
>>have to live with whatever software is widely available. Any solution
>>has to be found within the capabilities of this software, not by
>>modification.
>
> Well then the obvious choice would be to buy better software, or to
> harass your vendor into updating their software to not cause you to be
> blacklisted.
Tell us where this "better software" is available. Chances are that
it has some problem in an entirely different area, which again cannot
be fixed. The perfect software probably doesn't exist. Companies
select software based on a set of criteria, and you will have to live
with the fact that self-invented rules like "it should never ever send a
DSN" are very low on that list.
Seth
Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>On Wed, 16 Sep 2009 14:03:57 +0000, Seth wrote:
>> In article <50i2o6-...@news.rtij.nl>, Martijn Lievaart
>> <m...@rtij.nl.invlalid> wrote:
>>
>>>The only way not to get listed is to turn of NDRs completely, or always
>>>5xx even if delivery to some recipients failed while others succeeded in
>>>the data phase.
>>
>> Why not 4xx, and use some cleverness on the retry? (E.g. accept for
>> those users where delivery succeeded, but don't redeliver; then 5xx the
>> failures, or even try again and 4xx if any succeeds.)
>
>Clever! However then _all_ senders will get the NDR (from their own mail
>server, so a wanted one)
No; a proper mailserver will retry the 4xx after around 30 minutes,
but won't sent its own users a temporary NDR for 4 hours.
> and in the case of a permanent failure probably
>some warnings about delayed delivery as well. So although it will work,
>it is not a solution that will sit well with customers.
The second time, it 5xx at RCPT TO for those who failed; the senders
get the same 5xx NDR locally as otherwise, just half an hour later.
Where it passed, the only strange thing is that the sender thinks it
was delivered half an hour after the recipient got it, but that's only
observable by reading logs.
>> That's a smop.
>
>Ah, yes, but most mailadmins are not programmers.
But most mailserver writers are. Mailadmins (or their employers)
might need to hire programmers, or buy better software.
> I am, so I did create the appropriate modules for Courier, but this
>is beyond 99% of mail admins and beyond 95% of organisations. Of
>course they could do it, but it would be much better if mail server
>software was more mature on this point.
Agreed.
Seth
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"Fred Mobach" <fr...@mobach.nl> wrote in message
>news:4aaf69c8$0$283$1472...@news.sunsite.dk...
>> Or a server behind the listed server is not properly configured.
>
>Thus a false positive - as it's listing the WRONG "misbehaving" server.
Nope, it's listing the IP address that *emitted* the backscatter *at
them* which is the only useful thing to know. Knowing that there's a
misconfigured machine at 192.168.1.101 inside somebody's network is of
no use to me whatsoever. Knowing that the aforementioned machine
emits it garbage via a particular real IP address is.
>"Martijn Lievaart" <m...@rtij.nl.invlalid> wrote in message
>news:50i2o6-...@news.rtij.nl...
>> I currently believe all NDRs can be avoided (at the cost of dropping some
>> mail in very rare situations, [sic, parenthetical not closed] ...
>
>I do disagree with this - as demonstrated by the race condition regarding a
>"mailbox full" condition where at least one of the delivering messages will
>fit but not all.
The concept of "reserving space" doesn't exist on your planet?
> A mailbox full NDR returned to a non-forged sender in
>response to non-spam/virusmail is a required NDR that must be sent and
>cannot be avoided. Dropping is clearly inappropriate.
A mailbox full NDR sent to a forgery victim due to spam is not
required and is a sign of misconfiguration.
>As noted in another reply, a change in either STD 10 (via the RFC process)
>or a correction in the listing criteria of the backscatterer list are the
>only two ways the false positive problem will be resolved.
There's a third way, but it's even less likely: you could learn to
understand that other people mean what they say, not what you want
them to be meaning by using your own idiosyncratic definitions of the
terms they use.
Seth
D. Stussy
I'm surprised that you now finally agree! That's what I have said all
along: The criteria don't match their stated goal.
> In your opinion. What it comes down to is that you think the list should
> have different policies from what the list-ops think.
>
> You're entitled to an opinion. But you're unlikely to change the views
> of the list-ops, even after banging on about it for a month.
>
> > and thus open to false positive listings when comparing the rules
> > against their goal.
>
> That's "their goal" as re-interpreted for them by you.
It's not a reinterpretation if the stated rules are incomplete. It's a
MISMATCH - and that's what I have said. Their rules don't match their
goal.
E-Mail Sent to this address will be added to the BlackLists
> Companies select software based on a set of criteria,
> and you will have to live with the fact that self
> DSN" are very low on that list.
Which BlackLists / WhiteLists / DNSbls don't have
"self-invented rules"?
If the "Companies", can live with the consequences
of some recipients (or their mail servers' admins),
not tolerating what the recipients think is abuse,
and preventing it at the recipients end,
then I don't see why the "Companies" would have a
problem with the recipients decisions'.
I certainly don't.
As I often write (perhaps too often),
if recipients need / want / expect messages from me,
then they should accept and deliver them,
if they don't, then that is the recipients problem.
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
DevilsPGD
<sp...@bde-arc.ampr.org> was claimed to have wrote:
>"DevilsPGD" <Death...@crazyhat.net> wrote in message
>news:j3d2b51o4qvvfreij...@4ax.com...
>> In message <h8pf26$4te$1...@snarked.org> "D. Stussy"
>> <sp...@bde-arc.ampr.org> was claimed to have wrote:
>> >I do disagree with this - as demonstrated by the race condition
>regarding a
>> >"mailbox full" condition where at least one of the delivering messages
>will
>> >fit but not all. A mailbox full NDR returned to a non-forged sender in
>> >response to non-spam/virusmail is a required NDR that must be sent and
>> >cannot be avoided. Dropping is clearly inappropriate.
>>
>> This one is still the easiest of all to fix, enforce quotas at the
>> SMTP-inbound phase rather then on the filesystem.
>
>That does not ELIMINATE the race condition.
>
>Two mail processes can still check simultaneously, find that there is
>sufficient space for each message individually (but not both together),
>each accepts (because it is unaware of the other), and then when the MDA
>phase actually attempts to place the messages into the mailbox, only one
>succeeds, and the other gets an NDR.
You completely missed the point.
Make the decision during the SMTP-inbound phase (at the RCPT TO or after
DATA command, depending on how picky you are) then accept and deliver
the message, period.
Yes, users might go over the quota by a couple messages, but unless your
queue lengths are excessively long, only by a couple messages.
Shmuel (Seymour J.) Metz
at 02:50 PM, Martijn Lievaart <m...@rtij.nl.invlalid> said:
>Clever! However then _all_ senders will get the NDR
Why will they get an NDR on a 4yz? Perhaps Seth should have spelled out
the scenario, but I don't see a problem with it.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Chris Witkowski
> In article <h8pf26$4te$1...@snarked.org>,
> D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
> >"Fred Mobach" <fr...@mobach.nl> wrote in message
> >news:4aaf69c8$0$283$1472...@news.sunsite.dk...
> >> mail in very rare situations, [sic, parenthetical not closed] ...
> >
> >I do disagree with this - as demonstrated by the race condition regarding a
> >"mailbox full" condition where at least one of the delivering messages will
> >fit but not all.
>
> The concept of "reserving space" doesn't exist on your planet?
Especially when disk space is so cheap and plentiful. For example,
Gmail is currently offering >7GB per free account (www.gmail.com).
--
Christopher Witkowski chr...@ncf.ca http://web.ncf.ca/chrisw
Ph: (705) 256-5359
MrD
>>
>> Unfortunately, the stated rules are incomplete
>
> I'm surprised that you now finally agree! That's what I have said
> all along: The criteria don't match their stated goal.
Regrettably a ">" seems to have got lost there. I was trying to quote
you; I'm surprised that you didn't notice that those were your words.
>
>> In your opinion. What it comes down to is that you think the list
>> should have different policies from what the list-ops think.
>>
>> You're entitled to an opinion. But you're unlikely to change the
>> views of the list-ops, even after banging on about it for a month.
>>
>>> and thus open to false positive listings when comparing the rules
>>> against their goal.
>> That's "their goal" as re-interpreted for them by you.
>
> It's not a reinterpretation if the stated rules are incomplete. It's
> a MISMATCH - and that's what I have said. Their rules don't match
> their goal.
The way *I* assess a blocklist is this: I treat the methodology as *the
definition* of the listing criteria. Any "goal" or "description" of the
list is so much verbiage - a summary, as it were, for convenience, but
not to be taken as definitive. The methodology - how you get on and off
- defines the list.
Therefore the true "goal" of the list *does* match the listing criteria,
in that the listing criteria define the real goal.
If you want to restrict your assessment of the goals to a single word
such as "backscatter", and then declare that the listing criteria result
in the wrong things getting listed, that's your prerogative. But if you
do approach things that way, then you are bound to find errors in any
list (especially given your propensity for idiosyncratic redefinitions
of common terms).
A better approach, may I suggest, would be to accept that the list is
free of false positives, but that you don't think that "backscatter" is
a correct term for what appears on the list. Then we have a simple
disagreement about dictionaries, about which I couldn't care less.
--
MrD.
http://ipquery.org
D. Stussy
So have you.
> Make the decision during the SMTP-inbound phase (at the RCPT TO or after
> DATA command, depending on how picky you are) then accept and deliver
> the message, period.
Testing mailbox size during SMTP (i.e. before acceptance) does NOT and
CANNOT eliminate the race condition.
> Yes, users might go over the quota by a couple messages, but unless your
> queue lengths are excessively long, only by a couple messages.
One can't go "over quota" if the mailbox full condition is being caused by
something other than a quota overflow, e.g. a DISK full condition at the OS
level.
No matter how many tests one performs during SMTP, one cannot eliminate
this race condition and the NDR it will PROPERLY send within STD 10.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"Fred Mobach" <fr...@mobach.nl> wrote in message
>news:4ab229b8$0$286$1472...@news.sunsite.dk...
>> D. Stussy wrote:
>> > "Fred Mobach" <fr...@mobach.nl> wrote in message
>> > news:4aaf69c8$0$283$1472...@news.sunsite.dk...
>> >> Or a server behind the listed server is not properly configured.
>> >
>> > Thus a false positive - as it's listing the WRONG "misbehaving"
>> > server.
>>
>> In the case I noticed the listed server had a public IP adress, the
>> server behind it a private IP address. Seen from backscatterer.org it
>> listed the _correct_ server which had sent the backscatter to the
>> internet.
>
>It still misidentifies the misbehaving server. Granted, if the misbehaving
>server has a private network address, then it can't be listed because it
>can't be uniquely identified. The listing that results is still false.
Their goal is to list the server *that connects to them and sends the
NDN for a message that they didn't originate*. That's exactly what
they're doing. The details of the sender's network configuration are
completely irrelevant; the IP address that they claimed connected to
them and provided the NDN is the IP address that connected to them and
provided the NDN.
Seth
MrD
>
>> Yes, users might go over the quota by a couple messages, but unless your
>> queue lengths are excessively long, only by a couple messages.
>
> One can't go "over quota" if the mailbox full condition is being caused by
> something other than a quota overflow, e.g. a DISK full condition at the OS
> level.
So set a realistic quota?
>
> No matter how many tests one performs during SMTP, one cannot eliminate
> this race condition and the NDR it will PROPERLY send within STD 10.
Rubbish. You're clutching at straws.
--
MrD.
http://ipquery.org
Hal Murray
"D. Stussy" <sp...@bde-arc.ampr.org> writes:
>Testing mailbox size during SMTP (i.e. before acceptance) does NOT and
>CANNOT eliminate the race condition.
The database guys solved this problem years ago. If not,
modern banking wouldn't work.
It's not simple, but it's not rocket science either. I think
transaction if the magic word.
You have to get a lock, reserve the space, release the lock, ...
and remember enough information so that you can back out if
you change your mind or the system crashes before you finish
the transaction.
I doubt if any mail systems currently do all that work, but
"CANNOT eliminate the race condition" is clearly wrong.
--
These are my opinions, not necessarily my employer's. I hate spam.
Martijn Lievaart
> "Martijn Lievaart" <m...@rtij.nl.invlalid> wrote in message
> news:k2t7o6-...@news.rtij.nl...
>> On Wed, 16 Sep 2009 17:24:01 +0000, D. Stussy wrote:
>> >> I currently believe all NDRs can be avoided (at the cost of dropping
>> >> some mail in very rare situations, [sic, parenthetical not closed]
>> >> ...
>> >
>> > I do disagree with this - as demonstrated by the race condition
>> > regarding a "mailbox full" condition where at least one of the
>> > delivering messages will fit but not all. A mailbox full NDR
>> > returned to a non-forged sender in response to non-spam/virusmail is
>> > a required NDR that must be sent and cannot be avoided. Dropping is
>> > clearly inappropriate.
>>
>> I already showed in another posting that your race condition is very
>> easily solved. In fact I would say that your mailserver is
>> misconfigured if it allows this race condition.
>
> And I showed you that your solution to the race condition rejects
> messages that could have been accepted, thus causing another problem -
> false message rejection.
And I showed you that this is not so and you never answered to that.
M4
Michael Deutschmann
> "DevilsPGD" <Death...@crazyhat.net> wrote:
> > Yes, users might go over the quota by a couple messages, but unless your
> > queue lengths are excessively long, only by a couple messages.
>
> One can't go "over quota" if the mailbox full condition is being caused by
> something other than a quota overflow, e.g. a DISK full condition at the OS
> level.
>
> No matter how many tests one performs during SMTP, one cannot eliminate
> this race condition and the NDR it will PROPERLY send within STD 10.
To avoid hard disk full, you just slap a seperate quota on incoming-queue
space (which leads to 4xx, not 5xx, if hit) for each MX, and then make
sure that you have enough slack space (beyond the users' paid-for quotas)
for each MX to unload its queue past the official quota.
This of course means you cannot ride the redline of your hard-disk
capacity when setting quotas; you have to pay more for hard-disk than you
believe you should. We *know that*. We just *don't care*.
---- Michael Deutschmann <mic...@talamasca.ocis.net>
Chris Witkowski
> In article <h94k68$498$1...@snarked.org>,
> "D. Stussy" <sp...@bde-arc.ampr.org> writes:
>
> >Testing mailbox size during SMTP (i.e. before acceptance) does NOT and
> >CANNOT eliminate the race condition.
>
> The database guys solved this problem years ago. If not,
> modern banking wouldn't work.
>
> It's not simple, but it's not rocket science either. I think
> transaction if the magic word.
>
> You have to get a lock, reserve the space, release the lock, ...
> and remember enough information so that you can back out if
> you change your mind or the system crashes before you finish
> the transaction.
>
> I doubt if any mail systems currently do all that work, but
> "CANNOT eliminate the race condition" is clearly wrong.
I don't think you have to go to that much trouble. You can let your OS
handle the race condition. Just write out the message to disk before
sending the response to the data command. In these days of disk
caching you might have to set suitable options on your file I/O or
perhaps issue a special function call to your OS to be sure you know
whether or not the message was successfully written. I would hope
that decent email server software already does something like this.
--
Christopher Witkowski chr...@ncf.ca http://web.ncf.ca/chrisw
Ph: (705) 256-5359
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"DevilsPGD" <Death...@crazyhat.net> wrote in message
>news:j3d2b51o4qvvfreij...@4ax.com...
>> This one is still the easiest of all to fix, enforce quotas at the
>> SMTP-inbound phase rather then on the filesystem.
>
>That does not ELIMINATE the race condition.
>
>Two mail processes can still check simultaneously, find that there is
>sufficient space for each message individually (but not both together),
>each accepts (because it is unaware of the other), and then when the MDA
>phase actually attempts to place the messages into the mailbox, only one
>succeeds, and the other gets an NDR.
1. Do all the other checks (spam, etc.) first.
2. If the message passes all of them, check for *and reserve* space
for it. If that fails, 4yz or 5yz it as appropriate.
3. Deliver it. There's enough space, because you reserved it.
Seth
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:h8sova$87o$1...@news.eternal-september.org...
>> D. Stussy wrote:
>> > "MrD" <mrdem...@jackpot.invalid> wrote in message
>> > news:h8jd36$j3b$1...@news.eternal-september.org...
>> >> D. Stussy wrote:
>> >>> "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid>
>> >>> wrote in message
>> >>> news:4aaa9dc3$2$fuzhry+tra$mr2...@news.patriot.net...
>> >>>> In <slrnhajurq...@xs7.xs4all.nl>, on 09/11/2009 at
>> >>>> 02:23 PM, Rob <nom...@example.com> said:
>> They list what they say they list. Backscatterer says it lists machines
>> that send from <> to a spamtrap.
>>
>> > As previously demonstrated, the list can list MORE than what it says
>> > it lists. I do agree that there won't be any false negatives
>> > according to the analysis of its rules.
>> You mean "according to their published listing criteria", I guess.
>> Unfortunately, the stated rules are incomplete
>I'm surprised that you now finally agree! That's what I have said all
>along: The criteria don't match their stated goal.
Yes, they do, provided you interpret the meaning of words the way
they, I, the dictionary, and just about everyone else do. If you have
your own idiosyncratic interpretations, then you can't expect anything
to match.
>> > and thus open to false positive listings when comparing the rules
>> > against their goal.
>> That's "their goal" as re-interpreted for them by you.
>It's not a reinterpretation if the stated rules are incomplete.
It's a mis-interpretation.
> It's a MISMATCH - and that's what I have said. Their rules don't
>match their goal.
Presumably, their goal is to assist others in avoiding receiving NDNs
for email those others didn't actually send. Their rules work quite
well for that: the list IP addresses that emit the stuff that they
want to assist others in not receiving.
Why do you think their goal is something else? Can you support any
such beliefs with *their* statements?
Seth
D. Stussy
When the list includes servers that have sent VALID REQUIRED NDRs to
NON-FORGED senders that did not originate spam, the list will NEVER be a
backscatterer list as their designer(s) intended.
Martijn Lievaart
> In article <kvs7o6-...@news.rtij.nl>, Martijn Lievaart
> <m...@rtij.nl.invlalid> wrote:
>>On Wed, 16 Sep 2009 14:03:57 +0000, Seth wrote:
>>> In article <50i2o6-...@news.rtij.nl>, Martijn Lievaart
>>> <m...@rtij.nl.invlalid> wrote:
>>>
>>>>The only way not to get listed is to turn of NDRs completely, or
>>>>always 5xx even if delivery to some recipients failed while others
>>>>succeeded in the data phase.
>>>
>>> Why not 4xx, and use some cleverness on the retry? (E.g. accept for
>>> those users where delivery succeeded, but don't redeliver; then 5xx
>>> the failures, or even try again and 4xx if any succeeds.)
>>
>>Clever! However then _all_ senders will get the NDR (from their own mail
>>server, so a wanted one)
>
> No; a proper mailserver will retry the 4xx after around 30 minutes, but
> won't sent its own users a temporary NDR for 4 hours.
>
>> and in the case of a permanent failure probably
>>some warnings about delayed delivery as well. So although it will work,
>>it is not a solution that will sit well with customers.
>
> The second time, it 5xx at RCPT TO for those who failed; the senders get
> the same 5xx NDR locally as otherwise, just half an hour later. Where it
> passed, the only strange thing is that the sender thinks it was
> delivered half an hour after the recipient got it, but that's only
> observable by reading logs.
How do you know that it is the same message and not another one? This
cannot be made to work I think.
M4
Seth
Rob <nom...@example.com> wrote:
>Tell us where this "better software" is available. Chances are that
>it has some problem in an entirely different area, which again cannot
>be fixed. The perfect software probably doesn't exist. Companies
>select software based on a set of criteria, and you will have to live
>with the fact that self-invented rules like "it should never ever send a
>DSN" are very low on that list.
And if you select software that spams me, you're going to have to live
with the results.
If you think "avoid spamming victims of forgery" is a low-priority
requirement, then people who don't want to get spammed as victims of
forgery are likely to feel that receiving email from you is even lower
priority.
Seth
Rob
> You have to get a lock, reserve the space, release the lock, ...
> and remember enough information so that you can back out if
> you change your mind or the system crashes before you finish
> the transaction.
>
> I doubt if any mail systems currently do all that work, but
> "CANNOT eliminate the race condition" is clearly wrong.
Again, a "solution" that requires programming. What is needed is
a solution that can be implemented in existing mail software using
configuration.
Also you need to understand that many mail systems are implemented
using a front-end server that does the spam and virus scanning on
the mail connections it receives from internet, and then forwards
the mail to a back-end server that does the storage of mail and has
the functionality the business requires.
This combo is often not capable of performing quota checks before
a message is accepted. Your extra demands will have to wait until
software suppliers implement this, either in free- or commercial
software or preferably in both.
It is easy to tell people that the software they use is no good,
but impossible for most to change this when no better software is
widely available.
Martijn Lievaart
> Especially when disk space is so cheap and plentiful. For example, Gmail
> is currently offering >7GB per free account (www.gmail.com).
This is one of my pet peeves. Disk space is getting cheaper all the time,
but corporate disk space is still anything but cheap.
It's not expensive anymore, but it's neither cheap. You still pay for
using 15K scsi disks vs 7K2 sata, a slot in the san (so indirect for
space in the server room), maintenance, backup, power consumption, air
conditioning, etc. Not too much when taken for one disk, but even then,
it does add up.
But I agree that in this context the costs are probably minor.
M4
Seth
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
>In <kvs7o6-...@news.rtij.nl>, on 09/17/2009
> at 02:50 PM, Martijn Lievaart <m...@rtij.nl.invlalid> said:
>
>>Clever! However then _all_ senders will get the NDR
>
>Why will they get an NDR on a 4yz? Perhaps Seth should have spelled out
>the scenario, but I don't see a problem with it.
If the 4yz persists for 4 hours (as typically configured), a
notification is provided to the sender (by typical mailswerver
software).
But in my proposal, that wouldn't happen; at the first retry
(typically 30 minutes), the message would be accepted or rejected
(5yz).
Seth
Shmuel (Seymour J.) Metz
at 07:01 PM, Rob <nom...@example.com> said:
>and you will have to live with the fact that self-invented rules
> like "it should never ever send a DSN" are very low on that list.
While *you* will have to live with the fact that maintainers and users of
DNSBL's don't care about the excuses for abuse, they only care about the
abuse itself. If you get blocklisted because of your choice of software,
the loss of connectivity is your problem to deal with, not theirs.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
MrD
>
> When the list includes servers that have sent VALID REQUIRED NDRs to
> NON-FORGED senders that did not originate spam, the list will NEVER
> be a backscatterer list as their designer(s) intended.
Why should *I* care whether they originated (whatever you define as)
spam? If they might send NDRs to me, when I sent them nothing, then I
could well have a use for a list that includes them. Regardless of
definitions.
And it might be a good idea to quit trying to divine other people's
intentions.
--
MrD.
http://ipquery.org
Claus v. Wolfhausen
>
>"Claus v. Wolfhausen" <use-reply-...@remove-this.com> wrote in
>message news:h8kopa$316$1...@ulm.shuttle.de...
>> D. Stussy wrote:
>>
>> > WRONG! Properly configured mail servers can still get listed. That's
>the
>> > problem with the list.
>>
>real.
>>
>> If a server gets listed that is proof for it is NOT properly configured.
>
>Only in your mind.
>
>A server is properly configured if it follows all RFCs and standards in
>place at the time.
Then you believe any open relay to be properly configured, because it is 100%
conform to RFC5321?
Wake up and don't try to hide behind RFC's.
>These standards currently include situations where
>REQUIRED NDRs are sent off-host to non-forged senders of an original
>message. However, your listing criteria FAILS to account that such NDRs
>are legitimate (as STD 10 says), thus resulting in false positive listings
>as these servers are NOT misbehaving.
>
> Compliance with the published standards of the Internet is not
>misbehavior that is cause for listing anyone on any blacklist.
See that text about open relays above...
>You have two choices to eliminate the potential of false positives:
Backscatterer does not produce any false positive if used as intended.
>1) Publish your own RFC to get the standards changed so that off-host NDRs
>are forbidden.
Why should i waste my time to write an RFC?
You know what an RFC is, do you?
RFC = Request For Comments
When it comes to backscatter, i just list those abusers instead of requesting
them for comments.
If you follow best practices then you will not get listed.
>2) Add to your listing criteria that you will only accept backscatterer
>referrals from mailboxes protected by forgery detection methods (currently
>SPF and/or DK/DKIM), and follow through by implementing such.
Why should i care about SPF, DKIM and potential others?
It is a known fact that those can not be used by anyone by design.
>Either of those steps will fix the DEFECT in your listing requirements as
>compared to the goal you claim they enforce. Otherwise, your list remains
>open to false positives as noted and therefore, it is disingenuous.
I told it multiple times:
There is no defect, it is the listing criterias. Deal with it.
>I have told you the problem with your criteria. I have told you the
>solution, too. Why won't you implement the solution? It's easy....
What you call a solution is nothing than inaceptable.
We already have a solution ... list and block those that backscatter ....
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
Martijn Lievaart
> When the list includes servers that have sent VALID REQUIRED NDRs to
> NON-FORGED senders that did not originate spam, the list will NEVER be a
> backscatterer list as their designer(s) intended.
I think the list is exactly as the designers intended, you just happen
not to agree with their design.
M4
DevilsPGD
<sp...@bde-arc.ampr.org> was claimed to have wrote:
>"DevilsPGD" <Death...@crazyhat.net> wrote in message
>news:ofe7b5pd1mc434gft...@4ax.com...
>> Make the decision during the SMTP-inbound phase (at the RCPT TO or after
>> DATA command, depending on how picky you are) then accept and deliver
>> the message, period.
>
>Testing mailbox size during SMTP (i.e. before acceptance) does NOT and
>CANNOT eliminate the race condition.
>
>> Yes, users might go over the quota by a couple messages, but unless your
>> queue lengths are excessively long, only by a couple messages.
>
>One can't go "over quota" if the mailbox full condition is being caused by
>something other than a quota overflow, e.g. a DISK full condition at the OS
>level.
This one is even more trivial to solve since the backend should be
returning a temp-failure (4xx) rather then 5xx to the MX when the MX
tries to deliver to the backend (or if a non-SMTP method is used, have
it tempfail and queue similarly -- SMTP handles this gracefully)
The inbound-MX should be configured to hold the messages until the
backend situation is resolved anyway, otherwise you'll actually bounce
legitimately wanted mail due to temporary failures.
The inbound-MX itself can have quotas and/or will run out of space
eventually, but it too will 4xx mail as needed, all without a bounce.
In all cases, configuring your various servers to throw warnings and
start temp-failing when you're low on disk space allowing administrators
to resolve problems before mail is even tempfailed would be ideal, but
in the event that you do run out of space, the proper result is a
tempfail (SMTP 4xx) rather them permanent failure or bounce.
D. Stussy
message news:4ab7681f$2$fuzhry+tra$mr2...@news.patriot.net...
> In <slrnhb6d4n...@xs7.xs4all.nl>, on 09/18/2009
> at 07:01 PM, Rob <nom...@example.com> said:
> >and you will have to live with the fact that self-invented rules
> > like "it should never ever send a DSN" are very low on that list.
>
> While *you* will have to live with the fact that maintainers and users of
> DNSBL's don't care about the excuses for abuse, they only care about the
> abuse itself. If you get blocklisted because of your choice of software,
> the loss of connectivity is your problem to deal with, not theirs.
Actions specifically permitted and/or required by the Internet standards
are not abusive (else the standard usually gets changed to disallow the
abusive actions).
There has been no change to the standards here. Therefore, the blacklist
administrators are in error for classifying permitted actions as abuse and
NOT issuing an RFC to get the standards changed.
Michelle Sullivan
> Hal Murray <hal-u...@ip-64-139-1-69.sjc.megapath.net> wrote:
>> You have to get a lock, reserve the space, release the lock, ...
>> and remember enough information so that you can back out if
>> you change your mind or the system crashes before you finish
>> the transaction.
>>
>> I doubt if any mail systems currently do all that work, but
>> "CANNOT eliminate the race condition" is clearly wrong.
>
> Again, a "solution" that requires programming. What is needed is
> a solution that can be implemented in existing mail software using
> configuration.
>
> Also you need to understand that many mail systems are implemented
> using a front-end server that does the spam and virus scanning on
> the mail connections it receives from internet, and then forwards
> the mail to a back-end server that does the storage of mail and has
> the functionality the business requires.
That is available in commercial products (and opensource) without the
requirement for programming. Some function are _not possible_ in any
and all solutions currently available without programming, and if the
issue were that I'd be in agreement with you.
Quota, User-Unknown etc are all solvable without programming, just
careful choice of MTAs. So there are no excuses there.
I (in another thread) have an example that is *not* solvable without
programming knowledge with the currently available software (commercial
and open source in any combo).
I could be wrong, but I think there are a lot of cleaver people here
that are caught up in the hysteria and hype surrounding backscatter and
how bad it is. I have been one of the people to speak out against it,
and indeed I have even listed some of the worst servers as spam senders
in SORBS quite deliberately (particularly when they don't even respond
with RFC compliant bounces, and return the entire spam in the bounce.)
I have been the recipient of many backscatter bombs (backscatter
attacks) where I have received thousands if not millions of bounces in
hours leaving me to clean up the mess of bandwidth, blown out mailboxes
etc etc for hours. SO I CAN TALK ABOUT THIS WITH AUTHORITY.
Backscatterer.org was a good idea, but it doesn't take into account best
effort which I think is its major failing - however determining best
effort is quite difficult so I can understand that policy. It should
take into account RFC compliant mail servers in a better way than those
that are not. It should also take into account those servers that do
554 unknown users, and tempfail/permfail over quota users at SMTP time.
It should also take into account servers that whilst they have to have
auo-responders everything has been done to minimize any possible abuse.
There are servers out there that should be blocklisted to hell and back
for the way they are setup. There are also other servers out there that
should not be listed for backscatter as their admins had done everything
possible to minimize backscatter.
During the attacks on my servers by far the worst offenders were
"Unknown User", followed a close second by "Over Quota"... this
accounted for over 95% of the attack. The largest portion of the
remaining 5% were out-of-office auto responders, of which most sent
small messages (one or 2 lines) only once. Some send 100's of messages
because they responded every time they received an email (they should be
blacklisted to hell and back.) I don't recall ever seeing a 'Data
Format Error' or 'No space on device' response in the attacks.
Probably the most annoying were the systems that sent the over quota,
because they kept trying to deliver the messages for several days and
were kind enough to let me know that they couldn't and they would
continue re-trying for "x" days...
Summery/Point of this message....? I don't know there is one it could
be a rant, I think backscatterer.org was a good idea, I think it should
evolve, but I'm one to talk, I haven't evolved SORBS in a long time...!
In the current state, I won't use it, and I don't recommend anyone to
use it (in fact I actively discourage people to use it... just like some
do with SORBS.)
Shells
D. Stussy
> On Fri, 18 Sep 2009 13:04:21 +0000, D. Stussy wrote:
> > "Martijn Lievaart" <m...@rtij.nl.invlalid> wrote in message
> > news:k2t7o6-...@news.rtij.nl...
> >> On Wed, 16 Sep 2009 17:24:01 +0000, D. Stussy wrote:
> >> >> I currently believe all NDRs can be avoided (at the cost of
dropping
> >> >> some mail in very rare situations, [sic, parenthetical not closed]
> >> >> ...
> >> >
> >> > I do disagree with this - as demonstrated by the race condition
> >> > regarding a "mailbox full" condition where at least one of the
> >> > delivering messages will fit but not all. A mailbox full NDR
> >> > returned to a non-forged sender in response to non-spam/virusmail is
> >> > a required NDR that must be sent and cannot be avoided. Dropping is
> >> > clearly inappropriate.
> >>
> >> I already showed in another posting that your race condition is very
> >> easily solved. In fact I would say that your mailserver is
> >> misconfigured if it allows this race condition.
> >
> > And I showed you that your solution to the race condition rejects
> > messages that could have been accepted, thus causing another problem -
> > false message rejection.
>
> And I showed you that this is not so and you never answered to that.
Which could imply your message never showed up here. Please identify it by
message ID.
D. Stussy
> D. Stussy wrote:
> >
> > When the list includes servers that have sent VALID REQUIRED NDRs to
> > NON-FORGED senders that did not originate spam, the list will NEVER
> > be a backscatterer list as their designer(s) intended.
>
> Why should *I* care whether they originated (whatever you define as)
> spam? If they might send NDRs to me, when I sent them nothing, then I
> could well have a use for a list that includes them. Regardless of
> definitions.
As the original message wasn't forged and wasn't spam, YOU DID SEND them
something (or authorized someone else to send on your behalf). YOU
PERMITTED IT TO BE SENT IN THE FIRST PLACE.
D. Stussy
news:%XIst...@khar-pern.talamasca.ocis.net...
> On Sun, 20 Sep 2009, D. Stussy wrote:
> > "DevilsPGD" <Death...@crazyhat.net> wrote:
> > > Yes, users might go over the quota by a couple messages, but unless
your
> > > queue lengths are excessively long, only by a couple messages.
> >
> > One can't go "over quota" if the mailbox full condition is being caused
by
> > something other than a quota overflow, e.g. a DISK full condition at
the OS
> > level.
> >
> > No matter how many tests one performs during SMTP, one cannot eliminate
> > this race condition and the NDR it will PROPERLY send within STD 10.
>
> To avoid hard disk full, you just slap a seperate quota on incoming-queue
> space (which leads to 4xx, not 5xx, if hit) for each MX, and then make
> sure that you have enough slack space (beyond the users' paid-for quotas)
> for each MX to unload its queue past the official quota.
>
> This of course means you cannot ride the redline of your hard-disk
> capacity when setting quotas; you have to pay more for hard-disk than you
> believe you should. We *know that*. We just *don't care*.
Then you enter the condition where you may falsely reject messages that you
actually could have accepted. You've traded one problem for another. That
doesn't help.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:h92b9i$qep$1...@news.eternal-september.org...
>> Therefore the true "goal" of the list *does* match the listing criteria,
>> in that the listing criteria define the real goal.
>>
>> If you want to restrict your assessment of the goals to a single word
>> such as "backscatter", and then declare that the listing criteria result
>> in the wrong things getting listed, that's your prerogative. But if you
>> do approach things that way, then you are bound to find errors in any
>> list (especially given your propensity for idiosyncratic redefinitions
>> of common terms).
>>
>> A better approach, may I suggest, would be to accept that the list is
>> free of false positives, but that you don't think that "backscatter" is
>> a correct term for what appears on the list. Then we have a simple
>> disagreement about dictionaries, about which I couldn't care less.
>
>When the list includes servers that have sent VALID REQUIRED NDRs to
>NON-FORGED senders that did not originate spam, the list will NEVER be a
>backscatterer list as their designer(s) intended.
The designers clearly did not intend that the list be a "backscatter
as defined by D. Stussy" list. They apparently did intend that it be
a "backscatter as defined by Seth Breidbart, MrD, the dictionary, the
first 5 web sites in google that define the term 'backscatter'
referring to email, and the admins of the backscatterer.org domain"
list.
And it apparently does match that intention quite accurately.
Seth
D. Stussy
news:h96vd3$oi2$1...@theodyn.ncf.ca...
> "Hal Murray" <hal-u...@ip-64-139-1-69.sjc.megapath.net> wrote in
message news:ppidnSQC1Z0xxCvX...@megapath.net...
> > In article <h94k68$498$1...@snarked.org>,
> > "D. Stussy" <sp...@bde-arc.ampr.org> writes:
> > >Testing mailbox size during SMTP (i.e. before acceptance) does NOT and
> > >CANNOT eliminate the race condition.
> >
> > The database guys solved this problem years ago. If not,
> > modern banking wouldn't work.
> >
> > It's not simple, but it's not rocket science either. I think
> > transaction if the magic word.
> >
> > You have to get a lock, reserve the space, release the lock, ...
> > and remember enough information so that you can back out if
> > you change your mind or the system crashes before you finish
> > the transaction.
> >
> > I doubt if any mail systems currently do all that work, but
> > "CANNOT eliminate the race condition" is clearly wrong.
>
> I don't think you have to go to that much trouble. You can let your OS
> handle the race condition. Just write out the message to disk before
> sending the response to the data command. In these days of disk
> caching you might have to set suitable options on your file I/O or
> perhaps issue a special function call to your OS to be sure you know
> whether or not the message was successfully written. I would hope
> that decent email server software already does something like this.
That's not how SMTP systems currently work. The MDA (mail delivery agent)
does NOT get the message until it's been accepted. There's also no
guarentee that the mailbox will even be on the same physical machine as the
accepting MTA.
What you suggest only works when the MTA and MDA are on the same physical
machine AND the mailboxes are on a filesystem accessable to the MTA (i.e.
"no chroot jail").
Shmuel (Seymour J.) Metz
at 04:48 PM, Rob <nom...@example.com> said:
>Also you need to understand
ObOfficerKrupky *You* need to understand that only your behavior is
relevant to how people treat your traffic, not your excuses for that
behavior.
>Your extra demands will have to wait
Nobody needs your permission to update their deny lists or DNSBL's.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Michael Deutschmann
> When the list includes servers that have sent VALID REQUIRED NDRs to
> NON-FORGED senders that did not originate spam, the list will NEVER be a
> backscatterer list as their designer(s) intended.
The mails in question are not "NON-FORGED". Rather, from your perspective,
the absence of SPF makes them *perfectly forged*.
Backscatterer, and most of us, think DSNs in response to perfect forgeries
remain inexcusable because they can be avoided by binding the inner
mailserver to the deliverability decisions of its MXes.
This means the inner mailserver needs more diskspace than in a
backscatter-tolerant world, and much of the admin's freedom to set local
policy is curtailed. Again, *we know this and don't care*.
Just as SBL-like blacklists don't care about the far greater cost they
impose by demanding that consumer ISPs maintain 24/7 human-staffed abuse
desks.
If SPF-neutral/none senders' insistence on "having it both ways" by denying
you both the ability to automatically detect forgeries, and the right to
change your mind about their delivery, is such a problem for you, then your
only way out is to set policy of refusing to accept anything but SPF-pass
mail.
---- Michael Deutschmann <mic...@talamasca.ocis.net>
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>Actions specifically permitted and/or required by the Internet standards
>are not abusive (else the standard usually gets changed to disallow the
>abusive actions).
Congratulations on earning a Boursey Award for self-contradiction
within the space of a single sentence. The first part of your
statement is an attempt at being definitive: "are not". The
parenthetical explanation shows that isn't the case: "usually".
>There has been no change to the standards here.
There has been no change to the standards about running open relays,
either, but open relays that forward spam are abusive.
> Therefore, the blacklist administrators are in error for
>classifying permitted actions as abuse
They aren't classifying anything as abuse. They are listing IP
addresses according to their criteria for listing IP addresses. _You_
choose to interpret that as claiming abuse, and you redefine the terms
they're using to claim that unsolicited bulk email isn't abuse.
> and NOT issuing an RFC to get the standards changed.
Proposed RFCs for DNSBLs state that the list should list precisely
what it says it lists. They don't say the list has to be for abuse,
RFC violation, or anything else; that's up to the administrator. Or
do you also object to dnsbl.noprimes.org, lucky7 (lists all IP
addresses with a 7), and the like?
Seth
D. Stussy
> In article <h8ma5b$6nh$1...@snarked.org>, D.Stussy sp...@bde-arc.ampr.org
says...
> >"Claus v. Wolfhausen" <use-reply-...@remove-this.com> wrote in
> >message news:h8kopa$316$1...@ulm.shuttle.de...
> >> D. Stussy wrote:
> >>
> >> > WRONG! Properly configured mail servers can still get listed.
That's
> >the
> >> > problem with the list.
> >>
> >> We (tinw) know that you have a problem to see the reality as it is in
> >real.
> >>
> >> If a server gets listed that is proof for it is NOT properly
configured.
> >
> >Only in your mind.
> >
> >A server is properly configured if it follows all RFCs and standards in
> >place at the time.
>
> Then you believe any open relay to be properly configured, because it is
100%
> conform to RFC5321?
Technically, if an open relay doesn't pass spam or virusmail, it's not
really a problem. Open relays that are abused were the problem. Granted
most of them were abused, but not even ORDB ever listed 100% of them. The
list included ORs that were abused.
Being an open relay by itself was not misbehavior. Permitting an open
relay to be abused by spammers and virus-botnets was the misbehavior. Note
the distinction.
> Wake up and don't try to hide behind RFC's.
The RFCs and the Internet standards that they comprise define acceptable
behavior. When an action is specifically permitted, that action by itself
is not abusive. I shall grant you that certain actions can be abused, but
the actions themselves are not cause for listing "misbehavers."
> >These standards currently include situations where
> >REQUIRED NDRs are sent off-host to non-forged senders of an original
> >message. However, your listing criteria FAILS to account that such NDRs
> >are legitimate (as STD 10 says), thus resulting in false positive
listings
> >as these servers are NOT misbehaving.
> >
> > Compliance with the published standards of the Internet is not
> >misbehavior that is cause for listing anyone on any blacklist.
>
> See that text about open relays above...
>
> >You have two choices to eliminate the potential of false positives:
>
> Backscatterer does not produce any false positive if used as intended.
Incorrect. I have shown the possibility that it can. You haven't shown
the possibility that it can't.
> >1) Publish your own RFC to get the standards changed so that off-host
NDRs
> >are forbidden.
>
> Why should i waste my time to write an RFC?
Because you are attempting to enforce behavior that is currently contrary
to the standards. You believe that NO system should send an NDR, yet there
are still "required NDRs" in the standards. Your RFC is your proposal to
change that behavior.
As you consider the whole Internet standards procedure a waste o f your
time, I formally declare your backscatterer list as an abuse to the
Internet as a whole and a waste of everyone's time.
> You know what an RFC is, do you?
> RFC = Request For Comments
> When it comes to backscatter, i just list those abusers instead of
requesting
> them for comments.
Idiot.
> If you follow best practices then you will not get listed.
WRONG! I have already shown you how a system that follows all best current
practices and is compliant with all aspects of the standards (including
sending NDRs when required to - in response to non-forged, non-spam
messages) can still be listed.
> >2) Add to your listing criteria that you will only accept backscatterer
> >referrals from mailboxes protected by forgery detection methods
(currently
> >SPF and/or DK/DKIM), and follow through by implementing such.
>
> Why should i care about SPF, DKIM and potential others?
Because those things tell us when messages are forged. As your list is a
list of systems that have sent NDRs in response to forged messages, you
can't have any meaning to your list until you have a way to detect a forged
message in the first place. These are the forgery detection methods which
are available.
> It is a known fact that those can not be used by anyone by design.
That's the stupidest comment you have made yet.
> >Either of those steps will fix the DEFECT in your listing requirements
as
> >compared to the goal you claim they enforce. Otherwise, your list
remains
> >open to false positives as noted and therefore, it is disingenuous.
>
> I told it multiple times:
> There is no defect, it is the listing criterias. Deal with it.
The goal of your listing criteria is to list "misbehaving" servers.
Servers which are fully compliant with the Internet e-mail standard (STD
10) are NOT "misbehaving." Your criteria are defective as they permit
servers properly behaving within the standard to get listed (as previously
demonstrated).
> >I have told you the problem with your criteria. I have told you the
> >solution, too. Why won't you implement the solution? It's easy....
>
> What you call a solution is nothing than inaceptable.
> We already have a solution ... list and block those that backscatter ....
But your list includes those who have NOT backscattered too. That's the
problem.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:h98it2$2se$1...@news.eternal-september.org...
>> D. Stussy wrote:
>> >
>> > When the list includes servers that have sent VALID REQUIRED NDRs to
>> > NON-FORGED senders that did not originate spam, the list will NEVER
>> > be a backscatterer list as their designer(s) intended.
>>
>> Why should *I* care whether they originated (whatever you define as)
>> spam? If they might send NDRs to me, when I sent them nothing, then I
>> could well have a use for a list that includes them. Regardless of
>> definitions.
>
>As the original message wasn't forged and wasn't spam, YOU DID SEND them
>something (or authorized someone else to send on your behalf). YOU
>PERMITTED IT TO BE SENT IN THE FIRST PLACE.
The original message was forged (claimed to have been sent by someone
who didn't send it). It was spam. He didn't send them anything. He
didn't authorize anyone else to send anything in his name.
YOU claim that someone else is authorized to send in his name.
HE never permitted it to be sent; it was sent without his permission
or even knowledge.
But the definitions don't matter.
I don't want NDRs for mail that I didn't send. I don't care if you
claim the actual sender was authorized to forge my address. I don't
care if 57 RFCs say the spammer was authorized to forge my address.
The issue is quite simple: I do not want to receive the NDRs. In
achieving that desire, I find a list of IP addresses that emit NDRs of
the type I don't want to receive to be quite useful.
Now, are you going to try to claim that I can't want what I say I
want? (Hint: There's exactly one person in the universe who is
definitive in stating my desires, and it isn't you.)
Seth
Michelle Sullivan
>
> If you follow best practices then you will not get listed.
Not true. My mail servers follows *BEST PRACTICES* yet one still gets
listed (discussed elsewhere in these threads.)
Best practices says you *should* minimize backscatter. It does not say
you *must* eliminate it.
Note: Whether the OP is minimizing or not is irrelevant to my post here,
and should not be used to create argument in favour of sending backscatter.
Some cases of backscatter are unavoidable, most are avoidable (or should
be avoidable.) Following best practices you would stop all the
avoidable backscatter, and minimize the unavoidable backscatter. Over
quota and user unknown are avoidable backscatter in *all* cases.
Shells
Rob
>>1) Publish your own RFC to get the standards changed so that off-host NDRs
>>are forbidden.
>
> Why should i waste my time to write an RFC?
> You know what an RFC is, do you?
> RFC = Request For Comments
> When it comes to backscatter, i just list those abusers instead of requesting
> them for comments.
Writing an RFC and getting it accepted as a standard means that people
will try to conform to it. Right now you are just shouting your own
opinion around on the net and almost nobody listens. When you write a
standard, more people will listen and you can maybe move from blocking
half the world to getting the problem (that you define) resolved.
>>I have told you the problem with your criteria. I have told you the
>>solution, too. Why won't you implement the solution? It's easy....
>
> What you call a solution is nothing than inaceptable.
> We already have a solution ... list and block those that backscatter ....
Here at least you admit that you actually are involved with blocking!
That is a big improvement over the "we are only listing, not blocking" meme.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>That's not how SMTP systems currently work. The MDA (mail delivery agent)
>does NOT get the message until it's been accepted. There's also no
>guarentee that the mailbox will even be on the same physical machine as the
>accepting MTA.
The MDA can get the message before *the sender machine* has been told
that the message was "accepted". The return code from the MDA can be
used by the SMTP server to determine what code to return to the
sender.
That depends only on the MTA and the MDA being able to communicate.
If they can't, you have bigger problems.
Seth
MrD
> "MrD" <mrdem...@jackpot.invalid> wrote in message
> news:h98it2$2se$1...@news.eternal-september.org...
>> D. Stussy wrote:
>>> When the list includes servers that have sent VALID REQUIRED NDRs
>>> to NON-FORGED senders that did not originate spam, the list will
>>> NEVER be a backscatterer list as their designer(s) intended.
>> Why should *I* care whether they originated (whatever you define
>> as) spam? If they might send NDRs to me, when I sent them nothing,
>> then I could well have a use for a list that includes them.
>> Regardless of definitions.
>
> As the original message wasn't forged and wasn't spam, YOU DID SEND
> them something
NO.
Read it again: I'm speaking specifically of the case when I didn't.
> (or authorized someone else to send on your behalf).
NO.
Nobody is authorised to send emails using any of my email addresses,
either implicitly or explicitly. Neither SPF nor DKIM can perform any
kind of authorisation unless they have actually been deployed. There is
no such thing as authorisation through inaction, whatever you may think.
> YOU PERMITTED IT TO BE SENT IN THE FIRST PLACE.
That's "permit" as opposed to "prevent"? How was I supposed to prevent it?
I "permitted" it without knowing who the real sender is, nor that they
intended to send it, nor what its content was? That's another word for
the Stussy Lexicon, then, I guess.
--
MrD.
http://ipquery.org
E-Mail Sent to this address will be added to the BlackLists
> On Mon, 21 Sep 2009 16:42:22 +0000, D. Stussy wrote:
>> When the list includes servers that have sent VALID
>> REQUIRED NDRs to NON-FORGED senders that did not
>> originate spam, the list will NEVER be a backscatterer
>> list as their designer(s) intended.
>
> I think the list is exactly as the designers intended,
> you just happen not to agree with their design.
Nor the rest of the worlds definitions of valid, forged,
senders, backscatter, spam, ...
Not to mention lack of proof of any of his imagery claims.
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
D. Stussy
> On Mon, 21 Sep 2009 16:42:22 +0000, D. Stussy wrote:
> > When the list includes servers that have sent VALID REQUIRED NDRs to
> > NON-FORGED senders that did not originate spam, the list will NEVER be
a
> > backscatterer list as their designer(s) intended.
>
> I think the list is exactly as the designers intended, you just happen
> not to agree with their design.
Wrong. Their design does not match their stated goal. The design permits
listings that lie OUTSIDE of their goal. That's the problem.
Their goal is to list "misbehaving" systems that send NDRs.
However, some NDRs are REQUIRED under the standards, and standards
compliance is NEVER misbehavior. By listing systems that have sent NDRs
when required to (especially in response to non-forged, non-spammy/virused
original messages), their criteria directs the listing of systems that have
NOT misbehaved, and therefore the goal is not reached. By accepting
reports for listing from mailboxes receiving NDRs which are not protected
against forgeries, they contaminate their database of "misbehavers," again
violating their goal.
If they wish to list systems that send NDRs (even when required to) as
misbehaving, a change in the standards is required (to forbid all NDRs).
The list administrators have NOT even proposed a standards change. That is
where they are additionally wrong.
Michael Deutschmann
> "Michael Deutschmann" <mic...@talamasca.ocis.net> wrote in message
> news:%XIst...@khar-pern.talamasca.ocis.net...
> > capacity when setting quotas; you have to pay more for hard-disk than you
> > believe you should. We *know that*. We just *don't care*.
>
> Then you enter the condition where you may falsely reject messages that you
> actually could have accepted. You've traded one problem for another. That
> doesn't help.
Ah, you've almost got it.
This new problem, the "false-positive" refusal of mail that might or might
not be able to fit in the MDA's hard disk space, does not lead to
backscatterer listings, and does not cause you to break RFCs.
So backscatterer and friends are quite happy to *impose* that problem on
you. Since, as you've argued already, the only other options are to break
RFC by blackholing mail, or to risk backscattering perfect forgeries.
Note that you can minimize this in practice by having lots of hard disk
space. Unless your users like to mail around DVD images, the cost today
would be minimal.
---- Michael Deutschmann <mic...@talamasca.ocis.net>
D. Stussy
news:h993s0$1lt$1...@nemesis.sorbs.net...
> ...
> I could be wrong, but I think there are a lot of cleaver [sic] people
here
> that are caught up in the hysteria and hype surrounding backscatter and
> how bad it is. I have been one of the people to speak out against it,
> and indeed I have even listed some of the worst servers as spam senders
> in SORBS quite deliberately (particularly when they don't even respond
> with RFC compliant bounces, and return the entire spam in the bounce.)
I have not said that backscatter isn't bad.
What I have said is two-fold:
1) People have to take responsibility FOR THEMSELVES FIRST in preventing
themselves from being victims of backscatter. That means that if you don't
want it, you take steps to prevent it - by using at least one of the
forgery detection technologies commonly available. It's wrong to report
others for your OWN FAILINGS.
2) Only AFTER one has taken steps to prevent from happening and it still
happens, ONLY THEN the mailbox owner has the right to report backscatter to
any "misbehaver blacklist."
> I have been the recipient of many backscatter bombs (backscatter
> attacks) where I have received thousands if not millions of bounces in
> hours leaving me to clean up the mess of bandwidth, blown out mailboxes
> etc etc for hours. SO I CAN TALK ABOUT THIS WITH AUTHORITY.
You're not the only one. However, the last time it happened to me was
September 2003; a time before the forgery detection technology existed.
Since then, it has not happened. If it's happened to you after 2004, then
you're doing something wrong.
> Backscatterer.org was a good idea, but it doesn't take into account best
> effort which I think is its major failing - however determining best
> effort is quite difficult so I can understand that policy. It should
> take into account RFC compliant mail servers in a better way than those
> that are not. It should also take into account those servers that do
> 554 unknown users, and tempfail/permfail over quota users at SMTP time.
> It should also take into account servers that whilst they have to have
> auo-responders everything has been done to minimize any possible abuse.
I agree that the concept was a good idea. However, its deployment FAILS.
As for your comments about issuing a "554 during SMTP," you're clearly
misguided. Such a response is a rejection which never causes the receiving
server to even enter a state where it would consider issuing an NDR and
therefore it never backscatters.
Autoresponders themselves are a separate issue. However, for an
autoresponse to be sent in reply to a forged message means that the forgery
status was either never checked or was checked and ignored, and that is
exactly the type of misbehavior that the backscatterer list should list.
Note that such a proper blacklisting does NOT include when the receiver
checked for forgery status and found NO METHOD USED. The current
presumption under the standards is that messages are presumed to be
authentic unless shown not to be - and with no method used, they CANNOT be
shown to be forged.
> There are servers out there that should be blocklisted to hell and back
> for the way they are setup. There are also other servers out there that
> should not be listed for backscatter as their admins had done everything
> possible to minimize backscatter.
That sounds very much like an admission that the false positive issue I
raised months ago actually exists.
> During the attacks on my servers by far the worst offenders were
> "Unknown User", followed a close second by "Over Quota"... this
> accounted for over 95% of the attack. The largest portion of the
> remaining 5% were out-of-office auto responders, of which most sent
> small messages (one or 2 lines) only once. Some send 100's of messages
> because they responded every time they received an email (they should be
> blacklisted to hell and back.) I don't recall ever seeing a 'Data
> Format Error' or 'No space on device' response in the attacks.
So, for 95% of the attack, you did the correct thing and rejected the
messages during SMTP. However, for 5%, you still let the message in so the
autoresponder could reply. If you knew the message was forged, why did you
let it in at all? Sounds as if you're misconfigured.
> Probably the most annoying were the systems that sent the over quota,
> because they kept trying to deliver the messages for several days and
> were kind enough to let me know that they couldn't and they would
> continue re-trying for "x" days...
>
> Summery/Point of this message....? I don't know there is one it could
> be a rant, I think backscatterer.org was a good idea, I think it should
> evolve, but I'm one to talk, I haven't evolved SORBS in a long time...!
> In the current state, I won't use it, and I don't recommend anyone to
> use it (in fact I actively discourage people to use it... just like some
> do with SORBS.)
Too bad about SORBS.
Backscatterer should FIX its defective criteria. It must accept reports
only from mailboxes (including traps) which are forgery-detection
technology protected, and reject or ignore all other reports. Only then
will the list be clear of [new] false positive listings.