Problems sending mail to yahoo?

Mailman List Mirror (Read Only)
1

Gak, there isn't even a standard code which means MAILBOX FULL or
ACCOUNT NOT RECEIVING MAIL other than MAILBOX FULL, maybe by choice,
maybe non-payment, as specific as a site is comfortable with.

That's what I mean by standards and at least trying to focus on what
can be done rather than the endless retelling of what can't be done.

I would have thought it was obvious, but to see this sort of enlightened
ignorance(*) suggests that it isn't: The current methods of spam filtering
require a certain level of opaqueness.

Having just watched the gory hashing through of how $MEGAISP deals with
filtering on another list, I was amazed that the prevailing stance among
mailbox hosters is that they don't really care about principles, and that
they mostly care about whether or not users complain.

For example, I feel very strongly that if a user signs up for a list, and
then doesn't like it, it isn't the sender's fault, and the mail isn't spam.
Now, if the user revokes permission to mail, and the sender keeps sending,
that's covered as spam under most reasonable definitions, but that's not
what we're talking about here.

To expect senders to have psychic knowledge of what any individual recipient
is or is not going to like is insane. Yet that's what current expectations
appear to boil down to.

So, on one hand, we have the "filtering by heuristics," which require a
level of opaqueness, because if you respond "567 BODY contained www.sex.com,
mail blocked" to their mail, you have given the spammer feedback to get
around the spam.

And on the other hand, we have the "filtering by statistics," which requires
a large userbase and probably a "This Is Spam" button, where you use a
complaint driven model to reject mail, but this is severely complicated
because users have also been trained to report as spam any other mail that
they don't want, which definitely includes even things that they've opted
in to.

So you have two opaque components to filtering. And senders are
deliberately left guessing - is the problem REALLY that a mailbox is full,
or am I getting greylisted in some odd manner?

Filtering stinks. It is resource-intensive, time-consuming, error-prone,
and pretty much an example of something that is desperately flagging "the
current e-mail system is failing."

You want to define standards? Let's define some standard for establishing
permission to mail. If we could solve the permission problem, then the
filtering wouldn't be such a problem, because there wouldn't need to be as
much (or maybe even any). As a user, I want a way to unambiguously allow
a specific sender to send me things, "spam" filtering be damned. I also
want a way to retract that permission, and have the mail flow from that
sender (or any of their "affiliates") to stop.

Right now I've got a solution that allows me to do that, but it requires a
significant paradigm change, away from single-e-mail-address.

Addressing "standards" of the sort you suggest is relatively meaningless
in the bigger picture, I think. Nice, but not that important.

(*) It's enlightened to hope for standards that would allow remote sites
    to have some vague concept of what the problem is. I respect that.
    It just seems to be at odds with current reality.

More specific and standardized SMTP failure codes are just one example
but I think they illustrate the point I'm trying to make.

Oh yeah here's another (ok maybe somewhere this is written down), how
about agreeing on contact mailboxes like we did with
postmaster@domain?

Yeah, like that's actually implemented or useful at a majority of domains.

Is it abuse@domain or spam@domain or support@domain or
postmaster@domain (very commonly used) or ???@domain. Who cares? But
let's pick ONE, stuff it in an RFC or BCP and try to get each other to
conform to it.

Having defined methods for contacting people OOB would be nice. IFF (and
often/mostly they don't) anyone cared to actually try to resolve individual
problems. Don't expect them to want to, because for the most part, they do
not. Sigh.

... JG

2

> I would have thought it was obvious, but to see this sort of enlightened
> ignorance(*) suggests that it isn't: The current methods of spam filtering
> require a certain level of opaqueness.

Indeed, that must be the problem.

But then you proceed to suggest:

> So, on one hand, we have the "filtering by heuristics," which require a
> level of opaqueness, because if you respond "567 BODY contained www.sex.com,
> mail blocked" to their mail, you have given the spammer feedback to get
> around the spam.

Giving the spammer feedback?

In the first place, I think s/he/it knows what domain they're using if
they're following bounces at all. Perhaps they have to guess among
whether it was the sender, body string, sending MTA, but really that's
about it and given one of those four often being randomly generated
(sender) and another (sender MTA) deducible by seeing if multiple
sources were blocked on the same email...my arithmetic says you're
down to about two plus or minus.

But even that is naive since spammers of the sort anyone should bother
worrying about use massive bot armies numbering O(million) and
generally, and of necessity, use fire and forget sending techniques.

Perhaps you have no conception of the amount of spam the major
offenders send out. It's on the order of 100B/day, at least.

That's why you and your aunt bessie and all the people on this list
get the same exact spam. Because they're being sent out in the
hundreds of billions. Per day.

Now, what exactly do you base your interesting theory that spammers
analyze return codes to improve their techniques for sending through
your own specific (not general) mail blocks? Sure they do some
bayesian scrambling and so forth but that's general and will work on
zillions of sites running spamassassin or similar so that's worthwhile
to them.

But what, exactly, do you base your interesting theory that if a site
returned "567 BODY contained www.sex.com" that spammers in general and
such that it's worthy of concern would use this information to tune
their efforts?

This is not an existence proof, one example is not sufficient, it has
to be evidence worthy of concern given O(100 billion) spams per day
overwhelmingly sent by botnets which are the actual core of the actual
problem.

I say you're guessing, and not very convincingly either.

>
> So you have two opaque components to filtering. And senders are
> deliberately left guessing - is the problem REALLY that a mailbox is full,
> or am I getting greylisted in some odd manner?

Except that most sites return some indication that a mailbox is
full. It's just unfortunately in the realm of heuristics.

But look into popular mailing list software packages (mailman,
majordomo) and you'll see modules for classifying bounce backs
heuristically and automatic list removal (or not if it seems like a
temporary failure, e.g., mailbox full.)

> Filtering stinks. It is resource-intensive, time-consuming, error-prone,
> and pretty much an example of something that is desperately flagging "the
> current e-mail system is failing."

And standardized return codes (for example) will make this worse, how?

> You want to define standards? Let's define some standard for establishing
> permission to mail. If we could solve the permission problem, then the
> filtering wouldn't be such a problem, because there wouldn't need to be as
> much (or maybe even any). As a user, I want a way to unambiguously allow
> a specific sender to send me things, "spam" filtering be damned. I also
> want a way to retract that permission, and have the mail flow from that
> sender (or any of their "affiliates") to stop.

Sure, but this is pie in the sky.

For starters you'd have to get the spammers to conform which would
almost certainly take a design which was very difficult not to conform
to, it would have to be technologically involuntary. Whitelists are
the closest I can think of but they haven't been very popular and for
good reasons.

Anyhow, the entire planet awaits your design.

A set of standardized return codes was carefully chosen by me as
something which could be (other than the standards process itself)
adopted practically overnight and with virtually zero backwards
compatability problems (oh there'll always be an exception.)

> Right now I've got a solution that allows me to do that, but it requires a
> significant paradigm change, away from single-e-mail-address.

There's nothing new in disposable, single-use addresses (or credit
card numbers for that matter, a different realm) if that's what you
mean but if you have something more clever the world (i.e., the big
round you see when you look down) is your oyster.

> Addressing "standards" of the sort you suggest is relatively meaningless
> in the bigger picture, I think. Nice, but not that important.

Well, first you'd have to indicate that you actually have a view of
the problem which supports such a judgment.

At any rate you're quibbling the example as I forewarned.

But standardizing receiving MTA fail codes is, I suspect, more useful
than you give them credit. It would be some progress at little to no
cost in the large.

It deals less with spam filtering and more with effective MTA to MTA
operation.

At least it's sticking to the realm of improving standards in a way
that can be accomplished.

I don't see how I could have given a better example without a lot of
hand-waving and vagaries.

3

This is actually becoming a method some groups are using to attempt to censor others. This happened to one of our customers a while back:

Site A publishes some things that Group B finds objectionable. Group B wants to get it removed, but it's not illegal, against the hosting company's TOS or copyright infringement.
Group B tells all of it's members to go to Site A and sign up for A's discussion forum, using as many email addresses as they own.
A user registers for an account (one email sent to the user to confirm their email address). The user clicks the confirmation link, then gets an introductory email.
The user then does everything possible on the site that could generate emails. Password changes. "Notify me by email when the forum has a new post" activated. Sending private messages to each other. Etc.
When they've got thousands of users signed up, each with between 6 and 20 emails from Site A, Group B tells all of its users to go through all the emails and click "Report as Spam" on every one of them.
Every mail provider out there suddenly sees tens of thousands of reported spams coming from Site A from a wide range of people, and can independently verify that other sources are seeing elevated levels of spam from Site A's mail server.
Everyone blocks mail from Site A, thinking it's a spam source.

This took an insane amount of time to sort out. If the organizer of "Group B" hadn't emailed me personally confirming (and bragging) about what they had done, I still probably wouldn't have believed it. Our AOL feedback loop took days to go through, and contacting every blacklist we had our mail server entered on and convincing them of our story was difficult to put it mildly. And to make this mildly on-topic, we resolved this somewhat quickly with every provider except Yahoo - which never responded to any of our emails or form submissions.

Then there are the users who apparently think the "Report as Spam" button is like a spare for the "Delete" button, and use them interchangeably... We regularly have users who sign up for a mailing list, click the opt-in confirmation link, then report the confirmation email as spam. We remove them from the mailing list, then they complain they aren't getting their list anymore. We reply back explaining why they were removed, and they report our reply as spam.

-- Kevin

4

Filtering stinks. It is resource-intensive, time-consuming,
error-prone, and pretty much an example of something that is
desperately flagging "the current e-mail system is failing."

Hear, hear!

You want to define standards? Let's define some standard for
establishing permission to mail. If we could solve the
permission problem, then the filtering wouldn't be such a
problem, because there wouldn't need to be as much (or maybe
even any). As a user, I want a way to unambiguously allow a
specific sender to send me things, "spam" filtering be
damned. I also want a way to retract that permission, and
have the mail flow from that sender (or any of their
"affiliates") to stop.

Right now I've got a solution that allows me to do that, but
it requires a significant paradigm change, away from
single-e-mail-address.

In general, your "permission to send" idea is a good one to
put in the requirements list for a standard email architecture.
But your particular solution stinks because it simply adds
another bandage to a creaky old email architecture that is
long past its sell-by date.

IMHO, the only way that Internet email can be cleaned up is
to create an entirely new email architecture using an entirely
new set of protcols with entirely new port assignments and
no attempt whatsoever to maintain reverse compatibility with
the existing architecture. That is a fair piece of work and
requires a lot of people to get their heads out of the box
and apply some creativity. Many will say that the effort is
doomed before it starts because it is not compatible with
what went before. I don't buy that argument at all.

In any case, a new architecture won't come about until we have
some clarity of the requirements of the new architecture. And
that probably has to be hashed out somewhere else, not on any
existing mailing list.

--Michael Dillon

5

Folks,

Can we wrap the mail threads up or at least move them over to their
respective best-places like zorch, nsp-sec, spam-l, asrg, or
yet-another-favorite-list-for-spam-religion? We've gone far beyond
typical mass-mail operations.

Best Regards,

Marty

6

Can we wrap the mail threads up

actually, i am still learning from some of them.

i have a hypothesis to add

nanog list volume is proportional to

   S + E

where S is the amount of Slack time the active members have and
      E is the existence of a significant Event

in the absence of a significant event, volume is directly driven by the
amount of free time we have at the tube. as there is no event to
discuss, we will discuss whatever is kinda interesting, often the same
subjects. after all, this is a discussion forum, not a current news desk.

if an operational event ocurrs, discussion of it quickly predominates
over the S component. if we could watch this happening, we might even
learn something interesting about information flow in our culture, as
the wavefront of the E information causes posters attention to move.

and, in the absence of an E, and S being diverted to to actual paid
work, volume goes down. as pfs mentioned this eve, some time in the
last months, the shortage of E and S was so severe that someone posted
an "is the list working" test message.

randy

7

Great, I'll stop the world.

-M<