Blacklist checks all MTA in header not just the one doing the final delivery

[israel...@gmail.com]

Greetings.

I got a mail rejected today saying that my mail-server was blacklisted. It however turned out the receiving MTA checks all hops in the mail-header and the address blacklisted is my dynamically assigned home-address (from my ISP).
And since I an MSA to send mail that address will be punched into the header.

I think this is a wrong behaviour and that blacklisting only should apply to the MTA doing the final delivery, but I'd like a second opinion.

Brgds Jonas

[Mail Man]

Yes, the blacklist should only apply to the IP performing the
SMTP-connect. To be checking all IP's found in the header is
ridiculous.

What is the name of the machine performing the rejection?

[Anonymous]

My opinion (and that of eff.org) is that rejecting a message on the
sole basis of IP address is wholly unethical. *Every* RFC-compliant
message should be delivered.

DNSBLs are a sloppy and reckless attempt at spam control. They are
used by large corporations looking to save every buck possible on
their server load costs. Of course the price is paid in quality of
service to their unwitting customers.

There is *one* competent (and ethical) way to use a DNSBL:

After accepting a message for delivery, during the content analysis
phase that determins whether the message will go to a spam folder,
a DNSBL improves the scoring, assigning an appropriate weight to the
message.

[Anonymous]

[Mail Man]

The fool Anonymous (mixmaster @ remailer.cpunk.us) double-posted:

> My opinion (and that of eff.org) is that rejecting a message on the
> sole basis of IP address is wholly unethical.

Fuck your ethics.

It's a god-damn war out there, with ISP's administering their networks
like complete jack-asses by allowing residential customers and others
with dynamic IP's to be allowed to emit port-25 spam direct-to-mx to the
outside world.

> *Every* RFC-compliant message should be delivered.

I shit-can SMTP connectiond from about 2-dozen /8 IP-netblocks.
Connection REFUSED.

I smile when I look at my daily logs and see hundreds of CONNECTION
REFUSED entries.

And bleeding-heart liberal fucks like you don't like it. Well fuck you,
and fuck all those boneheads with infected PC's on dynamic IP's that
DON'T EVEN KNOW their pc is trying to send me spam.

And the increasing number of fly-by-night server hosts that are busy
renting their servers to spammers.

> DNSBLs are a sloppy and reckless attempt at spam control.

I don't use externeral or third-party DNSBL's.

For the past 3 years, for each spam I get from IP address a.b.c.d, I add
a.b.0.0/16 to my server's internal reject list. In addition to about 2
dozen /8 entries already there.

I have roughly 9000 such entries in my server's internal list, adding
about 5 each day.

[Richard Starkey]

> > My opinion (and that of eff.org) is that rejecting a message on the
> > sole basis of IP address is wholly unethical.
>
> Fuck your ethics.

I appreciate your honesty. Usually more reading is required to find
that someone has no sense of ethics.

> It's a god-damn war out there

Yes, and some dipshits are torching friendlies with reckless
disregard.

> with ISP's administering their networks like complete jack-asses by
> allowing residential customers and others with dynamic IP's to be
> allowed to emit port-25 spam direct-to-mx to the outside world.

You're confused about the client/supplier relationship. If the
supplier refuses to supply, their client walks. And rightly so.

The naive jack-asses here are those who try forcing residential users
to needlessly share their legitimate message payloads with a 3rd
party (generally a large corporation without regard to privacy).

> I smile when I look at my daily logs and see hundreds of CONNECTION
> REFUSED entries.

Ignorance is bliss.

Indeed some nutters just like roasting people regardless of whether
they can be identified as friend or foe. It's reckless and stupid.

> And bleeding-heart liberal fucks like you don't like it. Well fuck
> you, and fuck all those boneheads with infected PC's on dynamic IP's
> that DON'T EVEN KNOW their pc is trying to send me spam.

The problem is that we have boneheads who naively *help spammers* in
the battle by directly causing denial of service against the very same
traffic that's threatened by spam.

The evangelical anti-spammers are not only part of the problem,
they're actually a bigger proportion of the problem than spam itself.

To be clear, the /problem/ is DoS against non-spam. Spam causes lags
on servers (degregation of service), while morons with malconfigured
servers directly *deny* service to non-spam senders. This is where
the most damage is done.

[Richard Starkey]

> There is *one* competent (and ethical) way to use a DNSBL:
>
> After accepting a message for delivery, during the content
> analysis phase that determins whether the message will go to a
> spam folder, a DNSBL improves the scoring, assigning an
> appropriate weight to the message.
>

> ================
> And YOU are part of the problem:

You misunderstand the problem. The problem is availability.

> By accepting the message before performing the scan, you then must
> reply if you reject the message.

Bullshit. Recipients have a *choice* whether to reply to spam.
Furthermore, it's a bad idea to do so.

> Doing so to spam causes backscatter.

My point exactly. You're making my case.

> Any COMPETENT system performs its content analysis BEFORE accepting
> any message for delivery or forwarding.

Translation: competent admins can predict the future, and read the
message before it's sent.

You obviously don't understand how SMTP works. After the content is
transmitted, the transaction is over. The content cannot be analyzed
until it is received. After it's received, you don't get to change
the status after the fact - it's not in the protocol.

So what naive admins do is use a DNSBL to act *before* they see the
content, unwittingly denying service on legit messages, causing more
damage than spammers. Thus creating a bigger problem and defeating
the point of countering spam in the first place.

[Mail Man]

Richard Starkey wrote:

> > It's a god-damn war out there
>
> Yes, and some dipshits are torching friendlies with reckless
> disregard.

What exactly is a friendly?

Every /16 IPv4 net-block gets exactly ONE chance to send my company an
email. If its a legit email, an inquiry about our products or service,
then that /16 net-block gets special treatment in the future from me. I
will be careful when subdividing that block if something I consider to
be comes from it in the future.

If a new legit prospective customer can't send us mail because of a
pre-existing block - guess what. Our contact page includes our phone
number, and an alternate gmail contact address that gets forwarded to us
automatically. When the potential customer establishes contact, I will
sort out what his sending IP address is and will poke a hole in my
server's list to allow future contact. This happens maybe once or twice
a year. Our products are specialized enough such that prospective
customers are not disuaded by the initial rejection by our server on the
rare occasions it does happen.

> > with ISP's administering their networks like complete jack-
> > asses by allowing residential customers and others with
> > dynamic IP's to be allowed to emit port-25 spam direct-to-
> > mx to the outside world.
>
> You're confused about the client/supplier relationship.

There is no confusion. Anyone offering residential internet
connectivity (and connectivity to any customer given a dynamic IP
address) should block said customer's ability to communicate (send
packets) beyond the ISP's network on port-25. As a class of users, that
class has absolutely no business sending direct-to-mx from their IP to
the outside world on port-25. As a corollory, the ISP must therefore
provide an MTA or smart-host operating on port-25 for said customers to
send e-mail to the outside world.

> The naive jack-asses here are those who try forcing residential
> users to needlessly share their legitimate message payloads with
> a 3rd party (generally a large corporation without regard to
> privacy).

Wrong. It is no crime or hardship to tell residential and dynamic IP
customers to use the ISP's MTA or smart-host when sending mail on
port-25. If those customers want to use gmail or yahoo or some other
piece-of-crap server, they are free to do so on some other standard port
other than 25.

> > I smile when I look at my daily logs and see hundreds of
> > CONNECTION REFUSED entries.
>
> Ignorance is bliss.

You either don't operate a server or you don't have email addresses that
have been harvested a decade ago used by people that are long gone from
your organization but that spammers still insist on sending mail to.

> Indeed some nutters just like roasting people

I don't roast people.

I don't consider a trojanized Windoze PC or a spammer that is renting
some pos linux box to be a "person" in the sense of being an originator
of "real" email.

> regardless of whether they can be identified as friend or foe.
> It's reckless and stupid.

I have more than 14 years of looking at email logs, headers, and spam to
know that if a spam comes in on any given /16 net-block, 99 times out of
100 there will be no actual, legit SMTP servers operating out of that
net-block.

I don't consider a trojanized zombie Windoze PC coded with rudimentary
SMTP software to be a "legit" email server. Maybe you do. Maybe you
happily absorb dozens or hundreds of spams per day, waiting to receive
that one single valid email from a residential assignment block operated
by verizon, charter, comcast, telecom italia, orange, vodaphone, etc.

> > And bleeding-heart liberal fucks like you don't like it. Well
> > fuck you, and fuck all those boneheads with infected PC's on
> > dynamic IP's that DON'T EVEN KNOW their pc is trying to send
> > me spam.
>
> The problem is that we have boneheads who naively *help spammers*
> in the battle by directly causing denial of service against the
> very same traffic that's threatened by spam.

Do you deny that the single largest source of spam is from trojanized
residential and soho windoze botnets?

How is the outright blocking of large subnets that you know are
allocated to residential and dynamic IP customers somehow a threat to
legit servers that you know are not operating on those nets?

> The evangelical anti-spammers are not only part of the problem,
> they're actually a bigger proportion of the problem than spam
> itself.

False.

Your battle is not with me, or other entities that operate their own
SMTP servers (a diminishing crowd) who take a scorched earth approach to
the IPv4 landscape when it comes to spam.

Take up your cause with the big ISP's and tell them to block port-25 on
their network boundary so their customers either use some other port or
use the ISP's smart-host MTA.

> To be clear, the /problem/ is DoS against non-spam.

In our case, a single lost sale can be worth $20,000. That's real
coin. In over 14 years of operating our SMTP server, I've been
adjusting it's blocking settings trying to find the right strategy to
maximize spam-shit-canning while achieving ZERO erroneous denials.

For the past 4 years, I block entire countries and continents outright -
countries that I know we will never do business with.

I used to block /24 C-classes, but it was futile. That's how I came to
realize and experience some real effectiveness at /16 blocking.

Those are the dynamics that inform and drive the administration of my
server.

You've done nothing to describe your experience and the needs of your
organization when it comes to email service and anti-spam strategies.

[Mail Man]

"D. Stussy" wrote:

> Translation: competent admins can predict the future, and read the
> message before it's sent.
>
> You obviously don't understand how SMTP works. After the content is
> transmitted, the transaction is over. The content cannot be analyzed
> until it is received. After it's received, you don't get to change
> the status after the fact - it's not in the protocol.

Beyond refusing the SMTP connection based on the IP of the remote
machine, you can block (end the SMTP session) and prevent the reception
of the message body based on

- ehlo/helo argument (some can be diagnostic for spam)
- return path (transmitted before the message body)
- recipient (again this is transmitted before the message body)

Starkey wrote:

> So what naive admins do is use a DNSBL to act *before* they see
> the content, unwittingly denying service on legit messages,
> causing more damage than spammers. Thus creating a bigger
> problem and defeating the point of countering spam in the
> first place.

A DNSBL list should not contain the IP address of a "real" smtp server.
A real SMTP server is a machine that is consciously administered, owned
or operated by a human being for the purpose of transmitting/receiving
mail.

A machine that has been co-opted to act as a mail server without the
knowledge of the machine's owner/operator does not meet my definition of
a "real" smtp server. I would call those "spam servers" or "trojan
servers".

Further more, any single IP or range of IP's known to contain "real"
servers that otherwise transmit mail with the same "qualities" of spam
or trojan servers and therefore have the same reputation as spam servers
can be included in a DNSBL list.

As much as sometimes I would like to, I do not block "popular" webmail
servers such as gmail, yahoo, hotmail (or what-ever it's current
incarnation is called) for obvious reasons.

Here is a text copy of my server's current SMTP IP blocking list, sorted
by IP address, with all 40-odd /8 A-classes listed first.

My smtp server (running post.office) does not have the ability to
connect or interface with a DNSBL - and I'm not sure that I would even
use a DNSBL even if it could. Instead I have built up my own static
blocking list over time.

I welcome any discussion or inquiry regarding any IP that you feel is
used by a legit server that is being blocked by this list.

The list can be downloaded from here:

http://snk.to/f-ctjiqk9t

[Nomen Nescio]

>> > By accepting the message before performing the scan, you then must
>> > reply if you reject the message.
>>
>> Bullshit. Recipients have a *choice* whether to reply to spam.
>> Furthermore, it's a bad idea to do so.
>>

> Not according to RFC 5321 and STD 10:

You've got several things wrong here. First of all, an admin has
choice in RFC-compliance. It's a bad idea to deviate, but the option
is there. Your claim fails to counter what you quoted.

> Once you accept the message, you MUST deliver or DSN it.

Not in terms of RFC 5321:

rfc> Utility and predictability of the Internet mail system requires
rfc> that messages that can be delivered should be delivered,
rfc> regardless of any syntax or other faults associated with those
rfc> messages and regardless of their content.

You *must* deliver the message in order to conform to RFC 5321
"shoulds" and "shalls". Of course, compliance is your choice.
Strictly speaking, lousy admins who do not take the advice of the RFC
have these two rfc-permitted-but-discouraged options:

* DNSBL reject
* accept and blackhole the messages (see below)

BTW, these two options are only rfc-permitted for malformed messages.
Having an IP address that's on a blacklist does not in itself make a
message "malformed".

> A recipient is NOT permitted to drop an accepted message.

Wrong again, and this time it's unfortunate. Silent discards
are /permitted/ (only discouraged) by the RFC:

rfc> dropping mail without notification of the sender is permitted in
rfc> practice. However, it is extremely dangerous and violates a long
rfc> tradition and community expectations that mail is either
rfc> delivered or returned. If silent message-dropping is misused, it
rfc> could easily undermine confidence in the reliability of the
rfc> Internet's mail systems. So silent dropping of messages should
rfc> be considered only in those cases where there is very high
rfc> confidence that the messages are seriously fraudulent or
rfc> otherwise inappropriate.

> Recipients don't get the choice for what happens inside the MTA.

Obviously we know this to be wrong, even within the rules of the RFC.

You know just enough to search for the relevant RFC number, but you
don't actually understand it. You've simply assumed the RFC would
agree with your expectations.

In the future, please quote the RFC clause that you think supports the
claim. Also, learn to quote properly, only the text you're replying
to, and using leading quote marks.

> Wrong: One can still issue an error code at the end of the DATA
> phase (where the body is transmitted), thus rejecting the message.
> The message is analyzed AS it comes in and before the result code
> for the DATA phase is returned to the sender. Rejecting spam at
> this point does not mean that the recipient has accepted the
> message. Just because the sender has sent the message doesn't mean
> the transaction is over. It's over when the recipient issues the
> result code.

Can you name a server that does this? Or a specific e-mail provider?

>> So what naive admins do is use a DNSBL to act *before* they see the
>> content, unwittingly denying service on legit messages, causing
>> more damage than spammers. Thus creating a bigger problem and
>> defeating the point of countering spam in the first place.
>>

> You ASSume that one is using a DNS-based-list as a hard
> accept/reject switch, instead of in a point system by a more
> advanced filter (e.g. SpamAssassin).

Of course that's my assumption-- that's in fact the premise for the
abuses that I'm opposing.

You've lost sight of the thread. As I said already, using a DNSBL as
part of content analysis is the ethical and effective way to use
DNSBLs. Spamassassin scoring is both RFC-compliant and
eff.org-ethics-respecting.

[Richard Starkey]

>> You *must* deliver the message in order to conform to RFC 5321
>> "shoulds" and "shalls". Of course, compliance is your choice.
>> Strictly speaking, lousy admins who do not take the advice of the
>> RFC have these two rfc-permitted-but-discouraged options:
>>
>> * DNSBL reject
>> * accept and blackhole the messages (see below)
>>
>> BTW, these two options are only rfc-permitted for malformed messages.
>> Having an IP address that's on a blacklist does not in itself make a
>> message "malformed".

> ----------------
> I didn't say that having a blacklisted IP address cited in a message
> did (make it malformed).

Again, you've lost the thread, and also in your "blacklisted IP
address _cited in a message_" comment further demonstrates your
unawareness to how blacklisted IPs are identified when connections are
blocked. The IP is not "in a message", and in many cases it's not
even on the envelope.

Regardless, an IPs presence on someones blacklist *does not constitute
a malformed message*. RFC 5321 allows for malformed messages to be
rejected, not well-formed messages.

> All I said is that an RFC-compliant server (as that was the context
> in which I replied) must deliver or DSN a message it accepts.

Yes, that's what I corrected you on. I quoted you, and stated in
detail complete with the RFC quote that states DNSing a message is
non-compliant. You're still not getting it.

You are using MS Windows. Your communication problems are perhaps in
part due to MS tools (which don't quote properly and set users up to
top reply). Responding with a general restatement of position without
actually addressing what was said yields you nothing.

> And you don't seem to understand the difference between users and
> administrators.

This is a red herring. You're apparently confused by the fact that
the user and admin are sometimes the same person. In those cases,
it's the admin role that's relevant.

>> >> So what naive admins do is use a DNSBL to act *before* they see
>> >> the content, unwittingly denying service on legit messages,
>> >> causing more damage than spammers. Thus creating a bigger
>> >> problem and defeating the point of countering spam in the first
>> >> place.
>> >>
>> > You ASSume that one is using a DNS-based-list as a hard
>> > accept/reject switch, instead of in a point system by a more
>> > advanced filter (e.g. SpamAssassin).
>>
>> Of course that's my assumption-- that's in fact the premise for the
>> abuses that I'm opposing.
>>
>> You've lost sight of the thread. As I said already, using a DNSBL
>> as part of content analysis is the ethical and effective way to use
>> DNSBLs. Spamassassin scoring is both RFC-compliant and
>> eff.org-ethics-respecting.

> ----------------
> You seem to think that scoring systems (including scoring DNSBL
> results) can be employed only AFTER the message is accepted, so
> you're just as clueless as you sound.

[facepalms] You've got 3 logical fallacies in that one sentence. The
ad hominem shows your despiration. The red herring is due to the
scenario you describe being entirely orthoganol to my thesis.

And worse, you've created a straw man. I've already stated that
content analysis is the competent, RFC-compliant and
eff.org-ethics-respecting approach. Yet you continue to attack with
an idea that I've already endorsed.

If you're going to continue, you need to get some basics about who is
advocating what. Go back, re-read the thread, and come to grips with
what the problem is.

In short, it's the incompetent and reckless idea of blocking
RFC-compliant connections on the pure basis of IP address *prior* to
analyzing content.

[Anonymous]

> You're obviously replying to someone else, because you're including
> things I didn't say.

I replied to what I quoted. It doesn't matter who wrote it.

If you didn't write what's quoted, then obviously you're not in the
conversation.

[Mail Man]

On Sun, 6 Apr 2014, Anonymous wrote (in alt.comp.issues.spam):

> I appreciate your honesty.

Message-ID:
<3a6d5c799247f9c7...@remailer.paranoici.org>

(...)


Why is this being reposted again?

Why is an anonymous fool re-posting a reply here that was originally
made on March 25 in alt.comp.mail.misc?

==============
Re: Blacklist checks all MTA in header not just the one doing thefinal
delivery
Date: Tue, 25 Mar 2014 21:43:04 -0400 (EDT)
From: Richard Starkey <nob...@ringo.jpunix.net>
Newsgroups: alt.comp.mail.misc

Message-ID:
<3a6d5c799247f9c7...@ringo.jpunix.net>

Comments:
This message did not originate from the Sender address above. It was
remailed automatically by anonymizing remailer software. Please report
problems or inappropriate use to the remailer administrator at
<ab...@ringo.jpunix.net>.
==============

WTF?

What the hell is going on here?

Who the hell is Richard Starkey, and did he post both of the
above-mentioned messages?

[Jack Ryan]

> > > It's a god-damn war out there
> >
> > Yes, and some dipshits are torching friendlies with reckless
> > disregard.
>
> What exactly is a friendly?

A sender of non-spam. Solicited. Alice says to Bob "please email me
your phone number", and Bob e-mails Alice his phone number.

> Every /16 IPv4 net-block gets exactly ONE chance to send my company
> an email.

If you're basing this wholly on IP address, you're doing something
incompetent. IPs change. Although there are higher levels of
incompetence.. many will reject all IPs that simply appear on someones
blacklist of IPs that are dynamic, for example.

> If a new legit prospective customer can't send us mail because of a
> pre-existing block - guess what. Our contact page includes our
> phone number, and an alternate gmail contact address that gets
> forwarded to us automatically.

If it goes to that, you've already violated RFC 5321, and done more
damage than spam. Offering other means isn't real relevant to the
topic, and generally beyond the motivation of potential clients who
find it backwards for the client to bend over backwards to serve the
supplier.

Many clients (quite rightly) don't have the patience to do extra work
to give business. I get the impression you work in a country that's
not very capitalistic.

It's also amusing that gmail is your e-mail backup, because google is
even sloppier than your org. Google blocks IPs simply for being
dynamic.

> > > with ISP's administering their networks like complete jack-
> > > asses by allowing residential customers and others with dynamic
> > > IP's to be allowed to emit port-25 spam direct-to- mx to the
> > > outside world.
> >
> > You're confused about the client/supplier relationship.
>
> There is no confusion. Anyone offering residential internet
> connectivity (and connectivity to any customer given a dynamic IP
> address) should block said customer's ability to communicate (send
> packets) beyond the ISP's network on port-25.

This nonsense proves your misunderstanding about the client/supplier
relationship. Getting a partial/nannied service is an *disservice*.
It's *lack of service*. Would be comparable to an auto mechanic
installing a governor or making an adjustment to slow down your car.
No thanks, I'll pay another mechanic.

> As a class of users, that class has absolutely no business sending
> direct-to-mx from their IP to the outside world on port-25.

Bullshit.

An ISP has no business snooping on users email headers, forcing them
to share their traffic, and forcing them (needlessly) to trust the ISP
to deliver the message, trust the protection of the content, and
report all problems downstream.

It's also dumb security. It imposes extra trust in situations where
trust is otherwise unnecessary.

> As a corollory, the ISP must therefore provide an MTA or smart-host
> operating on port-25 for said customers to send e-mail to the
> outside world.

By what authority? Oh, what a privilege to have a facility in place
to nanny me, and view my mail traffic. No thanks. I don't value this
kind of "help" or "service".

If I'm the customer, I'll be the judge of what transport layer
encryption is sufficient.

> > The naive jack-asses here are those who try forcing residential
> > users to needlessly share their legitimate message payloads with
> > a 3rd party (generally a large corporation without regard to
> > privacy).
>
> Wrong. It is no crime or hardship to tell residential and dynamic
> IP customers to use the ISP's MTA or smart-host when sending mail on
> port-25.

That's non-sequitur logic. It's of course a bad idea for security
conscious senders to needlessly share information with a 3rd party.
It doesn't have to be a "crime" or "hardship" to be a *bad idea*. So
you've created a false contradiction here.

BTW, denial of service is in fact a crime in some jurisdictions. And
in a subset of those jurisdictions, it's even enforced. Germany in
particular. In Germany it is a crime to block or interfere with
communications between two parties -- and rightly so.

> I don't consider a trojanized zombie Windoze PC coded with
> rudimentary SMTP software to be a "legit" email server.

Of course. There are intelligent ways to determine if a message came
from such a host, and there are foolish, reckless false-positive prone
ways.

> > The evangelical anti-spammers are not only part of the problem,
> > they're actually a bigger proportion of the problem than spam
> > itself.
>
> False.

Of course, the most damage done to legit mail is denial of service.
If a message is 3-300 seconds slow from spam saturation, that's much
*less* damage than outright denial of service.

The evangelical anti-spammers who use the incompetent and sloppy
techniques I've described are first and foremost missing the point
and causing the most damage.

> Take up your cause with the big ISP's and tell them to block port-25

You've misunderstood my position. If I *oppose* denial of service,
I'm not going to advocate it.

> > To be clear, the /problem/ is DoS against non-spam.
>
> In our case, a single lost sale can be worth $20,000. That's real
> coin. In over 14 years of operating our SMTP server, I've been
> adjusting it's blocking settings trying to find the right strategy
> to maximize spam-shit-canning while achieving ZERO erroneous
> denials.
>
> For the past 4 years, I block entire countries and continents
> outright - countries that I know we will never do business with.

You're not good for business. Your approach has you unwittingly
denying clients in the regions you intend to do business because you
have no means to know where all potential clients would proxy their
connection through.

When a seller blocks my IP on the basis of region (in a naive attempt
to make me expose my real IP), I walk. They don't really need my
business anyway - and nor have they earned it.

I don't want to be the client of suppliers who don't believe it's
their job to serve the client.

[Odiferous Flatulence]

> > > It's a god-damn war out there
> >
> > Yes, and some dipshits are torching friendlies with reckless
> > disregard.
>
> What exactly is a friendly?

A sender of non-spam. Solicited. Alice says to Bob "please email me
your phone number", and Bob e-mails Alice his phone number.

> Every /16 IPv4 net-block gets exactly ONE chance to send my company
> an email.

If you're basing this wholly on IP address, you're doing something
incompetent. IPs change. Although there are higher levels of
incompetence.. many will reject all IPs that simply appear on someones
blacklist of IPs that are dynamic, for example.

> If a new legit prospective customer can't send us mail because of a
> pre-existing block - guess what. Our contact page includes our
> phone number, and an alternate gmail contact address that gets
> forwarded to us automatically.

If it goes to that, you've already violated RFC 5321, and done more
damage than spam. Offering other means isn't real relevant to the
topic, and generally beyond the motivation of potential clients who
find it backwards for the client to bend over backwards to serve the
supplier.

Many clients (quite rightly) don't have the patience to do extra work
to give business. I get the impression you work in a country that's
not very capitalistic.

It's also amusing that gmail is your e-mail backup, because google is
even sloppier than your org. Google blocks IPs simply for being
dynamic.

> > > with ISP's administering their networks like complete jack-
> > > asses by allowing residential customers and others with dynamic
> > > IP's to be allowed to emit port-25 spam direct-to- mx to the
> > > outside world.
> >
> > You're confused about the client/supplier relationship.
>
> There is no confusion. Anyone offering residential internet
> connectivity (and connectivity to any customer given a dynamic IP
> address) should block said customer's ability to communicate (send
> packets) beyond the ISP's network on port-25.

This nonsense proves your misunderstanding about the client/supplier
relationship. Getting a partial/nannied service is an *disservice*.
It's *lack of service*. Would be comparable to an auto mechanic
installing a governor or making an adjustment to slow down your car.
No thanks, I'll pay another mechanic.

> As a class of users, that class has absolutely no business sending
> direct-to-mx from their IP to the outside world on port-25.

Bullshit.

An ISP has no business snooping on users email headers, forcing them
to share their traffic, and forcing them (needlessly) to trust the ISP
to deliver the message, trust the protection of the content, and
report all problems downstream.

It's also dumb security. It imposes extra trust in situations where
trust is otherwise unnecessary.

> As a corollory, the ISP must therefore provide an MTA or smart-host
> operating on port-25 for said customers to send e-mail to the
> outside world.

By what authority? Oh, what a privilege to have a facility in place
to nanny me, and view my mail traffic. No thanks. I don't value this
kind of "help" or "service".

If I'm the customer, I'll be the judge of what transport layer
encryption is sufficient.

> > The naive jack-asses here are those who try forcing residential
> > users to needlessly share their legitimate message payloads with
> > a 3rd party (generally a large corporation without regard to
> > privacy).
>
> Wrong. It is no crime or hardship to tell residential and dynamic
> IP customers to use the ISP's MTA or smart-host when sending mail on
> port-25.

That's non-sequitur logic. It's of course a bad idea for security
conscious senders to needlessly share information with a 3rd party.
It doesn't have to be a "crime" or "hardship" to be a *bad idea*. So
you've created a false contradiction here.

BTW, denial of service is in fact a crime in some jurisdictions. And
in a subset of those jurisdictions, it's even enforced. Germany in
particular. In Germany it is a crime to block or interfere with
communications between two parties -- and rightly so.

> I don't consider a trojanized zombie Windoze PC coded with
> rudimentary SMTP software to be a "legit" email server.

Of course. There are intelligent ways to determine if a message came
from such a host, and there are foolish, reckless false-positive prone
ways.

> > The evangelical anti-spammers are not only part of the problem,
> > they're actually a bigger proportion of the problem than spam
> > itself.
>
> False.

Of course, the most damage done to legit mail is denial of service.
If a message is 3-300 seconds slow from spam saturation, that's much
*less* damage than outright denial of service.

The evangelical anti-spammers who use the incompetent and sloppy
techniques I've described are first and foremost missing the point
and causing the most damage.

> Take up your cause with the big ISP's and tell them to block port-25

You've misunderstood my position. If I *oppose* denial of service,
I'm not going to advocate it.

> > To be clear, the /problem/ is DoS against non-spam.
>
> In our case, a single lost sale can be worth $20,000. That's real
> coin. In over 14 years of operating our SMTP server, I've been
> adjusting it's blocking settings trying to find the right strategy
> to maximize spam-shit-canning while achieving ZERO erroneous
> denials.
>
> For the past 4 years, I block entire countries and continents
> outright - countries that I know we will never do business with.

[Mail Man]

Jack Ryan wrote:

> > What exactly is a friendly?
>
> A sender of non-spam. Solicited. Alice says to Bob "please email
> me your phone number", and Bob e-mails Alice his phone number.

I don't expect to get "friendly" email directly (direct-to-mx to our
SMTP server) from machines connected to the internet on
dynamically-assigned IP addresses.

The VAST majority of IPv4 IP space is dynamically allocated, because the
vast majority of devices with internet connections are not servers.

> > Every /16 IPv4 net-block gets exactly ONE chance to send my company
> > an email.
>
> If you're basing this wholly on IP address, you're doing something
> incompetent. IPs change.

They change at a very slow rate. And the the odds that a netblock that
once sent me spam is now operating an smtp server from which I would
ever expect to get "friendly" mail is even more remote.

> many will reject all IPs that simply appear on someones
> blacklist of IPs that are dynamic, for example.

If the IP or IP-block in question _really_ is dynamic, then the ISP
should prohibit port-25 traffic from said IP or IP net-block from
reaching the internet beyond the ISP's gateway. It's just that simple.

Customers with dynamic IP's have no business running their own SMTP
server. For every such customer that really wants to AND has a legit
reason why he doesn't have a static IP, there are a million others that
don't know what an SMTP server is but are nonetheless running one the
form of a trojanized spambot.

> > If a new legit prospective customer can't send us mail because
> > of a pre-existing block - guess what. Our contact page includes
> > our phone number, and an alternate gmail contact address that
> > gets forwarded to us automatically.
>
> If it goes to that, you've already violated RFC 5321,

You should see the hundreds or thousands of "connection denied" entries
in my SMTP server's daily log entries from the god damn sewer pipe of
the precious IP's that you want to protect their ability to send spam.

> and done more damage than spam.

Oh, you fucking liberal asswipe.

I've damaged those poor spambots, I've hurt them because I've denied
them the ability to connect to my server.

Oh, I'm crying that I've damaged them so much.

> Offering other means isn't real relevant to the topic, and

and fuck you.

I'm describing the way that small companies that manage their own SMTP
server should operate. I'm going to publish the next version of my
super-excellent IP blocking list soon. Stay tuned.

> Many clients (quite rightly) don't have the patience to do extra work
> to give business. I get the impression you work in a country that's
> not very capitalistic.

Canada is far more capitalist than the USA has been for the past
decade. We're wiping your ass in all sorts of ways (economic, civil and
personal freedom, social, etc). The USA is a socialist basket case
now.

> It's also amusing that gmail is your e-mail backup, because
> google is even sloppier than your org. Google blocks IPs
> simply for being dynamic.

Good for them, because I dare you to give an example of getting legit
(friendly) mail direct-to-mx from a dynamic IP address.

Do you even know what direct-to-mx is?

> > Anyone offering residential internet connectivity (and connectivity
> > to any customer given a dynamic IP address) should block said
> > customer's ability to communicate (send packets) beyond the
> > ISP's network on port-25.
>
> This nonsense proves your misunderstanding about the client/supplier
> relationship. Getting a partial/nannied service is an *disservice*.

You are a complete dink.

Someone that is a customer of an ISP and has a single assigned IP
address (probably a dynamic IP) and uses a client like thunderbird,
outlook, etc to send mail, will simply tell their software to use
SMTP.their-ISP.com on port-25 to send mail. If their computer becomes
infected and part of a botnet, it won't be able to send spam
direct-to-mx (directly to the internet to the destination server)
because the ISP blocks port-25 to any destination other than
smtp.their-ISP.com.

If the customer wants to send mail through another SMTP server outside
of the ISP's network, then they use port 465 (or what-ever) and probably
use SSL and authentication.

Explain why what I've just described shouldn't be the way that things
work.

Explain why it would be some sort of hardship or handical for things to
work that way.

Explain if there is any lack of functionality at all for the ISP's
customers if things worked that way.

> It's *lack of service*. Would be comparable to an auto mechanic
> installing a governor or making an adjustment to slow down your
> car.

Clearly, you have zero understanding of the situation.

Anything leaving a dynamically-assigned IP address destined for port-25
on an external network (the cloud) is going to be spam, and shouldn't
even be allowed to reach the cloud in the first place.

> > As a class of users, that class has absolutely no business
> > sending direct-to-mx from their IP to the outside world on
> > port-25.
>
> Bullshit.
>
> An ISP has no business snooping on users email headers,

This is not snooping.

The ISP blocks (or should block) all packets that want to connect to
port 25 on an external IP (external to the ISP's network). No email
header-snooping. Anyone that wants their outgoing mail to be handled by
another server in the cloud simply connects to that server on another
port, like 465. Anyone that doesn't care how their outgoing mail is
handled would simply have their outgoing SMTP server pointed to their
ISP's outbound MTA or smart-host - on port 25, 465, etc. This is
standard stuff.

> and forcing them (needlessly) to trust the ISP to deliver the
> message,

Anyone who doesn't "trust" their ISP to deliver their message has
several options. If they have the technical means to operate their own
SMTP server, then there is no excuse for them not to have a static IP
address, where they can control and assign the rDNS lookup.

If they don't have a static IP, then they are fair game to have their
mail blocked by IP-based blacklists.

If they don't operate their own SMTP server, but instead want to use an
external server (yahoo, gmail, hotmail/live/etc) then they would use a
standard port like 465 (tell me which of those accepts connections on
port 25 anyways?)

> > As a corollory, the ISP must therefore provide an MTA or smart-host
> > operating on port-25 for said customers to send e-mail to the
> > outside world.
>
> By what authority? Oh, what a privilege to have a facility in
> place to nanny me, and view my mail traffic. No thanks.

What a crock. Port 25 offers no encryption, no privacy. You've failed
at your own argument.

Do you have an internet connection at home?

Does that connection have a dynamic or static IP?

When you compose and send mail from home, does your email client
directly connect to the recipient's mail server, or does it connect to
an intermediate SMTP server?

If intermediate server, is that server operated by you (located in your
home), or operated by your ISP, or is it somewhere else on the internet?

How exactly would you be harmed if your ISP blocked all OUT-BOUND
port-25 traffic at it's boundary with the internet?

If you connect to the interent via a single dynamically-assigned IP, you
have no business sending anything destined for port-25 on an external
network. There are PLENTY of options available to you in that case to
send mail with or without using your ISP's servers.

I dare you to give an example of anyone (home or soho) that connects to
the internet via a single dynamically-assigned IP that has a legit need
to send mail direct-to-mx (directly to the recipient's mail server)

OR

who can't (or don't) point their email client's outbound SMTP server to
their ISP's outbound MTA or (by using a port other than 25) to an
external smtp server (yahoo, gmail, hotmail, etc).

Don't be a coward. Give an example.

> If I'm the customer, I'll be the judge of what transport layer
> encryption is sufficient.

This has nothing to do with encryption.

My SMTP server receives mail for local accounts on port-25 (and ONLY
port-25) from any IP in the world that is not listed in it's blacklist.
To my knowledge, there is no encryption used when this mail is received.

Look.

I'm not the only one who feels that large ISP's should block port-25
out-bound at their network boundary.

Read this:

http://customer.comcast.com/help-and-support/internet/email-port-25-no-longer-supported/

=====================================

Introduction

Email is used for important communications and Comcast wants to ensure
that these communications are as secure and as private as possible. As
such, Comcast does not support port 25 for the transmission of email by
our residential Internet customers. Much of the current use of port 25
is by computers that have been infected by malware and are sending spam
without the knowledge of the users of those computers.

Why is Comcast Supporting Port 587?

The original/legacy email ports, 25 and 110, have been in use since the
inception of email and have limited or no security features. As a
result, port 25 has been used for the transmission of spam and malware
from infected computers for nearly a decade. Port 110 simply is not a
secure means of retrieving email. Port 995 provides SSL encryption when
downloading email.

It has been a long standing recommendation from M3AAWG, an international
community of anti-abuse professionals, and the Internet Engineering Task
Force (IETF), that port 25 be blocked. In an effort to provide our
customers with the greatest security when using email, Comcast
recommends the use of the industry-recommended port 587 with TLS/SSL
enabled. The recommendations from M3AAWG can be read here and you can
also view the IETF RFC 5068 and RFC 4409 (section 3.1, see below).

From RFC 4409:

3.1. Submission Identification

Port 587 is reserved for email message submission as specified in this
document. Messages received on this port are defined to be submissions.
The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional
restrictions or allowances as specified here. Although most email
clients and servers can be configured to use port 587 instead of 25,
there are cases where this is not possible or convenient. A site may
choose to use port 25 for message submission by designating some hosts
to be MSAs and others to be MTAs.
What Makes These Settings More Secure?

Port 587 further improves security through the use of required
authentication and recommended TLS/SSL encryption.

Required Authentication

When sending and receiving email, it is required that you use your
Comcast ID and password. This helps to prevent infected computers and
other devices connected to the XFINITY services from being able to
freely transmit spam and malware.

SSL Encryption

Secure Sockets Layer (SSL) is a secure protocol for sending data safely
and encrypted over the Internet. With SSL encryption your user ID,
password, and email are secured from hackers and identity thieves when
sending or receiving email.
Other Bodies Opposed to the Use of Port 25

There are a number of other organizations that Comcast works with to
control the problem of spam on the Internet. One of the most notable of
these is Spamhaus, an organization that provides a number of lists
detailing IP addresses known to send a great deal of spam and a list of
IP addresses that should never send email at all. These lists as well as
others provided by similar organizations are used by nearly all of the
ISPs and mail receivers on the planet. All of the Comcast dynamic IP
address space is listed by Spamhaus as not to be used for the sending of
email. As such, any email sent by subscribers on the Comcast network
directly to other ISPs (not via the Comcast mail servers) is extremely
likely to be blocked by the receiving ISP.

The Federal Trade Commission, an organization that has taken legal
action against many spammers, also recommends that Port 25 should be
blocked by ISPs. The FTC’s recommendation is as follows:

“Block port 25 except for the outbound SMTP requirements of
authenticated users of mail servers designed for client traffic. Explore
implementing Authenticated SMTP on port 587 for clients who must operate
outgoing mail servers.”

The ITU also recommends blocking port 25 in their document named “ITU
Botnet Mitigation Toolkit”. This can be viewed here. While this document
is focused on the remediation of botted computers, blocking of port 25
is seen as an important step in mitigating the spam that is sent from
botted machines.

[Mail Man]

Odiferous Flatulence wrote:

(...)

why was the "Jack Ryan" post:

Date: Thu, 17 Apr 2014 15:33:34 -0500 (CDT)

Now duplicated by "Odiferous Flatulence"?

For the fucking ass-wipe "Jack Ryan" - why don't you post to usenet
using eternal september or aioe - instead of these riduculous and broken
anonymous mail-to-usenet gateways? Makes you look like a fool.