How would one go about figuring out why Yahoo tags as "bulk' all mail 
received from a colleagues mail server. Is there a list of criteria 
somewhere?
D

Lee Jones wrote:
>>>>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