North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Problems sending mail to yahoo?

  • From: Barry Shein
  • Date: Sun Apr 13 14:27:22 2008

I realize it's natural and predictable, when spam is mentioned, to
repeat the folklore...then the robots came and we were all driven
underground to survive...

However my point was something more in the realm of standards and
operations and what we can do rather than going back over what we
can't seem to do.

For example, and it's only an example don't quibble the example,
defining a list of return SMTP codes which are actually specific and
meaningful like (let's assume they should be 5xx, maybe 7xx would be a
better start? Policy failure codes)

    540 Sending site in internal blacklist contact: URL or MAILBOX
    541 Sending site is in external blacklist: URL
    542 FROM address blocked: MAILBOX
    543 RCPT address blocked: MAILBOX
    544 BODY contained blacklisted URL or MAILBOX: URL or MAILBOX
    545 BODY contained blacklisted string not a URL or MAILBOX
    546 SUBJECT contained blacklisted URL or MAILBOX: URL or MAILBOX
    547 SUBJECT contained blacklisted string not a URL or MAILBOX
    548 SPF Failure (note: could be subsetted further or detail code added)
    549 DKIM Failure (note: could be subsetted further or detail code added)

and so on, a taxonomy which could then at least be dealt with
intelligently by sending MTAs and supporting software rather than each
side cooking up their own stuff.

That's the first problem with this yahoo flap, right? You have to go
to the backed up mail queues and stare at them and try to pattern
match that a lot of these are from yahoo, and oh look they're
deferred?, wait, inside the queue files you can find this "421
Deferred due to user complaints see URL" which then leads you to a
form to fill out and you're still not sure what exactly you're
pursuing other than hoping you can make it go away either by your
action or theirs.

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.

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
[email protected]?

Is it [email protected] or [email protected] or [email protected] or
[email protected] (very commonly used) or [email protected] Who cares? But
let's pick ONE, stuff it in an RFC or BCP and try to get each other to
conform to it.

-- 
        -Barry Shein

The World              | [email protected]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*