FAQ
The background scenario is that I have been experiencing the "now you
see it/now you don't" big-consumer-internet mail service spam
blocking. This week it is Verizon.net.

Basically, mail to verizon.net addresses failed and bounced for a 24
hour period on the 12th. Service appeared to have been restored on
the 13th. Again, yesterday (the 18th), Verizon quit receiving mail
again. The log message being shown by sendmail is of the the form:

Jun 19 10:49:00 julie sendmail[16973]: [ID 801593 mail.info]
m5JGmxNk016971: to=<customer at verizon.net>,
ctladdr=(101/10), delay�:00:00,
xdelay�:00:00, mailer=esmtp, pri1428, relay=relay.verizon.net.
[206.46.232.11], dsn=5.0.0, stat=Service unavailable

For the four days June 13-17, mail went verizon.net normally,
dsn-2.0.0, stat=Sent

Two Verizon users have contacted me and told me that they had received
no mail from our list since the 11th; that they had contacted Verizon
support, and had been told that Verizon was not blocking or dumping
our list mails. Both users are sufficiently knowledgeable to have
looked for shunting to a "spam" or "bulk" file. I wrote a private
e-mail to one user giving log details for him to use. That e-mail
bounced back sky high, and the bounce message made clear that Verizon
has a spam block on my IP. The log message was another dsn=5.0.0
stat=Service unavailable.

I decided to change the bounce processing so that if this "Service
unavailable" bouncing continued into a second day, the affected
Verizon users would get bounce-trapped, and I'd see the triggering
bounce messages. Accordingly I changed:

Bounce score from 3.0 to 2.0
Discard period from 2 to 4 days
Number of warnings from 3 to 2
Notification interval left at 7 days

I've just double checked to be sure that the numbers in the window are
2.0, 4, 2, and 7.

This did exactly what I wanted, and I've got about thirty bounce
messages showing 5.7.1 security bounces, some of which I've forwarded
(via another IP) to affected Verizon users for their use in dealing
with the ISP.

However, I've also gotten about fifty other bounce disables on the 2.0
score. Some investigation shows that affected users had accumulated
two bounces several months ago, but none since. From what I see in
the bounce logs still in my rotation, it appears that the bounce
processor did not sense that these bounces were very stale (over 90
days, when I've specified 4), but simply operated on my reducing the
score from 3.0 to 2.0. A couple of users have forwarded back the
bounce e-mail they received and have noted the "last bounce dates" in
March-April.

Mailman version is 2.1.9, local build with Python 2.4.3 on Solaris 9.

Hank

Search Discussions

  • Mark Sapiro at Jun 19, 2008 at 10:58 pm

    Hank van Cleef wrote:
    However, I've also gotten about fifty other bounce disables on the 2.0
    score. Some investigation shows that affected users had accumulated
    two bounces several months ago, but none since. From what I see in
    the bounce logs still in my rotation, it appears that the bounce
    processor did not sense that these bounces were very stale (over 90
    days, when I've specified 4), but simply operated on my reducing the
    score from 3.0 to 2.0. A couple of users have forwarded back the
    bounce e-mail they received and have noted the "last bounce dates" in
    March-April.

    Mailman version is 2.1.9, local build with Python 2.4.3 on Solaris 9.

    Fixed in 2.1.10.

    See <http://www.msapiro.net/scripts/reset_bounce.py> (mirrored at
    <http://fog.ccsf.edu/~msapiro/scripts/reset_bounce.py>) for a withlist
    script to do a mass re-enable by domain.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Barry Finkel at Jun 20, 2008 at 12:23 pm
    Hank van Cleef <vancleef at lostwells.net> wrote, in part,
    The background scenario is that I have been experiencing the "now you
    see it/now you don't" big-consumer-internet mail service spam
    blocking. This week it is Verizon.net.

    Basically, mail to verizon.net addresses failed and bounced for a 24
    hour period on the 12th. Service appeared to have been restored on
    the 13th. Again, yesterday (the 18th), Verizon quit receiving mail
    again. The log message being shown by sendmail is of the the form:

    Jun 19 10:49:00 julie sendmail[16973]: [ID 801593 mail.info]
    m5JGmxNk016971: to=<customer at verizon.net>,
    ctladdr=(101/10), delay�:00:00,
    xdelay�:00:00, mailer=esmtp, pri1428, relay=relay.verizon.net.
    [206.46.232.11], dsn=5.0.0, stat=Service unavailable

    For the four days June 13-17, mail went verizon.net normally,
    dsn-2.0.0, stat=Sent

    Two Verizon users have contacted me and told me that they had received
    no mail from our list since the 11th; that they had contacted Verizon
    support, and had been told that Verizon was not blocking or dumping
    our list mails. Both users are sufficiently knowledgeable to have
    looked for shunting to a "spam" or "bulk" file. I wrote a private
    e-mail to one user giving log details for him to use. That e-mail
    bounced back sky high, and the bounce message made clear that Verizon
    has a spam block on my IP. The log message was another dsn=5.0.0
    stat=Service unavailable.
    It seems to me that

    stat=Service unavailable

    means that the inbound mailer is not available at the moment.
    This should result in a 400-level SMTP retryable reject, not a
    500-level hard reject. The statement

    "Verizon was not blocking or dumping our list mails"

    is technically a correct statement; Verizon is not accepting mail.

    Another thought comes to mind - when this happens, is Verizon rejecting
    all mail, or is that mailer selectively not accepting mail? If
    Verizon is selectively rejecting mail, then I would expect a different
    message than

    dsn=5.0.0 stat=Service unavailable.

    ----------------------------------------------------------------------
    Barry S. Finkel
    Computing and Information Systems Division
    Argonne National Laboratory Phone: +1 (630) 252-7277
    9700 South Cass Avenue Facsimile:+1 (630) 252-4601
    Building 222, Room D209 Internet: BSFinkel at anl.gov
    Argonne, IL 60439-4828 IBMMAIL: I1004994
  • Mark Sapiro at Jun 20, 2008 at 2:20 pm

    Barry Finkel wrote:
    Hank van Cleef <vancleef at lostwells.net> wrote, in part,
    <snip>
    For the four days June 13-17, mail went verizon.net normally,
    dsn-2.0.0, stat=Sent

    Two Verizon users have contacted me and told me that they had received
    no mail from our list since the 11th; that they had contacted Verizon
    support, and had been told that Verizon was not blocking or dumping
    our list mails. Both users are sufficiently knowledgeable to have
    looked for shunting to a "spam" or "bulk" file.
    <snip>
    It seems to me that

    stat=Service unavailable

    means that the inbound mailer is not available at the moment.
    This should result in a 400-level SMTP retryable reject, not a
    500-level hard reject.

    This status is often used to reject mail that is detected as spam.

    The statement

    "Verizon was not blocking or dumping our list mails"

    is technically a correct statement; Verizon is not accepting mail.

    If you re-read the sections I left above, you'll see that Hank says
    from June 13-17 list mail to verizon.net was accepted with an extended
    2.0.0 status but was not delivered to the recipient's inbox, bulk or
    spam folders.

    Another thought comes to mind - when this happens, is Verizon rejecting
    all mail, or is that mailer selectively not accepting mail? If
    Verizon is selectively rejecting mail, then I would expect a different
    message than

    dsn=5.0.0 stat=Service unavailable.

    Again, this response is often sent in response to the end of data to
    indicate that the data was unacceptable.

    It can also be sent earlier in the SMTP transaction if the MTA doesn't
    like the sender.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Stephen J. Turnbull at Jun 20, 2008 at 8:34 pm

    Barry Finkel writes:
    Hank van Cleef <vancleef at lostwells.net> wrote, in part,
    It seems to me that >
    stat=Service unavailable >
    means that the inbound mailer is not available at the moment.
    The problem that we're facing is that there are a few people who don't
    think[1] that the RFCs apply to them. Presumably due to the stress
    levels at large ISPs, this small fraction of all admins seems to be
    most concentrated at said large ISPs. :-(


    Footnotes:
    [1] Optionally insert "and thus conclude that" here.
  • Hank van Cleef at Jun 21, 2008 at 5:23 pm
    The esteemed Barry Finkel has said:
    Hank van Cleef <vancleef at lostwells.net> wrote, in part,
    Basically, mail to verizon.net addresses failed and bounced for a 24
    hour period on the 12th. Service appeared to have been restored on
    the 13th. Again, yesterday (the 18th), Verizon quit receiving mail
    again. The log message being shown by sendmail is of the the form:

    Jun 19 10:49:00 julie sendmail[16973]: [ID 801593 mail.info]
    m5JGmxNk016971: to=<customer at verizon.net>,
    ctladdr=(101/10), delay�:00:00,
    xdelay�:00:00, mailer=esmtp, pri1428, relay=relay.verizon.net.
    [206.46.232.11], dsn=5.0.0, stat=Service unavailable

    For the four days June 13-17, mail went verizon.net normally,
    dsn-2.0.0, stat=Sent

    Two Verizon users have contacted me and told me that they had received
    no mail from our list since the 11th; that they had contacted Verizon
    support, and had been told that Verizon was not blocking or dumping
    our list mails.
    It seems to me that

    stat=Service unavailable

    means that the inbound mailer is not available at the moment.
    This should result in a 400-level SMTP retryable reject, not a
    500-level hard reject. The statement

    "Verizon was not blocking or dumping our list mails"

    is technically a correct statement; Verizon is not accepting mail.

    Another thought comes to mind - when this happens, is Verizon rejecting
    all mail, or is that mailer selectively not accepting mail? If
    Verizon is selectively rejecting mail, then I would expect a different
    message than

    dsn=5.0.0 stat=Service unavailable.
    Since I'm the original poster, I should perhaps clarify a few things.
    My real question, which Mark answered (thank you Mark) was about an
    unwanted side effect from the Mailman bounce processor.

    When I made my original post, I decided to summarize my problems with
    verizon.net, and develop my rationale for resetting the bounce
    processing parameters as a diagnostic tool. Given the recent thread
    on problems with Hotmail, and other discussions about ISP's
    spam-blocking Mailman mail list mails over time, I felt that including
    some of the details could be informative to the larger audience of
    Mailman-users readers.

    First off, list mail deliveries to verizon.net (and yahoo.com) addresses
    have always been slow. My daily log-reading has led me to expect a
    great deal of mail requeuing from those two sites on a daily basis,
    and sporadic random bounces. So I'm not "psyched up" to pay a lot of
    attention to increases in "problem" activity from those two sites.

    Bounces with dsn=5.0.0 from verizon aren't news to me. I felt that the
    complete blackout on the 12th was very suspicious, but when service
    resumed on the 13th, none of the affected verizon.net list members had
    hit the bounce trap, so I did not have any of the bounce messages
    being sent back to my site.

    I had several offlist communications with one verizon.net subscriber
    who did not receive mail after June 11. I sent him the log messages I
    had from the 12th (bounces) and the 13th (normal delivery) and told
    him to work the problem with Verizon from his end. His report back to
    me was that Verizon had told him they were not purposely blocking our
    list mail nor dumping it after receiving it.

    When Verizon reinstated the block on the 18th, an offlist mail to this
    user bounced, which was the first hard evidence I had that we were
    dealing with a purposeful and specific blacklist action by Verizon. I
    forwarded the bounce message to this user through another (unblocked)
    IP to the user and told him to work the problem from his end with the
    hard evidence I'd furnished.

    I reset the bounce score so that all of the active verizon.net would
    bounce-disable almost immediately, which they did. I forwarded
    several of the bounce messages to other verizon.net users, and am
    aware that several of them used them in dealing with the Verizon
    administrators.

    I did go to the web site listed in the bounce messages and fill out
    the form with my site information. And I did get a response from
    Verizon that they would remove the block. The block was removed
    around noon on the 20th, and for the moment, mail is now going to the
    verizon.net listers and being delivered.

    I'm documenting this to the Mailman-users list in hopes that it is
    useful and informative information for other administrators
    encountering similar problems with user ISP's. I've been through this
    drill before with other ISP's. Misinformation seems to be a standard
    problem in communications between ISP's and their users, and giving
    the users the log information from the sending site clears the air in
    a hurry. I make it clear to the affected users that if reliable mail
    service cannot be restored, they will have to move to a site that will
    accept list e-mail, but go no further than that.

    As Mark has mentioned, the dsn=5.0.0 is legitimate, but it certainly
    is not very informative in a case like this.

    Hank

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJun 19, '08 at 10:20p
activeJun 21, '08 at 5:23p
posts6
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase