Sam Varshavchik wrote:
> mouss writes:
>> Sam Varshavchik wrote:
>>>> [snip]
>>>>
>>>> That's unrealistic. the user-part in MAIL FROM has a length 
>>>> limitation which goes against secure signatures. the other question 
>>>> is why would this be needed (I mean, is it really worth the 
>>>> trouble?)...
>>>>
>>>> isn't
>>>>     [EMAIL PROTECTED]   (where "blahblah" is whatever you want)
>>>> enough? (replace '+' with whatever "extension" character you use)
>>>
>>> That was my first thought as well. Maybe if I waste half a day trying 
>>> to decipher that document, I'll see some brilliance in that proposal, 
>>> but, so far, I just don't get it.
>>>
>>
>> the "primary" scheme proposed in the draft is
>>     [EMAIL PROTECTED]
>> where "KDDDSSSSS" is the "tag-value".
> 
> Cool. All that now needs to be determined is, if I start using these 
> return addresses, why anyone else should care. What difference does it 
> make, to someone else?

If DDD has expired already, then a bounce would be undeliverable, 
which may be a good reason for a remote server to discard the message 
altogether.

Otherwise, let's assume DDD has not expired yet but the message is 
undeliverable. A remote server may send us a bounce with no mental 
reservations, as it knows that we can work out the validity of the 
address at the RCPT level.

Even for deliverable messages, the remote server may abuse our ability 
to check the signature by faking a bounce and discarding the message 
as spam if our server rejects the signed address (that's the much 
disapproved callout).

SSSSSS is the hex encoding of the first three bytes of some sort of 
signature. Insecure by design. If SSSSSS were made with a (weak) 
public key, i.e. not prvs, a remote server could check the signature 
by itself.












































-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to