Questions and answers about anti-spam efforts using epostage.

Questions and Answers About eMstamp and Alternative Anti-Spam Efforts.

This document attempts to answer the many questions that have come to light regarding the eMstamp anti-spam system. Your best bet to find a particular answer is to use a keyword with your browser's EDIT > "Find on this page" search utility.

There are a large number of questions answered here but the result is by no means exhaustive. If you can't find an answer, please use the Contact link to send us your anti-spam or eMstamp question. We will attempt an answer and post it here. CONTACT

How does eMstamp stop spam mail?
EMstamp enabled MTAs will reject messages which are not accompanied by an eMstamp, having a required number of imbedded credits. This means that the sending MTA will either have to purchase the credits or receive them from incoming mail in order to have its messages received.

What's an MTA?
MTA is an acronym for Message Transfer Agent. An MTA is computer connected to the Internet for the purpose of transferring messages received from your desktop application to a remote MTA of an intended recipient. These MTAs are operated by ISPs and other commercial entities.

Does the use of the eMstamp mean that individuals will have to purchase credits to send messages?
No, credits are purchased or collected at the MTA server level of the message transfer process. Individual users of the e-mail system are not directly affected.

There are billions of e-mails sent every day. How can any payment system keep up with this volume?
EMstamp credits are not purchased every time a message is sent. MTAs are pre-loaded with credits purchased in bulk for generating their own eMstamps. This is similar to pre-loading a postal machine for printing stamps. Also, since MTAs recycle credits from incoming mail to send their own messages, the number of bulk purchases is expected to be relatively small.

Where does an MTA administrator go to buy eMstamp credits?
The generic answer is from an issuing authority. Specifically, this question has not yet been answered. It could be from a plurality of private institutions authorized to issue credits or as some have suggested, from quasi-private institutions like the postal services.

What about foreign e-mail?
One of the features that makes the eMstamp system so elegant is its simplicity. Since the eMstamp is imbedded with credits and not a specific currency any eMstamp enabled MTA anywhere in the world will be able to deliver messages to any other MTA. Naturally, issuing authorities will collaborate on a standard value for a credit.

What will an eMstamp credit cost?
A credit will cost very little in terms of individual messages. It has been speculated that it will be as little as 1/10 of one cent.

Why should 1/10 cent keep anyone from sending a message?
It won't …unless of course you're sending millions of messages a day. Then it will cost $1000.00 per million messages. With a spammer sending tens of millions of messages every day the cost will be prohibitive. The spammer will be out of business because it is no longer profitable to indiscriminately send unsolicited messages.

Who determines how many credits will be needed to send a message?
Ultimately the recipient will determine this by setting privacy levels on one or more individual mailboxes equivalent to the number of credits required for delivery to that particular box. This way you can set a high level for your least frequent but most important correspondence and lower levels for receiving commercial transactions such as Internet purchase receipts. Initially boxes will have a low default level set by the ISP.

Won't a spammer be tempted to send messages to low level boxes?
Spammers rely on being able to indiscriminately send hundreds of messages to millions of recipients. The cost grows quickly so, this isn't very likely.

Why can't a spammer simply generate a batch of eMstamps and apply them to outgoing messages?
This is one of the first questions that had to be resolved when designing the eMstamp system. It was decided that the most straightforward solution was to have the incoming MTA provide the outgoing MTA a one-time ID value when initially opening a communication channel. The sending MTA must incorporate this ID in the outgoing eMstamp and when received the ID must match the value generated and recorded by the incoming MTA or else the eMstamp will be invalid and the message refused.

What's to keep a spammer from hacking the eMstamp software module on their MTA and simply incrementing the number of available credits to any value they want?
The answer to this question is naturally critical to the viability of the eMstamp system. It must be able to function in a non-trusted environment. Hacking or reverse engineering the eMstamp module is prevented using several barriers to entry. The basic software is protected using a technique called white box security. Any tampering with the software will render it useless. Furthermore, eMstamp modules are registered and can be verified for authenticity periodically.

Why not use a proxy server to simply increase the number of credits imbedded in an eMstamp once a message has been sent?
This can't happen because the eMstamp with its credits is encrypted upon leaving the originating MTA and can only be decrypted by the intended recipient MTA.

What happens to newsletters or ads that I want to receive?
Mail from legitimate commercial operations should continue and your ability to receive subscribed to information like newsletters will be enhanced because indiscriminate blocking by ISPs will no longer be required. You may still receive some advertisements but at a much lower rate and only where the sending company thinks it's worth the cost. This is little different from your postal service except that now commercial operations will have to pay more than you do to send a message. Their MTAs are always sending more mail than received and will need to purchase credits.

If MTAs have to purchase credits to send messages, won't individuals ultimately have to pay for the mail service through their ISP?
No. In fact eMstamp has the effect of reducing the cost of providing mail service because the ISP will no longer have to deal with spam filtering schemes and the ever increasing storage requirements. Credits from incoming mail are striped from the eMstamp and reused to send mail. Since MTAs operated by your ISPs almost always receive more mail than is sent, there will always be an excess of credits available for sending messages; therefore, there will not be a need to purchase credits and no added cost to the individual mail system user.

How does eMstamp affect the SPF (Sender Policy Framework) initiative?
Domains publish MX (Mail Exchange) records so the enterprise knows what machine to send mail to for a particular domain. SPF requires domains to publish reverse MX records as one added line in the DNS record so the enterprise knows what machines send mail from a given domain. The entry allows an Incoming MTA to verify that the mail envelope return-path reflects the actual sending MTA. Unfortunately SPF interferes with mail forwarding unless a format change is made. With eMstamp, verifying the return-path is not an impairment but is unnecessary. More information on SPF can be found at spf.pobox.com

What happens with mail forwarding?
As long as the forwarding MTA is eMstamp enabled, mail transfers as usual. The forwarding MTA adds the necessary eMstamp credits.

How does eMstamp affect mail relays?
There is no problem as long as the relay MTA is eMstamp enabled. EMstamp credits are stripped from the incoming message and applied to the outgoing message. There is no net change in available credits.

What about using desktop mailers?
A desktop mailer is an SMTP utility for sending messages direct from the originating computer to the intended recipient's MTA rather than going through the mail server of the sender's ISP. If the receiving MTA is eMstamp enabled, then the desktop mailer will have to be also.

What about using a mail server with a dynamic IP address?
This is similar to the situation of using a desktop mailer. There is no MX record for the sending computer with a dynamically assigned IP addresses as is usually the case encountered with users of cable or other higher speed Internet connections. Many hosting companies already block mail from servers without an MX record. With SPF this blocking will be the case for all servers with or without a reverse MX address. With eMstamp a reverse MX address becomes unnecessary.

What happens with list servers?
As long as list servers are sending to eMstamp MTAs, they will have to be eMstamp enabled as well. However these servers tend to be from commercial operations. It's presumed that a worthwhile message is worth a few tenths of a cent to send.

Why can't a spammer simply use a bot to sign up with autoresponder sites and collect credits from the responses?
In the first place, autoresponders ordinarily prevent repeated sends to the same address to avoid infinite loops with other autoresponders and undeliverable mail. Therefore a bot would have to go repeatedly to thousands of autoresponder sites to collect enough credits; in itself this is not a simple task. It would be vastly uneconomical for a spammer to try such a technique.

What if a spammer sets up thousands of e-mail addresses on an MTA to collect credits from incoming messages?
This scenario seems to assume that someone is going to indiscriminately send thousands of messages to these addresses. Who else but another spammer? Since spammers have to pay to send the messages, this situation isn't very likely unless they want to continuously spam each other.

What about spamming using an NDR?
An NDR is a Non-Delivery Report. It works when the spammer sends spam to a legitimate MTA, but with a bogus 'To' address, and sets the 'From' address to the person he wants to spam. The receiving MTA replies with an email NDR sent to the forged but valid 'From' recipient. Since NDRs tend to bypass mail filters, the spammed message ultimately gets to the intended recipient. NDRs can also be used for delivering viruses and should never be opened with anything but a simple text reader. With the eMstamp system it's unlikely that a spammer would want to use this technique since they have to purchase eMstamp credits to send the message originally.

What does eMstamp do about hijacked e-mail addresses?
The hijacked address is the problem that the SPF (Sender Policy Framework) tries to solve by incorporating more information in the DNS registries. It's unlikely that anyone would pay to send messages and still try to deceive someone about whom the message is from.

How does eMstamp affect so called zombie servers?
A zombie server is a hijacked computer that has been infected with a Trojan e-mail sending program also known as a remote-access Trojan horse program or RAT. The infected computer can act like a list server, sending messages to multiple recipients based on one incoming message. Since the Trojan program cannot get its mail delivered without eMstamp credits, the effort in spreading these Trojans would be futile. This is just another example of how a complex problem is solved by simply using an economic disincentive.

How does eMstamp affect e-mail viruses?
E-mail viruses are usually spread when a virus invades a computer via e-mail and uses the computer's resident list of e-mail addresses to replicate itself by sending the virus on to those addresses. If the virus attempts to use a Trojan mailer to send the virus direct to the recipient MTA, then the effort will be futile unless the Trojan has purchased credits. Someone purchasing millions of credits to infect millions of computers is very unlikely. If the Trojan uses the infected computer's ISP MTA, then eMstamp alone cannot stop this activity.

Why isn't the "Caller ID" approach a better solution to the spam problem?
In some ways the approach taken to the spam problem is a matter of philosophy. Caller ID attempts to identify the sender of spam mail so that subsequent action can be taken against the perpetrator. That is, make sending spam mail a crime and punish the responsible parties. Instituting a "caller ID" system is in itself not simple and the subsequent trial and punishment activities are complex and very expensive. The eMstamp approach doesn't look to assign blame; it simply makes the sending of spam mail economically unfeasible, eliminating spam at the source and therefore eliminating all of the downstream complications.

Anti-spam filters can block unwanted e-mail. Why set up yet another system like eMstamp?
A lot has been written on this topic and again it's partly a mater of philosophy and partly a pragmatic issue. Filters applied by the intended recipient of a message are not a problem. It is the rightful prerogative of that recipient to decide what messages they want to read and what to trash. On the other hand, filters applied at the MTA level are undeniably a form of censorship of your incoming mail. You have no idea of how, why, or what messages are being eliminated. MTA filters are an expedient measure out to profit from spam mail, not to discourage the sending of it.

If "caller ID" and anti-spam filters are so bad, what's wrong with the "bonded sender" initiative that ISPs are signing onto?
Making spam a crime and the vagaries of that process or using anti-spam filters to censor your e-mail both pale in comparison to the injustice of the bonded sender program. With bonded sender, if you are a commercial mailer and want to send mail to a participating ISP's subscribers, you have to make a substantial financial commitment to the ISP before delivery is allowed. This is a barely disguised scheme to sell your e-mail address to the highest bidder. It is a blatant example of big business exerting its will at everyone else's expense and should never even be considered, let alone instituted.

Is there any truth to the claim that trashing e-Mail messages could get you in trouble?
Not exactly, at least not you as a private user of the e-mail system. This claim stems from an interpretation of sections 302 and 404 and 802 of the Sarbanes-Oxley Act of 2002 regarding corporate governance and the responsibilities of public company officers to maintain records. The requirement is that even unstructured information such as e-mail messages must be available for discovery in audits; therefore, relevant messages must be retained. The destruction of such information could be considered the destruction of evidence, raising questions of legal liability. Both public and private enterprises must be very careful about trashing e-mail, even inadvertently, when using spam filters.

There are billions of e-mail messages sent every day. How can any payment system keep up with this number of transactions?
This question stems from an old concept of having to make a micro payment for each message sent. EMstamp doesn't work that way. With eMstamp the administrator of an MTA purchases credits in bulk from an issuing authority. The credits are loaded into the MTA for use as required to create eMstamps. This is the same concept as a postal machine that gets loaded with credits for printing stamps.

With eMstamp won't all MTAs across the entire Internet have to be upgraded at the same time?
No. The eMstamp software module provides a zero credit option that effectively disables the eMstamp function at the incoming MTA. The MTA will, however, still reply with info about the eMstamp capability and optionally notify the sending MTA that eMstamp policy will be enabled as of a certain date.

With anti-spam filters reading my e-mail, what's to stop ISPs from using the filter to assemble a profile on me and subsequently selling this info along with my e-mail address to advertisers?
Nothing! This is like a Bonded Sender program on steroids. If we continue to allow ISPs to censor our e-mail using filters, then we can expect that it's only a matter of time until some ISP realizes that this activity can be a very lucrative source of revenue.

How does eMstamp affect the ESPC (Email Service Provider Coalition) "Project Lumos" initiative?
In their own words:
""Project Lumos" is a registry-based model developed to eliminate spam by holding senders accountable for the mail they send. Project Lumos implements true sender accountability and transparency by requiring that senders fully verify their identity, and adhere to best practices, and then objectively monitoring their performance.
As nice as the description may sound, the proposal is little more than the already discredited Sender ID and Bonded Sender proposals of Iron Port and Microsoft. These initiatives set out to create an elitist club of acceptable members, frequently based on their ability to pay. Not only are such schemes technically unsound but they are ripe for abuse from the political vagaries of third party accreditors.