+++ James Cronin <Monday 22 April 2002 11:51 pm>:
> I'm working on a bulk (opt-in, verified subscription etc...) email
> delivery system at the moment, and over the years I've heard a
> number of possibly apocryphal stories about people requiring
> contracts with large email suppliers (Hotmail, AOL, Yahoo, MSN
Confirmed.
> Has anyone ever actually come across such a contract in real life
> or are they just urban myths?
I do it all the time (as postmaster and mailadmin at a rather large webmail
provider - over 30 million mailboxes, but none of the above providers you
mentioned <g>).
Incidents of unconfirmed optin is just one of the several reasons why I block
IPs / domains (at our access.db, in our rbldns config, or at our firewall in
some extreme cases).
There's the rather key issue of bounce management. If you accept bounces at
the same (or even faster) rate than you send out mail, and do a good job of
weeding out dead / bouncing addresses, then you are reasonably safe. Even
safer if you don't hit any of our extensive list of spamtraps.
http://www.mail-abuse.org/rbl/manage.html should give you a few more ideas.
> Other things I'm interested in is stuff like whether and how it's
> necessary to rate limit sending to those domains, whether they
> don't like single messages having more than a certain number of
Frankly, speaking for myself, I don't really care whether you do MAIL FROM:
and several RCPT TOs, or several parallel MAIL FROM:RCPT TO combinations like
qmail + verp based lists do. Just don't saturate our servers and disrupt
much more important mail delivery (such as personal emails which our users
receive - and which carries a far higher priority than random mailing lists)
> RCPT TO lines, whether there are contracts that one can sign to
> get access to some sort of super special non-public MX for them,
> etc...
Not in our case. However, we do unblock or whitelist known "good" lists all
the time, once we
a. have a good working relationship with their admins
b. are convinced the list is true optin (confirmed optin)
c. note that the list is good at bounce management
Notwithstanding the above criteria, or a listing in our whitelist, if I or my
team catches a list saturating our servers and adversely affecting regular
mail delivery, chances are it runs a rather high risk of getting blocked.
Of course we also immediately contact the blocked site's admin in such a case
(if we've had a prior working relationship that is) and the block gets lifted
as soon as the issue at hand is resolved. In other cases, we do usually
unblock (if the issue is bounce management rather than unconfirmed
subscriptions / dirty lists) once the list admin commits to modifying his/her
list management and mailout systems to bring it into line with our
expectations above.
--srs
--
Suresh Ramasubramanian <----> mallet <at> efn dot org
EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
[Linux One Stanza Tip] From : <lvgandhi@???>
LOST #180 -**< Sub : Removing accidentally untarred package >**-
If you accidentally untar a package and it messes with one of
your directories, you can delete all the files produced by
untarring with following: rm -rf $(tar ftz package.tar.gz)
[Note : This needs to be done from the same dir of untarring]
