From: Anthony Howe
Date: 2006-07-11 04:28:12 -0400
Subject: Re: Milter-Null and / or SRS filtering...
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
> SRS rewritten address is subsequently forwarded. I believe the intent
This article/image explains SRS in more detail:
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
>> 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
> *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
>> 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
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561
Copyright 2009, 2012 by SnertSoft. All rights reserved.