why IPv6 isn't ready for prime time, SMTP edition

Jimmy Hess mysidia at gmail.com
Sat Mar 29 17:59:36 UTC 2014


On Fri, Mar 28, 2014 at 4:15 PM, Barry Shein <bzs at world.std.com> wrote:

> On March 28, 2014 at 00:06 owen at delong.com (Owen DeLong) wrote:
> [snip]
> I thought the suggestion was that a recipient (email, or by analogy
> postal) could indicate they wanted an email which would cancel the
> postage attached, that is, no charge to sender if they wanted it.
>
> So if a spammer or junk mailer could, say, trick you into accepting
> mail in those schemes then they get free advertising, no postage
> anyhow.
>

*Postage schemes as proposed with end users email clients 'attaching
postage' simply not workable  Not in IPv4.  Not in IPv6.   Not in IPng
 Not in any conceivable future version of IP.

*Believe end users being served by mail servers  WON'T tolerate postage, or
the extra difficulty in configuring their email client, even from a free
service.    Spam is a serious problem,  and different mail users don't
agree on exactly what messages are spam, BUT from end users' perspective:
they all tend to agree that it is their provider's  job  to have made all
the spam go away,  but  delivered all goodmail with 100% accuracy.

Moreover, mail users expect,  this should be 100% transparent,  requiring
no extra work from the mail user.  Confirming that a message was OKAY, or
that it was spam is definitely outside the compass of your average mail
user.

Therefore....  it would almost definitely be e-mail mailbox providers
footing the bill on behalf of their subscribers in any 'charge postage'
scheme  that ever had a reasonable chance of working.

Must be completely transparent to end users.

Any treatment for spam ultimately needs to have some conceivable way of
being implemented  to be  less harmful and annoying than the disease.

Therefore:  Must not have any significant burdens for at least 95% of
legitimate users,
and the burden of the 5% of legitimate users must be low and worth it.



Email hosting providers still just have to use the flat rate monthly
service fee to recover their costs,  AND  costs have to be low enough that
free mail providers can still work -- supported by advertising :   users
will revolt against SP,  if there are extra charges.


Therefore  "Postage must be optional".

Perhaps, by separating mail into multiple classes, and requiring postage
only for certain classes.

Such as
   "Unpostaged Email"  ---  Extreme spam filtering,  likely deliverability
issues
                                            (what we have today)

   "Bulk Class Email"  ---   subject to reduced spam filtering, reduced
postage,
                                          Only available to authorized SMTP
senders.

   "First class Email"  ---   Intended for private correspondence, greater
postage,
                                         reduced spam filtering

   "Priority Email"        ---  Intended for extremely urgent messages,
high postage,
                                         for time sensitive matters very
little or no spam filtering.



And the process by which SMTP operators could reach agreement to charge
each other for traffic, and on what rate  should be standard,    is
difficult to conceive.....

Postage would incentivize SMTP operators:  to scrutinize users' traffic and
limit abuse or excessive mail outflow  from any one user.

But who could say... that a particularly lucrative spam campaign  won't
 come from the spammer attached with the proper postage?

>
In theory SMTP providers could do this... exchange postage between SMTP
operators and completely hide it from end users, but the problem is it
requires agreement...  and consistent rules,  otherwise e-mail perhaps
becomes too expensive:  or not sufficiently predictably inexpensive.

Now....  if SMTP providers charge each other postage...
postage SPENT should be offset by  postage RECEIVED.

When e-mail conversations are mostly symmetrical ---  for example:  two
users e-mailing each other,   then the ratio of  messages OUT to  messages
IN    should be pretty close to 1.0,  or at least not 1000 to 1;     Which
means....   the two SMTP servers could charge each other postage,  but  the
postage  spent is  offset by postage received.

This would  be different for commercial bulk mailers  ("legitimate" or
otherwise),  AND as a result ---   they would pay.

Shifting some costs back from sender to receiver of the message.
And...  perhaps  the commercial mailers  _should_  bear costs.   As
commercial mailings create support costs  (when false positive'd  by spam
filters),   And...  additional storage cost  (before the  user downloads
their message from their POP3 mailbox).


Also large-scale bulk mail consumes bandwidth, memory, and processing power.


So...  how could it work technically...   One possibility:  a SMTP server
 proves postage deposited,  by   each presenting a cryptocurrency wallet
address in the HELO banner and the 250 reply;   for the smtp transaction to
proceed,  the sending server needs to be challenged to prove it has the
balance to pay --- and  challenged then to provide the signed transaction
in the form of a "Temporary deposit".

Probably through SMTP Extension verbs.


For example:

 "250 Hello: new SMTP server at IP address Xyz.   Before you can start
sending me mail,  except to abuse or postmaster, or clearly marked BULK
class mail:  you need to  introduce yourself with an AUTH message and
provide a Base64 signed transaction paying out a  minimum of a  $0.002
deposit.  to unique address [blahblah].

Deposit forfeit  if not used to send First class Email within 48 hours, or
upon any abuse complaint.

After this SMTP server receives confirmation of your deposit; this SMTP
server will track your balance by your IP address, and you will be allowed
to send mail from this IP,  as long as your balance is not negative.   The
cost of postage will be subtracted from your deposit.

Note, that every time you place a new deposit,  $0.0001 will be subtracted
as an introduction fee.    Every future SMTP connection you make to this
server
is $0.000001  times the number of simultaneous connections.

After the introduction, The first 100 valid recipients and the first 10
invalid recipients or  500 kilobytes of  First class traffic  per SMTP IP
address are free   for the first 100  times you connect to my SMTP port.

Beyond this,   every time you present a RCPT TO with an invalid e-mail
address, or address with an unauthorized recipient domain,  $0.0005 will be
deducted.

Every time you present  a RCPT TO,   $0.000001   will be be immediately
deducted.

Every time you complete DATA stage,  the charge will be
 $0.000001    times the number of RCPT TO lines for successfully accepted
recipients every 1 Kilobyte after the first 250 Kilobytes of message data
received.

If the entire delivery fails  due to a connection timeout,  only 1
recipient is charged for received data.

SPECIAL MAIL CLASSES:
        Bulk Solicited Mail -   1/1000    the normal postage rate  per
recipient for first 250Kb.
       - Identify by specifying 'Precedence: Bulk' in the message header.
         Must prepay the standard postage for the first 1000 recipients.
         Excess postage refunded after no spam complaints for 48 hours.

        Priority Mail           -    10000x   the normal postage rate  per
recipient.
        - Charged if Subject line contains the word PRIORITY
          or the message contains a X-Priority, Importance, or X-Priority
 Header
          indicating high priority.

        Urgent Mail            -    100000x   the normal postage rate  per
recipient.
        - Subject line contains the word URGENT,
         or the message contains a Disposition-Notification-To or
Return-Receipt-To header
          or the message contains a X-Priority, Importance, or X-Priority
 Header
          indicating high priority,

"


So    there may be a  $0.002  cost  to send  a 250  Kilobyte message to
1000 recipients.

Or  $0.10  to  send to 100000  local recipients.


In the event of a user sending mail to a free mailing list,  well....
 The mailing list provider is likely  to require whatever fee is needed to
offset the number of  members in the mailing list.


We're getting lost in the metaphors methinks.
>

--
-JH



More information about the NANOG mailing list