[milters] Archive

Lists Index Date Thread Search

Article: 1024
From: Anthony Howe
Date: 2006-07-11 04:28:12 -0400
Subject: Re: Milter-Null and / or SRS filtering...

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

Taylor, Grant wrote:
> Anthony Howe wrote:
> I have not run in to any such site.  Nor have I heard of such, but that 
> is not to say that they don't exist.  As I understand it, SRS rewritten 
> addresses that are rewritten only have a number change in the SRS 
> address.  The 

>
"<SRS0+<hash>+<local_part>=<domain_part>@local_domain.tld>"
is rewritten 
> to
"<SRS1+<hash>+<local_part>=<domain_part>@local_domain.tld>"
when an 
> SRS rewritten address is subsequently forwarded.  I believe the intent 

This article/image explains SRS in more detail:

	http://www.openspf.org/srspng.html

 From my understanding, if you include the original sender's address 
transformed as the local part, then there is no hash (well not a hash as 
I know it). The advantage of a hash is to completely replace the 
local-part so that it fits within length limits and you can record other 
bits of info associated with the hash in a database.

Anyway, SRS is a kludge to fix a failing of SPF.

> This would allow you to convert the <user part> to a 48 byte encoded 
> form.  This 48 byte encoded part plus the 4 byes of "enc+" will only 
> make the now new local part be 52 byes long, thus still complying with 
> RFC (2)821.
> 
> What do you think?

Sounds a lot like BATV or similar schemes.

> Do you recall what was Wong's response was at the time?

When it finally dawned on him what I was trying to explain, he realised 
that use of hashing would be the only solution, but by then SRS in its 
current form had be pushed forward. I don't think he ever followed up 
with changes or an alternate. I think everyone is more inclined to 
assume forgiving MTA's with larger address buffers. One day someone is 
going to try exploiting those overly forgiving buffers to find exploits 
and/or just how bad they can hose mail systems when they go beyond 255 
bytes.

>> The correct way to do SRS or any sender rewriting is to use a hash 
>> that doesn't blow up the local-part length limit, but then this 
>> requires a database to track hashs and method to expire them.
> 
> I could see the need for a database if the original local part was 
> longer than the hash used in the message.  However if the local part is 
> shorter than the has I would think you could just encode the local 
> part.  But I am not exactly what I would consider proficient in this area.

No. Consistency is more important than different cases for different 
address lengths.

> *nod*  As far as I can remember all of the services that I have tested 
> did return at least most of the headers for messages in some fashion.  

So far I've seen ALL the headers returned.

> However, I have seen many services not return an RFC 3464 Delivery 
> Status Notification message, but rather something that is proprietary 

Qmail does not , but it does still return the headers.

> that returns what they see fit.  In fact, I have worked with (and 
> re-written parts of) mailing list software that would accept messages in 
> and then return a simple text message that says you are not allowed to 
> send to this mailing list.  However such messages would fail both 
> Milter-Null and SRS filtering.

Yes. Dropped on cutting room floor.

> *nod*  The only way that I could see to prevent the relay attack would 
> be to use a database or something else that would implement something 
> similar of what messages have had DSNs or not.  Rather, I suspect that 
> it would be easier to implement some sort of list of messages that have 
> been sent out that could possibly have a DSN come back in.  When a DSN 
> has been received remove the message from the list.

Same diff. Your hashes provide the database lookup for Message-ID sent 
by this machine. milter-null choose to do this without reliance on a 
database by making use of certain common traits of DSN and MDN messages 
generated by the most popular software.

>> Most MTAs include the headers, but not the body. I've looked at mail 
>> DSN mail from Sendmail 8, Postfix, Qmail, and Exim, which all at least 
>> include headers. I've tested with Gmail, Hotmail, and Yahoo. ...
> 
> *nod*  As an aside do you maintain a local install of those MTAs for 
> testing reasons or have accounts on other systems?  Just curious, does 
> not matter for this discussion.

No. In this case I had access to a spam trap that I trawled through 
grabbing supposed DSN from a variety of MTAs. However, I wrote 
Roundhouse to allow me one day to have multiple MTA servers for testing 
purposes.

>> So far I've not found an MTA that does not include the headers by 
>> default in a DSN/MDN message. I sure its possible to disable returned 
>> headers with the options of most MTAs, but its not a default.
> 
> *nod*  I have found that (at least the ones that I work with) most MTAs 
> will return the entire message by default.  I would like to know how to 
> configure Exchange so that it will only return the headers.

Put your Exchange server in a guillotine. Guaranteed to give you headers 
at least once.

> likely communicate another way.  I *WISH* some people would learn that 
> there are other communications methods than email, and that email is not 
> an INSTANT MESSAGE.

I've said this time and again.

> Mainly from what you have said / pointed out about the 64 character 
> local part of RFC (2)821, I agree with you.  I also suspect that 
> Milter-Null might handle MDNs a bit better.  I will have to do some more 
> reading on MDNs, as I believe that seeing as how MDNs are usually client 

RFC 3798 for MDNs.

> ddresses.  Seeing as how MDNs are sent to the address indicated by the 
> "Disposition-Notification-To" header and from the null reverse path SRS 
> Filtering would filter out ALL MDNs.  :(  Thus giving more credence / 
> points / odds to Milter-Null.

Yes. But typically the Disposition-Notification-To: header will be the 
same as the From: header which hopefully is the same as the Return-Path: 
(the envelope sender, possible SRS rewritten). That's still a lot of 
expectations.

-- 
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561
     http://www.snertsoft.com/

Lists Index Date Thread Search