>>> In general anything coming into your mailbox and having a To: field
>>> that is not one of your addresses should be dropped as spam.

>> That prevents delivery of valid CC (carbon copy) and BCC (blind
>> carbon copies).  I, for one, use both of those addressing forms.

> Yes. You would have to send them in a different way (at some expense to 
> yourself), one by one. Of course a program would do that for you, just 
> not the smtp servers. The expense would increase a lot if you would send 
> spam. That is the point. Currently the expense is borne by the smtp 
> servers on the internet which explode the bccd message into 100 or more 
> copies and deliver it to spam catchers (after exploding).

You are confusing list expansion with CC/BCC.  A CC or BCC address
is specified in the header portion by the user agent when composing
the message.  It may be either a single recipient or a list.

If a single recipient, then when the user agent hands the message to
your SMTP client, the SMTP client extracts all addresses from all To:,
CC:, and BCC: fields appearing in the header.  One connection is made
to each destination system for each single recipient(*).  During the
SMTP dialog, the client uses the "rcpt to:" to specify the recipient
on the SMTP server system.

If an address is a list, then a list expansion mechanism converts it to
single recipients and then connects to each recipients' SMTP server to
deliver a copy of the message (as above).

(*) If a message is addressed to two or more single recipients on one
destination system, the SMTP client may optionally use one connection
to transfer one copy of the message to all recipients on that system.


>>> The envelope address (the To: field) and the real delivery address
>>> (smtp protocol 'rcpt to:' line argument) are different in email
>>> (unfortunately).

>> This is just like paper mail.  The envelope address does not have
>> to have any relationship to the contents ... as it should be.
>> People seem to be able to deal with this with paper mail.

> No, it's not. The header is the envelope. Imho the bug is that one
> can fake the address on the envelope (headers) and send the mail
> wherever one pleases.

Incorrect.  The envelope addresses exist in the dialog between the
SMTP client and the SMPT server in the "mail from:" and "rcpt to:".

The header that the user sees is built by the user agent program
before the message is sent.  The To:, CC:, and BCC: fields are lines
that appear in that header.  It travels as the first part of the
"data" portion of the SMTP dialog.  The receiving SMTP server may
add additional information to it, e.g. "received:" lines, but is
not required to do so.


>>> While this 'feature' makes running mailing lists easier, it also makes
>>> 90% of spam email possible.

>> That's plain wrong.  The delivery mechanism already has to make
>> individual connections to the recipient's system and enumerate
>> the recipient's name in the envelope portion of the SMTP dialog.
>> If the recipient's name had to be in the To: line, it would just
>> require more storage by expanding the header portion.

> Yes, but together with the bcc/cc denial feature above it would close 
> the other hole in RFC822 email: the sender anonimity would be gone. The 
> next step would be to enforce receiving capability for every sender, by 
> the first smtp daemon in the path (and by every successive one). No 
> valid functioning return receiver address, no forwarding. And this would 
> be checked periodically by the servers by sending messages that can be 
> responded to only by humans.

It is unclear here whether you are referring to the "mail from:" envelope
field or the "From:" header field.  They are distinct and different.  One
is required (by the RFCs) to be blank for non-delivery notices to prevent
mail loops.

> Legitimate mailing lists could use cookies or something like it to make 
> downstream servers accept their messages for distribution.

Or use the cryptographically signed SMTP dialogs that were proposed
a decade ago ... and which have yet to be accepted or deployed by the
Internet community at large.

						Lee Jones

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist