From: Taylor, Grant
Date: 2006-07-10 17:36:01 -0400
Subject: Re: Milter-Null and / or SRS filtering...
More information..: http://www.milter.info/#Support
Anthony Howe wrote:
> BATV / SRS modify the envelope instead. Some sites require that the MAIL
> envelope equal the From: or Sender: header. I think Sendmail X has an
> option to enforce this, particularly for mailing lists. Its unclear to
> me how effective the SRS variant would be when the MAIL envelope is
> changed by two or more forwarders.
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
is rewritten to
when an SRS rewritten address is subsequently forwarded. I believe the intent was to
allow SRS rewritten senders to pass through a chain of forwarders to an ultimate
destination server that would either accept or reject / bounce the message. If the
message was rejected / bounced the last server that accepted responsibility for the
message would generate a DSN (bounce) and send it back to the first SRS server in the
chain bypassing all intermediary SRS servers. This would allow the first SRS server to
receive the DSN and extract the original sending email address and send the DSN bounce
back to the original sender, thus
allowing the original sender to receive the DSN to know that there is a problem with
delivery to the address that was used. Of course this scheme does not take in to account
that people may want, for security / privacy reasons, the DSN to travel the forwarding
path in reverse. However if this is the case I think the SRS implementation to be
configured to resign the sender each time thus causing the DSN to come back to it as it
would appear to subsequent servers as if it was the first server.
> I have some issues with envelope rewriting. SRS in its basic form, as
> with VERP, can blowup RFC 2821 maximum local-part length which is
> suppose to be restricted to 64 bytes. RFC 2821 also states that an email
> address has an overall max. length of 255 bytes. So if I create a
> specially long email address and subdomains (for harvest detection lets
> say), then its possible that some MTAs will barf on an SRS/VERP
> rewritten address that tries to put 256+ characters into the local-part
> before the at-sign.
Hum. You pose a VERY good point. I do not really relish the fact that by using SRS on my
systems I'm out of RFC compliance. However I do like what SRS tries to do. I wonder if
the idea could not be extended / modified. I suspect that it would be possible to encrypt
the original recipient in such a manner that it would not be necessary to explode the
local part of an email address beyond the 64 byte length imposed by RFC (2)821. I.e.
"<user part>@<sending domain>.<tld>" would become
"enc+<encoded sending email address>@<local domain>.<tld>
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?
> Matter of fact all my milters have had options to enable strict RFC
> length enforcement as means to filter out rubbish. These options are now
> exposed with the latest option scheme used by all 20 Snert milters:
> They're off by default, because early attempts to enforce it broke those
> sites that use VERP capable MLM on their servers. I pointed this out to
> Wong concerning SRS about two years ago at the height of the SPF frenzy.
Do you recall what was Wong's response was at the time?
> 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.
> milter-null requires no such database, since all the information hashed
> is found in the message headers, which to my knowledge so far always
> returned as part of the DSN & MDN. BTW I did test with Thunderbird MDN
> support and Outlook Repress too.
*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. However, I have seen many services not
return an RFC 3464 Delivery Status Notification message, but rather something that is
proprietary 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.
> Replay attacks are possible, which is why the date-ttl option exists in
> milter-null. However, this is not a unique problem to milter-null. BATV
> or SRS using hashing are also vulnerable to replay attacks during your
> TTL window.
*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.
> 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.
> ... Yahoo is of
> particular interest here since they have an accept-then-bounce policy,
> making a bounce test far more interesting; it works too.
Yeck! I am particularly fond of DSN support where the receiving server will either accept
or reject the message then and there. This does take steps to help prevent back scatter.
It also makes testing for things that would cause a message to be rejected a bit more
tricky to detect.
> 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.
> However, IMHO that such sites that don't return message headers are rare
> and that bounce mail from such sites will probably be backscatter.
Id say you are right. The only time that this will be valid is if you send an email to
said site and it accepts and then rejects the message you would not be notified that the
bounce happened. However, if you sent the email it is quite likely that the person that
you sent the email to was expecting it, or you are expecting a reply from the recipient.
If neither of you receive the email or DSN, you will quite 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.
> Dropping legit bounce mail from such sites doesn't bother me any more,
> since so many sites have opted to reject mail from the null sender, a
> milter-null enabled site would just appear as another blip by these rare
> few that don't return message headers with their DSN.
> For the moment, I see the odds in my favour. Correct me if I'm wrong or
> have overlooked something.
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 side initiated the would not know any thing about the SMTP envelope MAIL
FROM: address. .... Ok, a quick refresher of section 3, page 6 & 7, of RFC 2298 -
Message Disposition Notifications, indicates that MDNs "The MDN MUST be addressed (in
both the message header and the transport envelope) to the address(es) from the
Disposition-Notification-To header from the original message for which the MDN is being
generated." and "The envelope sender address (i.e., SMTP MAIL FROM) of the MDN
MUST be null (<>), specifying that no Delivery Status Notification messages or other
messages indicating successful or unsuccessful delivery are to be sent in response to an
MDN.", thus rulering out SRS signed recipient a
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
Well, I think that with your help Anthony, I have severely taken the wind out of my own
sails. Of course that is what I was asking for. I guess someone was looking over my
shoulder by not motivating me to develop a file based class (K) of SRS signed domains to
filter DSNs by. To pull of what I was wanting to do now, I will have to update / rewrite
SRS to comply with RFC (2)821 local part lengths as well as check the
"Content-Type" header for the "report-type" of
"disposition-notification" on messages with the null reverse path address.
Which I believe is doable.
I think I'll go back in to my dark basement (read: cave) and do some more thinking.
Milter-Null will accomplish this as a single milter that I can install, or I can do a lot
more work. .... But then there is that part saying "I 'BET' that I 'CAN' do
it." where I will end up doing it just to see if I can or not.
Grant. . . .
Copyright 2009, 2012 by SnertSoft. All rights reserved.