Apple - About Apple - Mailing Lists





	Search list information:

Confirming your subscription request

Before your subscription can be started, you must confirm your subscription request. Our list server will send you two e-mails: one acknowledging that your subscription request has been processed, and one with an authorization string that must be returned to our server to verify that you did request the subscription.

Why do we require you to confirm subscriptions? It's a bit of a hassle, but on the Internet, it's unfortunately a necessary one. Forging someone else's e-mail address is fairly easy to do, and a common attack on users is to forge their e-mail address and subscribe them to dozens or hundreds of mailing lists. As you can probably imagine, the amount of e-mail this generates can easily swamp a user, and the hassle of trying to untangle an account can be immense.

As responsible list administrators, we don't want our sites to be used for these kinds of attacks. As a user, you definitely do not want to be on the wrong end of one of these attacks. Mail-back confirmation, the process we use, is one of the few systems available where we can guarantee that the user of an e-mail address is the person who made the subscription request.

Here's how our confirmation system works: when you request a subscription, our server will process it and send you, at the address you requested subscribed, what's known as an authorization (or auth) string.

The authorization string looks like this:

auth <auth_key> subscribe <listname> <your_address>

where <listname> is the name of the list you've requested to subscribe to, and <your_address> is the e-mail address you've requested to be subscribed.

<auth_key> is a key generated by the server that is unique to this address. That is how the mail-back confirmation works. When you mail the auth key back to majordomo@public.lists.apple.com (you can also reply to the message, but remember to edit the reply as we explain below), the list server will compare the <auth_key> in your message with the information we have on your request. If it all matches, we know that the person who sent in the auth string is the actual owner of the e-mail address. An e-mail forger can forge a subscribe request, but since the auth string has information that is only available to the person reading e-mail sent to that address, a forger can not forge the auth string. That way, we know this request is genuine and not part of a mail-bomb attack.

Common confirmation problems (and how to solve them)

There are a few very common problems users have while trying to confirm their subscriptions. Here are some hints on how to avoid them:

If you reply to the message to send the authorization back, be careful to edit the reply to remove all of the extra text. Most importantly, most e-mail clients will add a "> " to the front of all of the lines in a message included in a reply. If you do not remove this "> ", it will cause the confirmation attempt to fail. The string you send back to the server should look like:
auth auth_key subscribe listname your_address
not
> auth auth_key subscribe listname your_address
Many e-mail clients will word-wrap long strings to make them more readable to the person you send them to. Unfortunately, these clients also will word-wrap your auth string, which confuses the list server, because your e-mail client ends up sending:
auth auth_key subscribe listname
your_address
to the server. Since the server doesn't see your_address, it refuses the confirmation request, and it sends you another confirmation request. If this happens to you, turn off word-wrapping before you send the confirmation request, or try sending:
auth auth_key subscribe listname \
your_address
with a backslash (not a slash) at the end of the first line. That tells the list server that the auth command is on two lines, and will help you get around the word-wrap problem.
Do not modify any of the data in the auth string! If you change the list name or e-mail address in the auth string, they'll no longer match the information kept on our server, so the authorization will fail. If either the list name or address are incorrect, throw out the authorization request and start over with the correct data.

If you have problems making the confirmation process work, please contact us and we'll help you work through your problems. Please note, however, that for your own protection we can't circumvent the confirmation process -- there are e-mail forgers out there brazen enough to send mail asking admins to circumvent their own security measures, and unfortunately, it works more often than you might think.

We want to help you get subscribed, but we have to be somewhat paranoid about e-mail attacks and forgeries. Please understand we're doing this not to create problems, but to avoid them -- for you and for us -- and work with us. Until better ways to verify the validity of e-mail and addresses, we have to be very careful about adding users to mailing lists. It may seem we're being bureaucratic at times, but in reality, we're simply trying to protect people from the idiots out there. We wish this weren't necessary, but it is.


Search Tips \| Site Map	Extended	Index