Subject: Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Mon, 31 Dec 2007 00:26:46 +0100
List-Id: <ietf-smtp.imc.org>

Sorry, something between OE and the clipboard doesn't work as
I expect it when composing plain/text mails.  The final mail
has the subject "Spaces in quoted-strings".  While I'm at it:

Dots in a quoted-string as in ".do..ts."@example can be also
"interesting" when they meet a local-part macro in RFC 4408,
the SHOULD in 2821(bis) 4.1.2 is no nonsense.

| a host that expects to receive mail SHOULD avoid defining 
| mailboxes where the Local-part requires (or uses) the 
| Quoted-string form or where the Local-part is case-sensitive.
| For any purposes that require generating or comparing
| Local-parts (e.g., to specific mailbox names), all quoted
| forms MUST be treated as equivalent and the sending system
| SHOULD transmit the form that uses the minimum quoting 
| possible.

The NetNews RFC replaced the latter SHOULD by a MUST for the
special case of Message-IDs.  And 2822upd-03 finishes it off
for the LHS of Message-IDs, I hope that -04 tackles the RHS.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Spaces in quoted-string (was: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard)
Date:  Sun, 30 Dec 2007 23:51:16 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 67
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Alexey Melnikov wrote:

> RFC 821 allowed for space characters (0x20) in local part of
> email addresses, but RFC 2821 and 2821bis don't allow for that

| <quoted-string> ::=  """ <qtext> """
| <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
[...]
| <q> ::= any one of the 128 ASCII characters except <CR>, <LF>,
|         quote ("), or backslash (\)

That allowed NO-WS-CTL, SP, and even NUL in a <quoted-string>
outside of a <quoted-pair>, we obviously don't want it "as is".

> Quoted-string  = DQUOTE *qcontent DQUOTE
[...]
> qtext          = NO-WS-CTL /     ; Non white space controls
>                  %d33 /          ; The rest of the US-ASCII
>                  %d35-91 /       ;  characters not including "\"
>                  %d93-126        ;  or the quote character
 
> qcontent       = qtext / quoted-pair

Right, no SP outside of <quoted-pair>.  You can still have SP
within <quoted-pair>, at the moment (2822upd-03):

| quoted-pair    = ("\" text) / obs-qp
| text           = %d1-9 /          ; Characters excluding CR
|                  %d11 /           ;  and LF
|                  %d12 /
|                  %d14-127

And with <obs-qp> anything down to NUL goes :-(  Fiddling with
SP is very critical, it could break RFC 2821 implementations.

Whatever 2821bis will do, that needs a fat *caveat* somewhere.
And it has to be in sync with 2822upd, we can't have different
approaches in 2821bis and 2822upd for a local part <shudder />

> Prohibition of spaces in quoted parts breaks gatewaying 
> to/from X.400 (MIXER, RFC 2156).

RFC 2156 is still based on 822 (STD 11), it has to be updated
for future full "2821ter/2822fin" standards.  In 2156 4.3.4:

| 2. If the 822.local-part uses the 822.quoted-string encoding,
|    remove this quoting.  If the resulting unquoted
|    822.local-part has leading space, trailing space, or two
|    adjacent spaces go to stage II.

Apparently X.400 can do single embedded spaces in "stage I".

I don't see in 4.3.4 where they deal with any <quoted-pair>s,
how is that supposed to work ?  There's no backslash in 3.3.3
<printablestring>, and no abbreviation in 3.4 <ps-encoded>, a
backslash might end up as "(092)".

Anyway, it is possible to use space in a <quoted-pair> on the
RFC 822 side, isn't that good enough for MIXER ?  IOW, who is
planning to update their MIXER implementation for 2821/2822,
or better for 2821bis/2822upd ?  

2821 and 2821bis have a clear "stay away from quoted-string"
SHOULD at the end of 4.1.2, with text indicating that this is
as near to a MUST as possible without explicitly saying so.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Last Call: draft-klensin-rfc2821bis          (Simple Mail Transfer Protocol) to Draft Standard
Date:  Sun, 30 Dec 2007 22:39:48 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 50
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Alexey Melnikov wrote:

> RFC 821 allowed for space characters (0x20) in local part of
> email addresses, but RFC 2821 and 2821bis don't allow for that

| <quoted-string> ::=  """ <qtext> """
| <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
[...]

| <q> ::= any one of the 128 ASCII characters except <CR>, <LF>, quote ("),|         or backslash (\)
That allowed NO-WS-CTL, SP, and NUL in a <quoted-string> *outside* of a <quoted-pair> 
> 
>    Local-part     = Dot-string / Quoted-string
>                   ; MAY be case-sensitive
> 
>    Dot-string     = Atom *("."  Atom)
> 
>    Atom           = 1*atext
> 
>    Quoted-string  = DQUOTE *qcontent DQUOTE
> 
> where qcontent is defined in RFC 2822 as:
> 
>    qtext           =       NO-WS-CTL /     ; Non white space controls
>                         %d33 /          ; The rest of the US-ASCII
>                         %d35-91 /       ;  characters not including "\"
>                         %d93-126        ;  or the quote character
> 
>    qcontent        =       qtext / quoted-pair
> 
>    NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
>                         %d11 /          ;  that do not include the
>                         %d12 /          ;  carriage return, line feed,
>                         %d14-31 /       ;  and white space characters
>                         %d127
> 
> Was this change between RFC 821 and RFC 2821 intentional? Prohibition of 
> spaces in quoted parts breaks gatewaying to/from X.400 (MIXER, RFC 2156).
> 
> Regards,
> Alexey
> 
> 

Date: Sat, 29 Dec 2007 16:02:48 -0500
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Last Call: draft-klensin-rfc2821bis          (Simple Mail Transfer Protocol) to Draft Standard
Sender: [email-masked]

I'll have to check this, but it certainly was not intentional in
the DRUMS work.  I can see lots of reasons for getting rid of
the other control characters, but none at all for retaining them
and prohibiting space.

   john

--On Sunday, 30 December, 2007 00:01 +0300 Alexey Melnikov
<[email-masked]> wrote:

> The IESG wrote:
>> The IESG has received a request from an individual submitter
>> to consider the following document:
>> 
>> - 'Simple Mail Transfer Protocol '
>>    <draft-klensin-rfc2821bis-06.txt> as a Draft Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action.  Please send
>> substantive comments to the [email-masked] mailing lists by
>> 2007-12-24. Exceptionally,  comments may be sent to
>> [email-masked] instead. In either case, please  retain the
>> beginning of the Subject line to allow automated sorting.
>>   
> I know that the IETF LC has ended, but I believe the issue is
> important enough and hopefully will be addressed.
> My co-worker has pointed out that RFC 821 allowed for space
> characters (0x20) in local part of email addresses, but RFC
> 2821 and 2821bis don't allow for that:
> 
>    Local-part     = Dot-string / Quoted-string
>                   ; MAY be case-sensitive
> 
>    Dot-string     = Atom *("."  Atom)
> 
>    Atom           = 1*atext
> 
>    Quoted-string  = DQUOTE *qcontent DQUOTE
> 
> where qcontent is defined in RFC 2822 as:
> 
>    qtext           =       NO-WS-CTL /     ; Non white space
> controls
>                         %d33 /          ; The rest of the
> US-ASCII
>                         %d35-91 /       ;  characters not
> including "\"
>                         %d93-126        ;  or the quote
> character
> 
>    qcontent        =       qtext / quoted-pair
> 
>    NO-WS-CTL       =       %d1-8 /         ; US-ASCII control
> characters
>                         %d11 /          ;  that do not include
> the
>                         %d12 /          ;  carriage return,
> line feed,
>                         %d14-31 /       ;  and white space
> characters
>                         %d127
> 
> Was this change between RFC 821 and RFC 2821 intentional?
> Prohibition of spaces in quoted parts breaks gatewaying
> to/from X.400 (MIXER, RFC 2156).
> 
> Regards,
> Alexey
> 

Date: Sun, 30 Dec 2007 00:01:09 +0300
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Pete Resnick <[email-masked]>, John C Klensin <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis  (Simple Mail Transfer Protocol) to Draft Standard
Sender: [email-masked]

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'Simple Mail Transfer Protocol '
>    <draft-klensin-rfc2821bis-06.txt> as a Draft Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-12-24. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>   
I know that the IETF LC has ended, but I believe the issue is important 
enough and hopefully will be addressed.
My co-worker has pointed out that RFC 821 allowed for space characters 
(0x20) in local part of email addresses, but RFC 2821 and 2821bis don't 
allow for that:

   Local-part     = Dot-string / Quoted-string
                  ; MAY be case-sensitive

   Dot-string     = Atom *("."  Atom)

   Atom           = 1*atext

   Quoted-string  = DQUOTE *qcontent DQUOTE

where qcontent is defined in RFC 2822 as:

   qtext           =       NO-WS-CTL /     ; Non white space controls
                        %d33 /          ; The rest of the US-ASCII
                        %d35-91 /       ;  characters not including "\"
                        %d93-126        ;  or the quote character

   qcontent        =       qtext / quoted-pair

   NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
                        %d11 /          ;  that do not include the
                        %d12 /          ;  carriage return, line feed,
                        %d14-31 /       ;  and white space characters
                        %d127

Was this change between RFC 821 and RFC 2821 intentional? Prohibition of 
spaces in quoted parts breaks gatewaying to/from X.400 (MIXER, RFC 2156).

Regards,
Alexey

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Mon, 17 Dec 2007 10:52:18 -0000
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Content-description: Mail message body
Sender: [email-masked]

Hi all,

On 14 Dec 2007 at 18:41, Alex van den Bogaerdt <[email-masked]> said:

> 
> On Fri, Dec 14, 2007 at 05:13:58PM +0000, Tony Finch wrote:
> 
> > > To stress:  The first and second are very similar, but they are not the
> > > same and I think the differences are important.
> > 
> > In which case we should continue to use the term "alias" for type 1, and
> > we should continue to discourage type 2a lists that don't change the
> > return path.
> 
> Indeed. [email-masked] can automatically unsubscribe
> me should my email address become unreachable. Someone posting to
> this list cannot, and thus has no use for bounces, out of office
> messages, delivery notifications and what more.

I just asked mail.imc.org to expand [email-masked].  It reports one 
member, majordomo - the processor and the resubmitter.

In which case, why do DSNs for mail to this address show as delivery to a 
mailing list (in the sendmail alias-of-more-than-one-destination sense)?  
I know this is probably an implementation detail, but it seems to me that 
sendmail ought to be delivering mail to a mailbox under the current 2821 
reading of what an alias-based mailing list is.  Perhaps some other 
characteristic of an alias sets off a sendmail-specific behaviour (the 
owner-x syntax?) but in this case it's programmatically annoying since 
some directly wired tools given aliases from the mailer (like Ecartis, for 
which addresses of lists seem to show up as mailboxes at most sendmail 
sites running it) need the return path to be accurate the whole time.  The 
bouncer processor in Ecartis, for instance, simply can't work without a 
valid "From [email-masked] date" line, but does the SMTP loopback 
connection thing itself in order to prepare new submissions.

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Sun, 16 Dec 2007 23:29:11 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

On Fri, 14 Dec 2007, Dave Crocker wrote:
>
> In some environments, it is deemed more important for an original author to
> know that there message did not get fully delivered, than to notify the list
> admin of the problem.

I think this is a job for aliases, not lists - and probably not a job for
either. You're assuming that the sender knows who the recipients will be,
which implies a close association between sender and recipients. It also
implies that you aren't near the scaling problems of aliases which drive
many of the bells and whistles of mailing list implementations.

If the sender doesn't know the recipients of an alias or mailing list,
and/or cares about delivery, they'll address the recipients directly.
(This is one of the things that makes it difficult to persuade people to
use role addresses properly.)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: VARIABLE 3 OR 4. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD.

Date: Sat, 15 Dec 2007 18:35:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Cc: Alex van den Bogaerdt <[email-masked]>
Sender: [email-masked]

My bad. I must have been smoking the wrong kind of cigarette.

Date: Sat, 15 Dec 2007 17:13:50 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Dec 15, 2007 at 07:22:44AM -0800, Dave Crocker wrote:

> Alex van den Bogaerdt wrote:
> >On Fri, Dec 14, 2007 at 09:59:39PM -0800, Dave Crocker wrote:
> >>You are confusing delivery notices with post-delivery notices.
> ...
> >*iff* you consider the message not delivered when it arrives at the list
> >host.
> 
> 
> For the scenario I described, the author cares about final delivery to 
> potential readers. So, from that participant's perspective, the mail is not 
> 'delivered' when it arrives at the list processor.

Please see my other reply at 12:20 UTC today, which applies here as well.

regards,
Alex

Date: Sat, 15 Dec 2007 07:22:44 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Alex van den Bogaerdt wrote:
> On Fri, Dec 14, 2007 at 09:59:39PM -0800, Dave Crocker wrote:
>> You are confusing delivery notices with post-delivery notices.
...
> *iff* you consider the message not delivered when it arrives at the list
> host.

For the scenario I described, the author cares about final delivery to 
potential readers. So, from that participant's perspective, the mail is not 
'delivered' when it arrives at the list processor.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 15 Dec 2007 13:20:37 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Dec 15, 2007 at 12:48:46PM +0100, Arnt Gulbrandsen wrote:
> 
> Valdis KlÄ“tnieks writes:
> >I'd be awfully curious to know what use-case it's actually interesting 
> >if the mail was *delivered* to all recipients, but *not* whether all 
> >recipients have actually read/processed the message.
> 
> Here in Germany there are two kinds of whatsitcalled, the kind of postal 
> mail where delivery is recorded. The cheaper kind records delivery into 
> the recipient's mailbox. It's used most of the time, so obviously there 
> are use cases for it. The expensive kind records that the envelope is 
> handed to the recipient personally.
> 
> >Phrased differently - when is it interesting to know that the mail has 
> >been delivered into an abandoned mailbox that hasn't been read in 6 
> >months?
> 
> My bank sends me lots of utterly mail that I am supposed to read within 
> four weeks. If I don't I lose the right to have mistakes fixed. I'm 
> sure the bank would like to know when I first had the opportunity to 
> read the mail.

We're talking about mailing lists.  A proper analogy would be a letter
you write to the newspaper, readers forum part or such.

I do *not* wish to know that one or two of their subscribers did not
receive my letter.  I only want to know that the letter arrived at
the newspaper (or not). Return the letter, or publish it. But don't
inform me that they could not redistribute it to all subscribers.

I cannot fix problems between the newspaper and its subscribers.
I do not need to know that {John Doe, 1st street 123, Somewhere} is
unavailable and will read the paper in three months. I also do not
need to know that Jane Doe now lives Elsewhere, please forward mail.

And now an analogy for an alias:

I tell my secretary to send a letter to the people on the "foo" list.
She will make copies and deliver. I do expect her to inform me when
a message cannot be delivered to John Doe.  If it's important for me
to know, I will explicitly give her instructions to do so, and I will
ask receivers to let me know when they read the letter.

Still, for incoming mail (thus: mail from outside, destined to inside)
which happens to be handled by an alias, I do *not* wish to inform the
sender that, eventhough he wrote to [email-masked]', the message
was not delivered to [email-masked]'.  That's my business,
not the sender's. I don't even *want* the sender to know about these
internal addresses.

In short: I expect that on the internet, with the exception of a few
isolated cases maybe, delivery notifications should always go to the
list admin address (the sender) and never to the person composing the
original message (the author).

In private environments, even when they use the internet for transport,
things may be different. But those are the exceptions, not the other
way around.

Alex

Date: Sat, 15 Dec 2007 12:48:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Valdis KlÄ“tnieks writes:
> I'd be awfully curious to know what use-case it's actually interesting 
> if the mail was *delivered* to all recipients, but *not* whether all 
> recipients have actually read/processed the message.

Here in Germany there are two kinds of whatsitcalled, the kind of postal 
mail where delivery is recorded. The cheaper kind records delivery into 
the recipient's mailbox. It's used most of the time, so obviously there 
are use cases for it. The expensive kind records that the envelope is 
handed to the recipient personally.

> Phrased differently - when is it interesting to know that the mail has 
> been delivered into an abandoned mailbox that hasn't been read in 6 
> months?

My bank sends me lots of utterly mail that I am supposed to read within 
four weeks. If I don't I lose the right to have mistakes fixed. I'm 
sure the bank would like to know when I first had the opportunity to 
read the mail.

Arnt

Date: Sat, 15 Dec 2007 12:32:25 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Dec 14, 2007 at 09:59:39PM -0800, Dave Crocker wrote:
> 
> You are confusing delivery notices with post-delivery notices.
> 
> d/
> 
> [email-masked] wrote:
> >On Fri, 14 Dec 2007 09:49:58 PST, Dave Crocker said:
> >>In some environments, it is deemed more important for an original author 
> >>to know that there message did not get fully delivered, than to notify 
> >>the list admin of the problem.
> >
> >It of course makes sense that the original author be notified if the 
> >message
> >never made it as far as the list.  If, however, it is deemed important that
> >the author be notified of failure to be delivered to *the end user*, the 
> >proper
> >tool in this case is:
> >
> >3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil,
> >     Ed.. May 2004. (Format: TXTd049 bytes) (Obsoletes RFC2298) (Updates
> >     RFC3461, RFC2046) (Status: DRAFT STANDARD)

*iff* you consider the message not delivered when it arrives at the list
host.

Date: Sat, 15 Dec 2007 03:02:13 -0500
From: John C Klensin <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

--On Saturday, 15 December, 2007 02:30 -0500
[email-masked] wrote:

>...
> No, I'm not.
> 
> In almost all the cases I've seen in 25 years, it's the person
> who wants a delivery notification who was confused it - it's
> almost *never* of actual interest merely if the mail was
> *delivered*.  What you *care* about is the *disposition* - if
> it was sent to a human, was it *read*?  If it was sent to a
> daemon, was it *processed*?
>...

Sure.

But the desire for read receipts / notifications runs squarely
into a privacy problem.  A delivery notification is a product of
the transport environment, and such notifications, or their
absence, are generally reliable (at least in the absence of
mailing lists, where there may be a concern about disclosure of
list members and their addresses).  But a significant number of
users view read receipts as an intrusion on privacy and have
them disabled or only selectively enabled, so that non-receipt
of a read receipt message gives one very little information in
the general case.

With both email and postal mail, delivery receipts/notifications
are about the best one can reasonably expect to get.

    john

To: [email-masked]
Cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
From: [email-masked]
Date: Sat, 15 Dec 2007 02:30:33 -0500
Sender: [email-masked]

--=_Exmh_1197703833_8442P
Content-Type: text/plain; charset=us-ascii

On Fri, 14 Dec 2007 21:59:39 PST, Dave Crocker said:
> You are confusing delivery notices with post-delivery notices.

No, I'm not.

In almost all the cases I've seen in 25 years, it's the person who wants
a delivery notification who was confused it - it's almost *never* of actual
interest merely if the mail was *delivered*.  What you *care* about is
the *disposition* - if it was sent to a human, was it *read*?  If it was
sent to a daemon, was it *processed*?

I'd be awfully curious to know what use-case it's actually interesting if
the mail was *delivered* to all recipients, but *not* whether all recipients
have actually read/processed the message.

Phrased differently - when is it interesting to know that the mail has been
delivered into an abandoned mailbox that hasn't been read in 6 months?

--=_Exmh_1197703833_8442P
Content-Type: application/pgp-signature

--=_Exmh_1197703833_8442P--

Date: Fri, 14 Dec 2007 21:59:39 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
CC: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

You are confusing delivery notices with post-delivery notices.

d/

[email-masked] wrote:
> On Fri, 14 Dec 2007 09:49:58 PST, Dave Crocker said:
>> In some environments, it is deemed more important for an original author to 
>> know that there message did not get fully delivered, than to notify the list 
>> admin of the problem.
> 
> It of course makes sense that the original author be notified if the message
> never made it as far as the list.  If, however, it is deemed important that
> the author be notified of failure to be delivered to *the end user*, the proper
> tool in this case is:
> 
> 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil,
>      Ed.. May 2004. (Format: TXTd049 bytes) (Obsoletes RFC2298) (Updates
>      RFC3461, RFC2046) (Status: DRAFT STANDARD)

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Date: Fri, 14 Dec 2007 11:48:36 -0800
Sender: [email-masked]

On Dec 14, 2007, at 9:30 AM, Frank Ellermann wrote:

> Hector Santos wrote:
>
>>> IMHO, 2821bis should state that "putting CNAMES as the target of  
>>> MX records is not allowed, as stated in RFC 2181"
>
> Good idea, maybe it helps to reduce the debates about this issue.

Agreed.

>> this still won't change the BCP requirement for "Industry Ready"  
>> software to recognize it.
>
> That BCP has no number yet, and Doug can be very creative to turn  
> anything in DNS into some kind of attack, with a slight prejudice  
> against SPF's mx-mechanism ;-)

Ouch.  The macro expansion of SPF can initiate subsequent DNS  
transactions against domains constructed from email header and  
parameter components passed to the processing routines.  These  
automatically generated transactions thereby permit a cached RR to  
generate sizeable amounts of independently targeted traffic trigged by  
spam, but not logged by SMTP.  The spam and SPF records can be crafted  
to facilitate DNS poisoning and/or DDoS attacks at _zero_ additional  
cost to spammers.  Do not describe my concern as a _slight_  
prejudice.  MX records were used to just demonstrate this concern with  
available open-source SPF routines.  Imagine how bad it might get when  
full IPv6 support is added to accommodate RFC 3974. :^(

-Doug

To: [email-masked]
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
From: [email-masked]
Date: Fri, 14 Dec 2007 14:21:58 -0500
Sender: [email-masked]

--=_Exmh_1197660118_14126P
Content-Type: text/plain; charset=us-ascii

On Fri, 14 Dec 2007 09:49:58 PST, Dave Crocker said:

> In some environments, it is deemed more important for an original author to 
> know that there message did not get fully delivered, than to notify the list 
> admin of the problem.

It of course makes sense that the original author be notified if the message
never made it as far as the list.  If, however, it is deemed important that
the author be notified of failure to be delivered to *the end user*, the proper
tool in this case is:

3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil,
     Ed.. May 2004. (Format: TXTd049 bytes) (Obsoletes RFC2298) (Updates
     RFC3461, RFC2046) (Status: DRAFT STANDARD)

> With immediate notification of non-delivery, an original author can choose 
> alternate ways to get the message delivered.  For time-sensitive messages, 
> this is an important capability.

If it's that time-sensitive, you really want full end-to-end linkage.

Of course, I'm writing this as somebody who *did* read a time-sensitive note
this morning - after I failed to see it all yesterday because I was busy
being ill.

Just sayin', ya know....

--=_Exmh_1197660118_14126P
Content-Type: application/pgp-signature

--=_Exmh_1197660118_14126P--

Date: Fri, 14 Dec 2007 20:14:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Alex van den Bogaerdt writes:
> Subscribers to a list shouldn't need to know who else is on the list.

Unless, of course, they wish to send a group reply to the list address 
and non-subscribers.

(This message is a group reply.)

Arnt

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Lists and aliases
Date:  Fri, 14 Dec 2007 19:05:25 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 13
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Dave Crocker wrote:

> why is modification of the return path required?

It's only required when forwarding mail to a 3rd party
(or "to another ADMD" in email-arch terminolgy), as it
indicates the transfer of responsibilty as outlined in
RFC 821.

Preserving the spirit of RFC 821 without reverse routes
is a black art.  But ignoring it results in backscatter.

 Frank

Date: Fri, 14 Dec 2007 09:49:58 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Tony Finch wrote:
> On Fri, 14 Dec 2007, Dave Crocker wrote:
>> For one thing, why is modification of the return path required?
> 
> If delivery to one of the recipients fails, does the sender want to know,
> and if they do know, what are they going to do about it?
> 
> The only people that can do anything about bounces are the list managers

Actually, that not 100% correct.  While true about fixing the list problem, it 
does not deal with the problem that a particular message did not get delivered.

In some environments, it is deemed more important for an original author to 
know that there message did not get fully delivered, than to notify the list 
admin of the problem.

With immediate notification of non-delivery, an original author can choose 
alternate ways to get the message delivered.  For time-sensitive messages, 
this is an important capability.

> (or their automated agent), so the bounces should go to them. The only
> time you can get away with leaving the return path is if the only senders
> to the list are the list admins - but in that case changing it does no
> harm and is better for consistency.

Note that my scenario does not expect or require that the notification involve 
the list admin.  It helps, but isn't required.

> This reasoning also applies to fan-out aliases, which is why you need to
> be careful about when you use them. Linear aliases are much safer.

Yup.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 14 Dec 2007 17:41:48 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

On Fri, 14 Dec 2007, Dave Crocker wrote:
>
> For one thing, why is modification of the return path required?

If delivery to one of the recipients fails, does the sender want to know,
and if they do know, what are they going to do about it?

The only people that can do anything about bounces are the list managers
(or their automated agent), so the bounces should go to them. The only
time you can get away with leaving the return path is if the only senders
to the list are the list admins - but in that case changing it does no
harm and is better for consistency.

This reasoning also applies to fan-out aliases, which is why you need to
be careful about when you use them. Linear aliases are much safer.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: SOUTHERLY 7 TO SEVERE GALE 9, DECREASING 4 OR 5 LATER EXCEPT IN FAR
SOUTHEAST. HIGH, OCCASIONALLY VERY HIGH. RAIN AT TIMES. MODERATE OR GOOD,
OCCASIONALLY POOR.

Date: Fri, 14 Dec 2007 18:41:35 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Dec 14, 2007 at 05:13:58PM +0000, Tony Finch wrote:

> > To stress:  The first and second are very similar, but they are not the same
> > and I think the differences are important.
> 
> In which case we should continue to use the term "alias" for type 1, and
> we should continue to discourage type 2a lists that don't change the
> return path.

Indeed. [email-masked] can automatically unsubscribe
me should my email address become unreachable. Someone posting to
this list cannot, and thus has no use for bounces, out of office
messages, delivery notifications and what more.

Subscribers to a list shouldn't need to know who else is on the list.

I post to the list, and as long as this part is transmitted OK I'm
fine. Whatever happens thereafter is the list's problem.

I even can agree with adding a "Sender:" header, to overcome MSes
problem with their SenderID use of SPF records.

Alex

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: MX to CNAME and (mis)interptretation of 2821
Date:  Fri, 14 Dec 2007 18:30:52 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 44
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:
 
>> IMHO, 2821bis should state that "putting CNAMES as the target
>> of MX records is not allowed, as stated in RFC 2181"

Good idea, maybe it helps to reduce the debates about this issue.

> this still won't change the BCP requirement for "Industry Ready" 
> software to recognize it.

That BCP has no number yet, and Doug can be very creative to turn
anything in DNS into some kind of attack, with a slight prejudice
against SPF's mx-mechanism ;-)

> -1 on changing RFC 29821bis.
  +1 for Paul's proposal, maybe adding "so far" to his note, that
     would help if your BCP gets a number (you could add "updates
     2181 and 2821bis" to this BCP as easy as only "updates 2181")

> This SMTP Operational Experience is officially recognized in 
> RFC 3974

With an IESG note almost half as long as that in RFC 4005..4008.
See also the comment about 3974 in 2821bis.  And of course 3974
talks about aliases for the MX, not aliases of the addresses.

> See RFC 974 for historical perspective.
>      http://tools.ietf.org/rfc/rfc974.txt

Oops, now I see why they picked 3974 ;-)  Skipping the WKS magic
RFC 974 states:

| Note that the algorithm to delete irrelevant RRs breaks if
| LOCAL has a alias and the alias is listed in the MX records
| for REMOTE.  (E.g. REMOTE has an MX of ALIAS, where ALIAS has
| a CNAME of LOCAL).  This can be avoided if aliases are never
| used in the data section of MX RRs.
 
> [5] http://tools.ietf.org/rfc/rfc2672.txt

Is DNAME relevant for "industry ready" MTAs, and while we're at
it, what about SRV ?  And should 2821bis mention these issues ?

 Frank

Date: Fri, 14 Dec 2007 09:27:54 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Tony Finch wrote:
>> 1.    I believe the 'alias' function refers to a RCPT-TO multi-cast expansion
...
>> 2a.   Except that the mailing list function can be distinguished by the degree
>> to which the new message is the same as the original message.  When it is
>> essentially identical, except for the RCPT-TO list and some additional
>> handling fields,
...
>> 2b.   Then there are mailing lists that do some amount of additional violence
>> to the message, possibly quite a bit.
...
> In which case we should continue to use the term "alias" for type 1, and
> we should continue to discourage type 2a lists that don't change the
> return path.

I'd like to explore this and see what folk prefer.

I don't have a firm opinion yet.  What you suggest makes sense.  My question 
is whether it both resonates with other folk and whether we can see real 
utility in it (and if so, what?)

For one thing, why is modification of the return path required?  I can 
certainly see legitimate uses of mailing list software (full delivery and then 
re-posting) which chooses to have notifications go to whatever address is in 
the original return path.

That, of course, raises the question of whether this use of a mailing list is 
in any way distinguishable externally from the simpler alias mechanism?  That 
is, does the new message and envelope look different?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 14 Dec 2007 17:13:58 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

On Fri, 14 Dec 2007, Dave Crocker wrote:
> Tony Finch wrote:
> > On Thu, 13 Dec 2007, Dave Crocker wrote:
> > >
> > > While I think the proposed text gets across the distinction folks
> > > are seeking, I'm concerned that it leads to a belief that one or the
> > > other type of activity is not a list.  My own view is that they are
> > > both lists, but the former is a list that restricts itself
> > > sufficiently to qualify as emulating an MTA.
> >
> > I disagree. The distinction between aliases and lists is useful and should
> > not be muddied.
>
> I am suspecting that there are three different functions here, not two.
>
> 1.    I believe the 'alias' function refers to a RCPT-TO multi-cast expansion
> and relaying mechanism that takes place during address resolution within the
> delivery process, but before delivery takes place. [...]
>
> 2a.   Except that the mailing list function can be distinguished by the degree
> to which the new message is the same as the original message.  When it is
> essentially identical, except for the RCPT-TO list and some additional
> handling fields, it is very close to the alias mechanism, but it isn't the
> same.  Still it is seeking to emulate an MTA (doing multicast.)
>
> 2b.   Then there are mailing lists that do some amount of additional violence
> to the message, possibly quite a bit.
>
> To stress:  The first and second are very similar, but they are not the same
> and I think the differences are important.

In which case we should continue to use the term "alias" for type 1, and
we should continue to discourage type 2a lists that don't change the
return path.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTH FITZROY: VARIABLE 3 OR 4. MODERATE OR ROUGH. FAIR. GOOD.

Date: Fri, 14 Dec 2007 08:58:57 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

Tony Finch wrote:
> On Thu, 13 Dec 2007, Dave Crocker wrote:
>> While I think the proposed text gets across the distinction folks are seeking,
>> I'm concerned that it leads to a belief that one or the other type of activity
>> is not a list.  My own view is that they are both lists, but the former is a
>> list that restricts itself sufficiently to qualify as emulating an MTA.  In
>> particular, both have a delivery of the original message and a posting of a
>> new one.
> 
> I disagree. The distinction between aliases and lists is useful and should
> not be muddied.

I am suspecting that there are three different functions here, not two.

1.    I believe the 'alias' function refers to a RCPT-TO multi-cast expansion 
and relaying mechanism that takes place during address resolution within the 
delivery process, but before delivery takes place.

Then there is mailing list function which accepts delivery to the named list's 
address, creates a new message with a new set of addressees and posts the new 
message.

2a.   Except that the mailing list function can be distinguished by the degree 
to which the new message is the same as the original message.  When it is 
essentially identical, except for the RCPT-TO list and some additional 
handling fields, it is very close to the alias mechanism, but it isn't the 
same.  Still it is seeking to emulate an MTA (doing multicast.)

2b.   Then there are mailing lists that do some amount of additional violence 
to the message, possibly quite a bit.

To stress:  The first and second are very similar, but they are not the same 
and I think the differences are important.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 14 Dec 2007 16:51:37 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

On Thu, 13 Dec 2007, Dave Crocker wrote:
>
> While I think the proposed text gets across the distinction folks are seeking,
> I'm concerned that it leads to a belief that one or the other type of activity
> is not a list.  My own view is that they are both lists, but the former is a
> list that restricts itself sufficiently to qualify as emulating an MTA.  In
> particular, both have a delivery of the original message and a posting of a
> new one.

I disagree. The distinction between aliases and lists is useful and should
not be muddied.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NORTH FITZROY SOLE: SOUTHEASTERLY 5 TO 7. MODERATE OR ROUGH, OCCASIONALLY VERY
ROUGH IN WEST. FAIR. MODERATE OR GOOD.

Date: Fri, 14 Dec 2007 10:08:57 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Trevor Paquette <[email-masked]>
CC: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

>> From: Ned Freed 
>>
>> As for updating the specification, I have no problem with adding
 >> a statement that the result of an MX lookup MUST NOT be a
 >> CNAME if there is consensus to do so. I strongly object,
>> however, to adding statements along the lines of "this document 
 >> doesn't update this other RFC". That's a path to madness.

Trevor Paquette wrote:

> I really like this idea. This will solve the problem of
> misinterpretation of the RFC.

I doubt that because this issue predated RFC 2821.

While hugely successful over the years, one of the problems with the 
style of RFC documents (by design) is that they tend to serve a wide 
range of audiences. Specifically, they tend to blend both functional 
design specifications with technical design specifications.  The former 
typically serves management, operations, possible marketing. The latter 
typically serves development and implementation details.

So it depends on who is reading the RFC.

That said, I do not advocate any change to RFC 2821bis, but if there is 
something to point out, IMO, it should be addressed to two parties:

  - DNS operators MUST NOT add CNAME records in MX records as this
    can create extra unnecessary queries.

  - SMTP DNS resolvers SHOULD be prepared for MX lookups
    resolving to CNAME records.

This targets both audiences.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 14 Dec 2007 08:26:16 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

Paul Smith wrote:

> IMHO, 2821bis should state that "putting CNAMES as the target of MX 
> records is not allowed, as stated in RFC 2181"

Paul, I generally agree with your other points in your message.

But this still won't change the BCP requirement for "Industry Ready" 
software to recognize it.  So even if it was stated strongly, what you 
will end up doing is someone new who will implement it as stated and 
then get all bent out of shape when he comes across those CNAME 
situations in the real world.

Guess who has to change?

While he might get on mission and initially succeed in getting DNS 
administrators to change their setups, eventually he will get tired of 
it and begin to recognized and add support for it - bitching and moaning 
at the same time.  If he doesn't - he simply isn't normal. <grin>   The 
fact is, sometimes it is not feasible for DNS setup to be changed.

So IMO, -1 on changing RFC 29821bis.

Consider the fact it is already general practice for DNS software to 
recognize CNAME issues, including but not exclusive to:

     - Watching and Limiting CNAME loops [1]
     - Resolving CNAMES from A records lookups [4] [5]

Yes, it is expected MX resolves to A records [2], the main concern being 
that it will cause extra queries/network burdens and early resolvers did 
not expect it.

But due to the nature of the world, those A records can easily end up 
being CNAME RRs [3].  It is prudent that Industry Ready software be 
prepare for that.  This SMTP Operational Experience is officially 
recognized in RFC 3974 [4]

Mandating it in RFC 2821bis isn't going to change that.  Even if you are 
looking at future generation DNS admins doing things correctly for MX 
resolution, I still say the DNS client software will still need to take 
into account the MX resolution will point to CNAMES, even if the 
practice is deprecated.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

[1] http://tools.ietf.org/rfc/rfc1612.txt

[2] RFC 2181.
     http://tools.ietf.org/rfc/rfc2181.txt

[3] See RFC 974 for historical perspective.
     http://tools.ietf.org/rfc/rfc974.txt

[4] RFC 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments
     http://tools.ietf.org/rfc/rfc3974.txt

[5] http://tools.ietf.org/rfc/rfc2672.txt

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Lists and aliases
Date:  Fri, 14 Dec 2007 13:27:32 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 83
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Dave Crocker wrote:

> RFC2821bis:  "As used in this specification, an "address" is a character
>    string that identifies a user to whom mail will be sent or a location
>    into which mail will be deposited.  The term "mailbox" refers to that
>    depository."
> RFC2822:     "A mailbox receives mail.  It is a conceptual entity which
>    does not necessarily pertain to file storage.
 
> I am sure it will entirely shock folks to hear that I strongly prefer
> the 2822 definition

The RFC 2822 definition is a verbatim copy from RFC 822 6.2,
<http://tools.ietf.org/html/rfc822#section-6.2>

For RFC 821 a mailbox is a "character string (address) which identifies
a user to whom mail is to be sent", and *additionally* "the 'container'
in which mail is stored" (RFC 821 glossary).   For RFC 821 it was still
important to distinguish "mailing" and "sending" (= instant messaging).

2821bis replaces 'container' by 'location', and says 'user or location'
instead of 'user and location', because that's it what it needs for its
purposes.

> and, therefore, also believe that 2821bis' use of the term "pseudo-
> mailbox" needs to be removed.

Maybe the [2]822[upd] mailbox would avoid the introduction of pseudo-
mailbox.  For the [2]821[bis] definition a list or alias (or program
etc.) is no 'user or location'.  For the purposes of 2821bis a mail
to a list or alias is still "in transit", not a final delivery to a
receiver.  

 [simple 2821bis lists vs. "complex" lists]
> In particular, both have a delivery of the original message and a
> posting of a new one.

New messages after delivery are not the business of [2]821[bis].

>| A mailing list can perform a very wide range of modifications to
>| a message and its envelope.

That's no proper mailing list.  A mailing list redistributes the
mail AS IS (signatures still working etc.) from its own address
to the list members, adding useful List-* header fields.  Likewise
an alias forwards the mail AS IS to one or more addresses updating
only the reverse path like all other relays.  

Updating the reverse path is not more possible (or rather it's
pointless), therefore alias forwarding to third parties is not
more allowed, it would eliminate the responsibility for delivery
or error reports at the forwarder.  RFC 821 explains very clearly
what this responsibility actually means and offers 551 for admins
not willing to take it.  IMO 2821bis should finally admit this
RFC 1123 5.3.6() design flaw, documenting bugs is a good thing.

Things mailing lists MUST NOT do:  Modify the body, add or replace
Reply-To, replace Sender.  The 2821bis 3.9 MUST is in essence fine,
it only goes to far wrt List-* header fields.

Folks need to know that most entities claiming to be mailing lists
are not proper mailing lists.  They are some kind of "mediator", 
where good, bad, or ugly are not yet specified in an RFC.

> When a list constrains its processing to the very limited set of
> modifications and actions described here, it is attempting to 
> emulate an MTA. Such lists can be treated as a continuation in
> email transit.

That's the idea, and it's no "emulation", it's the real thing.
As "email transit" is the topic of [2]821[bis] it also fits.

> More elaborate lists need to be viewed as full MUAs, which accept
> a delivery and post a new message.

That's off topic for [2]821[bis], it's discussed in email-arch.

 Frank

Date: Fri, 14 Dec 2007 09:37:01 +0000
To: Hector Santos <[email-masked]>, Arnt Gulbrandsen<[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Cc: [email-masked]
Sender: [email-masked]

At 20:06 13/12/2007, Hector Santos wrote:

>Arnt Gulbrandsen wrote:
>>So if I understand you correctly, you meant to 
>>say: «All current/modern DNS clients will 
>>support the resolution of a CNAME as part of a 
>>MX expansion process, when "current and modern" 
>>is defined to take this issue into account.»
>>That's just a tautology wrapped in some suggestive wording.
>
>(Gawd, this is so silly.)
>
>Arnt,
>
>I guess that depends on how you view or define "Current and Modern."

>I change my statement:
>
>  "Industry ready DNS clients support the resolution of a
>   CNAME as part of a MX expansion process."
>
>Another else, IMO, is mal-practice. <g>
>
>Can we move on?

Hector, the reason I'm 'debating' here is not 
because our software doesn't handle CNAME entries 
as MX records (it does), but because saying 
things like 'all modern' or 'all industry ready' 
or anything else which sounds like 'all good' is 
implying that anything that doesn't is poor 
quality or is breaking standards - when it most certainly isn't.

The debate comes up frequently of whether 
software should try to work around buggy 
implementations or fail them. Some people think 
you should do anything possible to make it work, 
others think you should fail anything which is 
slightly wrong, and most people are somewhere in 
between. One thing most agree on is that we 
should TRY to make sure everything works 
according to standards even if most software can 
work around the non-conformities. That means we 
should strongly discourage people putting CNAMES 
in as MX records - including telling them they're 
wrong if they do. It might work if you do, but 
that doesn't mean that it's an OK thing to do.

Saying that "anything which treats a buggy 
configuration as buggy is 'mal-practice'" is very 
dangerous IMHO. It could lead to people writing 
buggy implementations and saying 'xyz email 
client handles it so it must be right - ignore 
what the standards say, they're not what matters, 
what matters is common practice'.

IMHO, 2821bis should state that "putting CNAMES 
as the target of MX records is not allowed, as stated in RFC 2181"

Date: Thu, 13 Dec 2007 18:40:19 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Lists and aliases (Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1))
Sender: [email-masked]

(Please note that I'm directing this to the ietf-smtp list, in order to target
folks who have more history on the topic. /d)

Ned Freed wrote:
> 
> 
>> --On 10. desember 2007 15:22 -0800 Ned Freed <[email-masked]> 
>> wrote:
> 
>>>> 2. The mailing lists described in 2821 are very simple redistribution
>>>>  lists, as opposed to the "fairly sophisticated forums for group 
>>>> communication" [2919] described in these documents. For simple 
>>>> aliasing and redistribution lists, I think the "MUST be left 
>>>> unchanged" is appropriate.
>>> 
>>> The key point is that this is redistribution prior to final delivery. 
>>> Sophisticated list processors in effect submit a new message to the 
>>> transport infrastructure and do not fall under this prohibition.
> 
>> Would it be a reasonable thing to add a note saying that "there exist 
>> things that call themselves lists but are doing processing other than 
>> what is described here; such lists should be described as delivery
>> followed by a submission, and alterations are therefore outside the
>> rules"?
> 
> Seems like a reasonable addition to me.

Folks,

Oh boy.  When I started to write this note, it had a very focused intent.  As
I started writing it, I uncovered some issues I think too serious to ignore:

1.  RFC2821bis needs a glossary.  At the least, I do not see a definition of
'mailing list' or 'alias' in 2821bis, nor 'redistribution' or 'forward'. So
2821bis uses essential terms without defining them.

2.  RFC2821bis has a different, and I believe significantly incompatible,
definition of mailbox from that in rfc2822:

     RFC2821bis:  "As used in this specification, an "address" is a character
     string that identifies a user to whom mail will be sent or a location into
     which mail will be deposited.  The term "mailbox" refers to that
     depository."

     RFC2822:  "A mailbox receives mail.  It is a conceptual entity which does
     not necessarily pertain to file storage.

I am sure it will entirely shock folks to hear that I strongly prefer the 2822
definition and, therefore, also believe that 2821bis' use of the term
"pseudo-mailbox" needs to be removed.

I do not believe that resolving these issues alters 2821 as a protocol, so
there will be no need to worry about recycling at Proposed.  But these changes 
would greatly increase the document's clarity (or at least precision) and 
compatibility between 2821 and 2822.

I'll wait to see how folks react to the above (on this ietf-smtp list, please)

As for the more narrow topic at hand:

While I think the proposed text gets across the distinction folks are seeking,
I'm concerned that it leads to a belief that one or the other type of activity
is not a list.  My own view is that they are both lists, but the former is a
list that restricts itself sufficiently to qualify as emulating an MTA.  In
particular, both have a delivery of the original message and a posting of a
new one.

For the particular wording changed being discussed here -- I lost track;
section 3.9.2, right? -- I'm inclined to something along the lines of:

    A mailing list can perform a very wide range of modifications to a message 
and its envelope. When a list constrains its processing to the very limited 
set of modifications and actions described here, it is attempting to emulate 
an MTA. Such lists can be treated as a continuation in email transit. More 
elaborate lists need to be viewed as full MUAs, which accept a delivery and 
post a new message.

ok.  start shooting...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 13 Dec 2007 15:06:10 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> So if I understand you correctly, you meant to say: «All current/modern 
> DNS clients will support the resolution of a CNAME as part of a MX 
> expansion process, when "current and modern" is defined to take this 
> issue into account.»
> 
> That's just a tautology wrapped in some suggestive wording.

(Gawd, this is so silly.)

Arnt,

I guess that depends on how you view or define "Current and Modern."

But I see your point.  Lets explore:

   "Current/modern DNS clients support the resolution of
   a CNAME as part of a MX expansion process."

Some make logical argue this is also a taulogy as one may argue, a 
Current/Modern takes all these issues into account and there is nothing 
new added.

Of course, there is implied semantic "Current/Modern" is akin to "Best 
Current Practice", but I'm sure people will argue that as well.

It is also true to exist current and modern DNS clients which neglect to 
take issue into account, but one might arguable debate they are not 
current and modern or following best practice or expected practice.

We can also explore:

    "Most ..."              Safe in this list (A lie to me)
    "Most, if not all,"     Safe, acceptable even if wrong
    "Some...."              Would be more wrong than correct
    "Industry Ready"        I like it!

I change my statement:

  "Industry ready DNS clients support the resolution of a
   CNAME as part of a MX expansion process."

Another else, IMO, is mal-practice. <g>

Can we move on?

-- 
Hector Santos, CTO
http://www.santronics.com

Content-class: urn:content-classes:message
Subject: RE: Re: MX to CNAME and (mis)interptretation of 2821
Date: Thu, 13 Dec 2007 10:06:00 -0700
From: "Trevor Paquette" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]] 
> Sent: Wednesday, December 12, 2007 5:25 PM
> To: Trevor Paquette
> Cc: [email-masked]
> Subject: RE: Re: MX to CNAME and (mis)interptretation of 2821
>
> As for updating the specification, I have no problem with adding a
statement that the result of an MX lookup
> MUST NOT be a CNAME if there is consensus to do so. I strongly object,
however, to adding statements along
> the lines of "this document doesn't update this other RFC". That's a
path to madness.

I really like this idea. This will solve the problem of
misinterpretation of the RFC.

Cc: Paul Smith <[email-masked]>, [email-masked]
From: "Derek J. Balling" <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Date: Thu, 13 Dec 2007 10:15:07 -0500
Sender: [email-masked]

--Apple-Mail-768-208375866
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Dec 13, 2007, at 9:21 AM, Hector Santos wrote:
> To me, "Current and Modern" DNS client software takes into account  
> the idiosyncrasies of the system, including this very common issue.   
> So if a  current/modern DNS client is ignorant of such issues, well,  
> think what you wish - it will be viewed as "buggy" and if you deal  
> customer service business, it will be your problem.

I think that depends a lot on your environment. In a lot of  
environments, "$OTHERPLACE has their DNS borked in such a way that it  
breaks the standards and causes an error" is an acceptable response,  
and sufficient to close a problem-report.

Cheers,
D

--

Derek J. Balling
Manager of Systems Administration
Vassar College
124 Raymond Ave
Box 0406 - Computer Center 229
Poughkeepsie, NY 12604
W:	(845) 437-7231
C:	(845) 249-9731

--Apple-Mail-768-208375866
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-768-208375866--

Date: Thu, 13 Dec 2007 15:53:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

So if I understand you correctly, you meant to say: «All current/modern 
DNS clients will support the resolution of a CNAME as part of a MX 
expansion process, when "current and modern" is defined to take this 
issue into account.»

That's just a tautology wrapped in some suggestive wording.

Arnt

Date: Thu, 13 Dec 2007 09:21:59 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

Paul Smith wrote:
> At 00:08 13/12/2007, Hector Santos wrote:
> 
>> Trevor,
>>
>> Who is right or wrong is a matter of historical perspective.
>>
>> The fact is this:
>>
>> All current/modern DNS clients will support the resolution of a CNAME 
>> as part of a MX expansion process.
> 
> No. That should be '_Many_ current/modern...' or even '_Most_...', but 
> to say 'All' is presumptive.
> 

Well Pardon me!

To me, "Current and Modern" DNS client software takes into account the 
idiosyncrasies of the system, including this very common issue.  So if a 
  current/modern DNS client is ignorant of such issues, well, think what 
you wish - it will be viewed as "buggy" and if you deal customer service 
business, it will be your problem.

-- 
Hector Santos, CTO
http://www.santronics.com

Date: Thu, 13 Dec 2007 12:24:08 +0000
To: Hector Santos <[email-masked]>, Trevor Paquette<[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Cc: [email-masked]
Sender: [email-masked]

At 00:08 13/12/2007, Hector Santos wrote:

>Trevor,
>
>Who is right or wrong is a matter of historical perspective.
>
>The fact is this:
>
>All current/modern DNS clients will support the resolution of a 
>CNAME as part of a MX expansion process.

No. That should be '_Many_ current/modern...' or even '_Most_...', 
but to say 'All' is presumptive.

RFC 2821 definitely doesn't allow CNAMEs as the bit that the MX is 
pointing to. It does allow it as the bit it's pointing _from_, but 
that's different.

Just because many people have written their software that works 
around bugs in some DNS configurations doesn't mean that those buggy 
DNS configurations are right.

Given that it would take about 2 minutes for TrendMicro to fix their 
DNS configuration, I really don't see what the fuss is about from 
their POV. They're wrong. Everyone else is right to complain. If 
TrendMicro hadn't been told about the problem, their configuration 
would be understandable, but now it just seems like stubbornness. In 
the time they took to write their knowledgebase article explaining 
why they're doing wrong, they could have fixed the problem 10 times over.

They even admit that some older software may not work with their DNS 
configuration - but it would be trivial to fix it, so why don't they???

RFC 2181 isn't updated or obsoleted by RFC 2821, so it still applies today.  

From: Douglas Otis <[email-masked]>
To: Trevor Paquette <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Date: Wed, 12 Dec 2007 23:40:39 -0800
Cc: <[email-masked]>
Sender: [email-masked]

On Dec 12, 2007, at 2:33 PM, Trevor Paquette wrote:

> However, in talking to TrendMicro, they say that this syntax is  
> perfectly valid and that RFC 2821 overrides the MX to CNAME  
> limitation. The following website is their stance on this:http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667

CNAMES returned for MX queries can cause problems.

In this case, the CNAME is a placeholder offered by a DNS provider who  
normally deals with websites.  The name contained within the CNAME RR  
needs to be published as an MX record to avoid returning the CNAME  
itself.

Section 10.3 of RFC 2181 is fairly clear, where this section is not  
updated by the follow-on documents.

> However, in talking to others, they say that TrendMicro is  
> misinterpreting the RFC. I’ll admit after reading 2821, I could  
> interpret things both ways.

RFC 2821 section 3.6 is somewhat misleading, and Ned has explained why  
fairly well.

> This is why I come to you folks who are responsible for this RFC.  
> Who is right? Is MX -> CNAME now allowed by 2821, or is TrendMicro  
> in the wrong?
> Would it also be possible to state directly within the next revision  
> of the RFC where or not this RFC overrides the provision 10.3 of RFC  
> 2181. I don’t want to leave things left to misinterpretation.

The on-line advice published by Trend needs to be updated.  AFAIK, the  
IMHS support staff will not make this recommendation.

-Doug

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
To: David MacQuigg <[email-masked]>
Subject: Re: Authentication/Reputation, TBR (was Everyone Greylists...)
Date: Wed, 12 Dec 2007 16:44:59 -0800
Sender: [email-masked]

On Dec 12, 2007, at 11:42 AM, David MacQuigg wrote:

>>> Hiding valid email addresses is a fundamentally insoluble  
>>> problem.   If legitimate senders can find out when an address is  
>>> invalid (which they must if we are to preserve reliability), then  
>>> spammers can do the same.  Perhaps we can sacrifice some  
>>> reliability for a little more security, e.g. by sending "nosuch  
>>> recipient" rejects only when the sender is authenticated and  
>>> reputable.  The rest can be tempfailed until they give up.
>>
>> This is solvable.  TBR can both limit discovery of valid email-  
>> addresses AND greatly improve delivery integrity.
>
> Section 3.2 of the TBR draft says '''
>   If no valid RCPT TO address is
>   supplied, the TBR command will simply fail.  If at least one valid
>   RCPT TO address is supplied, then the TBR eXAM-URI argument will be
>   accepted.'''
>
> Doesn't this give the sender the same information as a "nosuch  
> recipient" SMTP reject?

It is fairly common (although fairly problematic) for inbound MTAs to  
use different "valid recipient lists" as messages are forwarded to  
their destination.  With TBR, an MTA may accept any local-part for a  
domain, where subsequent MTAs are then able to silently eliminate  
recipients subsequently considered invalid.  Expunging recipient TBR  
references does not mandate DSNs to maintain delivery integrity, since  
fetching a message represents acceptance of an obligation to ensure  
delivery or report failure.

>>>> Providers of domain names, IP addresses, or certificates have a  
>>>> conflict of interest, and are unable to prevent access to spammers.
>>>
>>> Unwilling, not unable.
>>
>> Unwilling, and likely unwise.  There remains an inherent conflict  
>> of interest.  Using registration to limit access may also lead to  
>> forms of extortion.  What type of non-repudiation protects innocent  
>> domains?  Must all messages be signed by a CA?  What limits the  
>> number of certificates issued?  Should all certificates be aged 30  
>> days before being accepted?
>
> I'm no expert here, but it seems that all of these would be  
> effective if we had a good reputation system in place.

A reputation system is reactive.  Abuse tactics are able cycle within  
minutes where reputation would be much after this activity.

>  Then we wouldn't need high security, just enough to raise the cost  
> of abusable IDs above the profit from one short spam run.  I'm  
> guessing that profit is somewhere around $100.

Should Gmail charge $100 for their email service?  Why expect $100  
charges against a stolen credit cards will limit abuse?

> A corporate registration would do it, or maybe a valid credit card  
> with no reported theft in 30 days, or even just a Paypal account.

Domain registrars are not willing to hold requests for even 24 hours.   
Any credit card or online account can be compromised.  As it is now,  
bad actors are able to publish their domain 24 hours before even  
cooperative registries indicate which domains are new.  The domain  
registry process demonstrates the inherent conflict of interest with  
providing access and preventing abuse.

> We can "piggyback" on the ID checking done by the financial-services  
> industry, which has a lot more to lose than a domain-name vouching  
> service.

The many many millions of entities wanting a domain reside in almost  
every country using different currencies and communication systems.  A  
consortium of postal services might be able to handle a centralized  
registration process.  Perhaps by correlating domain names with a  
physical postal addresses.  This would likely create a cottage  
industry aimed at generating domain names used by abusers.

> All of this applies only to those who need to "jump start" a new  
> legitimate ID.  A good reputation can also be built by simply  
> sending lots of good mail and very little spam to many receivers  
> over a long time.

There remains an inherent conflict of interest, in addition to  
compromised systems infiltrating otherwise reputable domains, and of  
course more time is needed to accrue meaningful reputations.  The TBR  
mechanism affords perhaps 20 minutes needed to resolve reputations  
from questionable sources.

>> Messages can be submitted as legitimate users, but likely originate  
>> from compromised systems.  Correlating source patterns and overall  
>> volume determines the trend.
>
> I think I understand what you are saying.  Zombies are sending spam  
> not directly, but through their ISP's outgoing mail servers.  The  
> ISP needs better authentication, rate-limits, etc.  Most large ISPs  
> (aol.com, yahoo.com, etc.) have this type of abuse under control.

Some are better than others.  Bad actors seek out networks imposing  
fewer limitations and may see dial-ups or port 25 blocking as a  
limitation, for example.

>> Blocking port 25 is not a complete solution.  Compromised systems  
>> can bypass such blocks.  In the case of compromised systems, abuse  
>> is widely diffused such that rate limiting and outbound content  
>> filtering offers diminished relief.
>
> I'm seeing very little spam from the authorized transmitters of  
> aol.com, yahoo.com, and most other legitimate senders.  Eliminating  
> outgoing spam is not that difficult.

With an exponential trend, detection failures may be manageable now,  
but are not likely to remain that way.  Reliance upon content  
filtering appears to be creating increasingly difficult to detect spam  
and malware.

>> Agreed, but then this also runs into conflicts of interest.  An  
>> email-provider often does not want credit.  TBR demands an  
>> identity, a matching MailFrom, and an MX record.  In addition, TBR  
>> better identifies a problem source, and not just the last MTA  
>> "holding the bag" so to speak.
>
> An email provider that "does not want credit", or more accurately,  
> one that "is unwilling to assume responsibility" for what is sent in  
> its name, gets the reputation it deserves.

When the domains are large, blocking just at the domain will cause a  
significant amount of collateral damage.  When domain level blocking  
is used to triage limited resources, head of queue blocking will  
become increasing predominate problems.

> The last MTA on the sending side (the "transmitter" in my  
> terminology) is more than a "bag holder".  Of all the parties  
> involved in handling email, the operator of that transmitter is in  
> the best position to stop spam.  Google.com cannot deny that its  
> transmitters are sending spam.
>
> Google's problem is likely a conflict of interest.  It wants new  
> accounts so much that it is making it too easy for spammers to sign  
> up for these accounts.  The fix is not costly, however.  They just  
> need to segregate the new accounts, and until they earn some trust,  
> use a different HELO name, and apply more rigorous rate-limits and  
> filtering.

A widespread abuse problem has been seen by most large email  
providers, where even Google has improved their process.  Eliminating  
organizations who attract large numbers of new users seems counter  
productive, as these domains also represent desired sources of email.

>> When spam must comply with grey-listing, transactions will  
>> dramatically increase.  The vast majority of email is spam where a  
>> percentage can not be detected based upon content.
>
> You may be right.  I'm seeing a still small but growing percentage  
> getting past SpamAssassin.
>
> I can see this heading to either of two endpoints.  Either the  
> spammers will win, overwhelming the statistical filters and forcing  
> everyone to sign up with a large ESP with the resources to work out  
> individual arrangements with other large ESPs, or we find a way to  
> hold senders responsible, and as you say "shift the burden to the  
> transmitter", where it is 1000X easier to deal with.
>
> If the spammers win, the anti-spam industry and a few large ESPs can  
> look forward to a long and prosperous future.

There is no profit allowing spammers to win.  Spam represents a  
growing waste of resources.  Instead of one receiving server accessed  
over a single path, email now often travels over two or more paths  
through an array of servers needed to meet a resource demand.  When a  
small and growing percentage of spam slips past filters, and there is  
a rapidly growing volume and diversity of sources, customers will  
perceive a problem with the service.

> I hope TBR succeeds, but I suspect that the cost to both senders and  
> receivers will outweigh the benefit of prompt delivery.

Deployment of TBR would be able to better ensure prompt delivery.  The  
cost to the transmitter needs to be increased, while also reducing  
costs for the receiver.

> The cost of publishing CSV records was very little, and it went  
> nowhere.  Nothing wrong technically, just a lack of sender motivation.

I do not agree as CSV can offer path registration as well.  This path  
would be by name instead of a large IP address list.  CSV can insure  
an upper limit of a couple of transactions instead of 10 x N  
transactions needed to construct possibly sizeable IP address lists.   
CSV could have provided an authorization scheme using a sha1 base32  
label published withn the authorizing domain.  This approach scales to  
any number of servers associated with a domain without increasing the  
transactions performed by receivers.  Too many wanted fairly dangerous  
scripts risking DNS instead. : (

> I think to get widespread adoption, the cost and risk must be not  
> much more than publishing an SPF record ending in ?all, and less  
> than the cost of publishing CSV records.

Ensuring messages are handled in a timely fashion will likely justify  
rather extensive changes.  As the problem grows, moving nearly the  
entire burden to the transmitter will not be a difficult sell.  It  
will likely become perhaps the only choice.

> I think senders may need a kick in the pants.  I'm thinking of an  
> SMTP reject, with a message like "Sorry, your authentication records  
> are insufficient, and we cannot assess the reputation of <domain>.   
> Your message will be sent to our quarantine, but we cannot guarantee  
> delivery.  If it is important, call your recipient to make sure they  
> got it."

There will not be any new notifications.  No one wants to explain  
anything to users.  Its too damn expensive.  Things will just become  
increasingly broken.

-Doug

From: [email-masked]
Cc: [email-masked]
Date: Wed, 12 Dec 2007 16:24:47 -0800 (PST)
Subject: RE:  Re: MX to CNAME and (mis)interptretation of 2821
To: Trevor Paquette <[email-masked]>
Sender: [email-masked]

> Sounds to me like this is a great opportunity to get this resolved once
> and for all. If the intent of 2821 was never to override the provisions
> of 2181, then Mr. Klensin could state this specifically within the RFC.

I have already explained why I believe this to be a bad idea.

> I believe that the confusion lies around the CNAME provision dealing the
> left hand side of the MX record, not the right hand side. This is where
> people get confused. The following paragraph can be interpreted to allow
> CNAMES as the result of an MX lookup; this paragraph may need to be
> clarified:

> 5.1.  Locating the Target Host
>  ..... The lookup first attempts to locate an MX record associated with
> the name.  If a CNAME record is found instead, the resulting name is
> processed as if it were the initial name.  If no MX records are found,
> but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA RR, or
> their successors) is found, the address RR is treated as if it was
> associated with an implicit MX RR, with a preference of 0, pointing to
> that host....

> That is the section that is confusing people. You can read it to say
> "When you do an MX record lookup, and the result is a CNAME, then ...
> blah blah blah.."

That might be the case if the sentence didn't end with "as it it were the
initial name". Given that clause there's no way to read it as applying to the
MX result and have the resulting operation make sense. THis reading would
effectively allow an MX to refer to another MX through a CNAME, which is
clearly not the intent and I believe is in fact banned elsewhere.

> To the folks that I've talked to, they say that this
> one statement allows an MX record to point to a CNAME. Again, if is this
> not the case nor the intention, I'd love to see this latest revision
> updated to categorically state that.

John will have to speak to the intention, but I have to say that the examples
provided thus far (and I note that the Trend Micro did not in fact cite this
particular section in their attempt to justify their behavior) are a long way
from making the case that it is reasonable to read 2821 this way.

As for updating the specification, I have no problem with adding a statement
that the result of an MX lookup MUST NOT be a CNAME if there is consensus to do
so. I strongly object, however, to adding statements along the lines of "this
document doesn't update this other RFC". That's a path to madness.

				Ned

Date: Wed, 12 Dec 2007 19:08:46 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Trevor Paquette <[email-masked]>
CC: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

Trevor,

Who is right or wrong is a matter of historical perspective.

The fact is this:

All current/modern DNS clients will support the resolution of a CNAME as 
part of a MX expansion process.

You can see it yourself, NSLOOKUP also resolves the CNAME reference.  Is 
NSLOOKUP wrong?  No. It did the right thing as well as all current DNS 
clients will do when they do a MX request and expand the result.

In short,

  MX --> list of host names --> expansion

The expansion starts with a A record to obtain the IP addresses.  If the 
A record lookup returns a CNAME to another host name, you need to do A 
record lookup again on this host to get the IPs.

If the DNS client does not do this, it will undoubtedly come across a MX 
request that may fail or have be incomplete its in MX expansion.

PS: dnsstuff.com does not have a copyright on correctness. On two 
occasions over the many years, I have pointed their own 
misinterpretations or improper usages of their otherwise fine tools.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Trevor Paquette wrote:
> I’m currently at odds with a few folks regarding the interpretation of 
> RFC 2821 and the case of MX records that resolve to CNAMEs. I’m hoping 
> that those here, who are authoritative when it comes to this RFC, can 
> shed some light.
> 
>  
> 
> Take the following case:
> 
> % nslookup -q=mx fleetpride.com
> 
> Non-authoritative answer:
> 
> fleetpride.com  mail exchanger = 10 in.sjc.mx.trendmicro.com.
> 
> fleetpride.com  mail exchanger = 20 mx-in01.mail-abuse.org.
> 
> fleetpride.com  mail exchanger = 20 mx-in02.mail-abuse.org.
> 
> fleetpride.com  mail exchanger = 20 mx-in03.mail-abuse.org.
> 
>  
> 
> Authoritative answers can be found from:
> 
> fleetpride.com  nameserver = ns1-auth.sprintlink.net.
> 
> fleetpride.com  nameserver = ns2-auth.sprintlink.net.
> 
> fleetpride.com  nameserver = ns3-auth.sprintlink.net.
> 
> ns1-auth.sprintlink.net internet address = 206.228.179.10
> 
> ns2-auth.sprintlink.net internet address = 144.228.254.10
> 
> ns3-auth.sprintlink.net internet address = 144.228.255.10
> 
>  
> 
> % nslookup in.sjc.mx.trendmicro.com.
> 
> Non-authoritative answer:
> 
> in.sjc.mx.trendmicro.com        canonical name = 
> in.mx.trendmicro-fail-over.akadns.net.
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.15
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.16
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.1
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.2
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.3
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.4
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.13
> 
> Name:   in.mx.trendmicro-fail-over.akadns.net
> 
> Address: 216.99.131.14
> 
>  
> 
> According to RFC 2181, this is invalid. You cannot have an MX record 
> that resolves to a CNAME.
> 
>  
> 
> However, in talking to TrendMicro, they say that this syntax is 
> perfectly valid and that RFC 2821 overrides the MX to CNAME limitation. 
> The following website is their stance on this: 
> http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667 
> <http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667>
> 
>  
> 
> However, in talking to others, they say that TrendMicro is 
> misinterpreting the RFC. I’ll admit after reading 2821, I could 
> interpret things both ways.
> 
>  
> 
> This is why I come to you folks who are responsible for this RFC. Who is 
> right? Is MX -> CNAME now allowed by 2821, or is TrendMicro in the wrong?
> 
> Would it also be possible to state directly within the next revision of 
> the RFC where or not this RFC overrides the provision 10.3 of RFC 2181. 
> I don’t want to leave things left to misinterpretation.
> 
>  
> 
>  
> 
> --
> 
> Trevor Paquette
> 
> Director, Information Technology and Systems
> 
> TeraGo Networks Inc.
> 
> 300, 300 Manning Road NE
> 
> Calgary, Ab T2E 8K4
> 
> http://www.terago.ca <http://www.terago.ca/>
> 
> W: (403) 668-5321
> 
> C: (403) 703-8738
> 
>  
> 
>  
> 

Date: Thu, 13 Dec 2007 01:03:58 +0100
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Dec 12, 2007 at 03:33:21PM -0700, Trevor Paquette wrote:
> I'm currently at odds with a few folks regarding the interpretation of
> RFC 2821 and the case of MX records that resolve to CNAMEs. I'm hoping
> that those here, who are authoritative when it comes to this RFC, can
> shed some light.

I am not authoritative, nevertheless I wish to comment on this.

> However, in talking to TrendMicro, they say that this syntax is
> perfectly valid and that RFC 2821 overrides the MX to CNAME limitation.
> The following website is their stance on this:
> http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&i
> d=EN-1035667

The solution mentions "Section 5" of 2821 which discusses

CNAME->MX->mailhost

and they (ab)use it to defend

MX->CNAME->mailhost

which is just not the same, at all.

> However, in talking to others, they say that TrendMicro is
> misinterpreting the RFC. I'll admit after reading 2821, I could
> interpret things both ways.

I can see how 3.6 can be interpreted the wrong way, but it does
not (IMHO) overrule 2181.  Neither does 2821 claim to obsolete or
update 2181.

2821 2.3.5 says:
Domain names are used as names of hosts and of other entities in
the domain name hierarchy.  For example, a domain may refer to an
alias (label of a CNAME RR) or the label of Mail eXchanger records 

If these exist:
mailrelay.example.com.  MX      10 mailhost01.example.com.
alias.example.com.      CNAME   canonicalname.example.com.

then 2.3.5 talks about mailrelay and alias, not about
mailhost01 or canonicalname.

Trendmicro uses it to defend "mailhost01.example.com." being an alias.

my 2ct
Alex

Date: Thu, 13 Dec 2007 13:00:42 +1300
To: [email-masked]
From: Glenn Anderson <[email-masked]>
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Sender: [email-masked]

At 3:33 pm -0700 12/12/2007, Trevor Paquette wrote:
>According to RFC 2181, this is invalid. You cannot have an MX record 
>that resolves to a CNAME.

Section 2.4 of RFC 1912 also says "Don't use CNAMEs in combination 
with RRs which point to other names like MX, CNAME, PTR and NS."

>However, in talking to TrendMicro, they say that this syntax is 
>perfectly valid and that RFC 2821 overrides the MX to CNAME 
>limitation.

Nowhere in RFC 2821 does it say that it obsoletes or updates RFC 1034 or 2181.

Glenn.

Content-class: urn:content-classes:message
Subject: RE:  Re: MX to CNAME and (mis)interptretation of 2821
Date: Wed, 12 Dec 2007 16:49:23 -0700
From: "Trevor Paquette" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Sounds to me like this is a great opportunity to get this resolved once
and for all. If the intent of 2821 was never to override the provisions
of 2181, then Mr. Klensin could state this specifically within the RFC.

I believe that the confusion lies around the CNAME provision dealing the
left hand side of the MX record, not the right hand side. This is where
people get confused. The following paragraph can be interpreted to allow
CNAMES as the result of an MX lookup; this paragraph may need to be
clarified:

5.1.  Locating the Target Host
 ..... The lookup first attempts to locate an MX record associated with
the name.  If a CNAME record is found instead, the resulting name is
processed as if it were the initial name.  If no MX records are found,
but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA RR, or
their successors) is found, the address RR is treated as if it was
associated with an implicit MX RR, with a preference of 0, pointing to
that host....  

That is the section that is confusing people. You can read it to say
"When you do an MX record lookup, and the result is a CNAME, then ...
blah blah blah.." To the folks that I've talked to, they say that this
one statement allows an MX record to point to a CNAME. Again, if is this
not the case nor the intention, I'd love to see this latest revision
updated to categorically state that.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Frank Ellermann
Sent: Wednesday, December 12, 2007 4:13 PM
To: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821

Trevor Paquette wrote:

> Would it also be possible to state directly within the next
> revision of the RFC where or not this RFC overrides the 
> provision 10.3 of RFC 2181.

The Last Call for 2821bis ends 2007-12-24:

<http://tools.ietf.org/html/draft-klensin-2821bis> is 2821bis,
and <http://permalink.gmane.org/gmane.ietf.announce/22584> is
a copy of the running Last Call.

> I don't want to leave things left to misinterpretation.

I've seen at least one flamewar about this on another list. 

 Frank

From: [email-masked]
Cc: [email-masked]
Date: Wed, 12 Dec 2007 15:24:31 -0800 (PST)
Subject: Re: MX to CNAME and (mis)interptretation of 2821
To: Trevor Paquette <[email-masked]>
Sender: [email-masked]

> I'm currently at odds with a few folks regarding the interpretation of
> RFC 2821 and the case of MX records that resolve to CNAMEs. I'm hoping
> that those here, who are authoritative when it comes to this RFC, can
> shed some light.

First of all, as a practical matter, people set things up this way on a regular
basis. Additionally, the strategy a lot of software uses to process the results
of MX lookups (i.e., call some external resolver library) not only will allow
CNAMEs to be used and may even be incapable of detecting that a CNAME was used.

As such, such  setups "mostly work" irrespective of their standards status. And
even if you're technically in the right when arguing such a point, it can be
difficult to rebut the "but it works with everyone's else's system so why not
yours?" argument.

> According to RFC 2181, this is invalid. You cannot have an MX record
> that resolves to a CNAME.

Correct. And you should also note that RFC 2181 is conspicuous by its absence
from the list of RFCs that RFC 2821 updates. That provides a fairly strong
indication that the rules it establishes are still in force.

> However, in talking to TrendMicro, they say that this syntax is
> perfectly valid and that RFC 2821 overrides the MX to CNAME limitation.
> The following website is their stance on this:
> http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&i
> d=EN-1035667

> However, in talking to others, they say that TrendMicro is
> misinterpreting the RFC. I'll admit after reading 2821, I could
> interpret things both ways.

I don't think TrendMicro's reading is sensible. They quote sections  2.3.5 and
5 of RFC 2821 as supporting their claim. The relevant text is:
	
  "Domain names are used as names of hosts and of other entities in the domain
  name hierarchy. For example, a domain may refer to an alias (label of a CNAME
  RR) or the label of Mail exchanger records to be used to deliver mail instead
  of representing a host name."
  	 
and:

  "Once an SMTP client lexically identifies a domain to which mail will be
  delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup
  MUST be performed to resolve the domain name [22]. The names are expected to be
  fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from
  partial names or local aliases are outside of this specification and, due to a
  history of problems, are generally discouraged. The lookup first attempts to
  locate an MX record associated with the name. If a CNAME record is found
  instead, the resulting name is processed as if it were the initial name." 

In both of these paragraphs it is quite clear that the CNAME being referred to
is one associated with the initial lookup of the domain extracted from the
email address. This text is entirely silent about CNAMEs produced by an MX
lookup. And since it is silent on this point the rules of RFC 2181 remain in
force.

> This is why I come to you folks who are responsible for this RFC. Who is
> right? Is MX -> CNAME now allowed by 2821, or is TrendMicro in the
> wrong?

> Would it also be possible to state directly within the next revision of
> the RFC where or not this RFC overrides the provision 10.3 of RFC 2181.
> I don't want to leave things left to misinterpretation.

It's possible but IMO not a good idea. Sure, we could state that this condition
remains in force, but what does that then mean if there were a revision to RFC
2181 that changed the requirement in some way? Additionally, there's a
slippery slope we're getting close to: If we start listing all the stuff
that a given RFC doesn't override where do we draw the line?

No, the way this is supposed to work - and IMO should work - is that when an
RFC overrides a condition imposed by another that RFCs says explicitly that it
is doing exactly that and lists the RFC it is overriding in the Updated: list.

Now, some may point out that there have been cases where one RFC updated
another but didn't say so. If that's found to be the case we have this thing
called an RFC errata process and I see no reason why it couldn't be used in
such cases.

				Ned

From: "Derek J. Balling" <[email-masked]>
To: [email-masked]
Subject: Re: MX to CNAME and (mis)interptretation of 2821
Date: Wed, 12 Dec 2007 18:44:50 -0500
Sender: [email-masked]

--Apple-Mail-525-152558198
Content-Type: multipart/alternative;
	boundary=Apple-Mail-524-152558118

--Apple-Mail-524-152558118
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Dec 12, 2007, at 5:33 PM, Trevor Paquette wrote:
> However, in talking to TrendMicro, they say that this syntax is  
> perfectly valid and that RFC 2821 overrides the MX to CNAME  
> limitation. The following website is their stance on this:http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667

I'll speak to how TrendMicro appears to be misinterpreting RFC2821. :-)

"Domain names are used as names of hosts and of other entities in the  
domain name hierarchy. For example, a domain may refer to an alias  
(label of a CNAME RR) or the label of Mail exchanger records to be  
used to deliver mail instead of representing a host name."

This is defining "what a domain is".  A "label", as defined in  
RFC1035, is (in simple terms) the left portion of a DNS record. If  
you're looking at a record like:

foo IN MX 0 mailhost

"foo" is the label, and that label is made up of a domain name. There  
are other places domain names might appear (such as in CNAME or MX  
RDATA), but I don't think anything in RFC2821/2.3.5 is saying that MXs  
can have hosts that resolve to CNAMEs in their RDATA.

They further reference section 5, quoting:

"Once an SMTP client lexically identifies a domain to which mail will  
be delivered for processing (as described in sections 3.6 and 3.7), a  
DNS lookup MUST be performed to resolve the domain name [22]. The  
names are expected to be fully-qualified domain names (FQDNs):  
mechanisms for inferring FQDNs from partial names or local aliases are  
outside of this specification and, due to a history of problems, are  
generally discouraged. The lookup first attempts to locate an MX  
record associated with the name. If a CNAME record is found instead,  
the resulting name is processed as if it were the initial name."

The process this is describing is

	[1] I have mail for 'name'.
	[2] Do an MX lookup for 'name'
	[3] If I get a CNAME RR instead of an MX RR, repeat step [2] with the  
RDATA of the CNAME RDATA
	[4] Handle MXes that were found in step [3]
	
The key here is that you're asking for an MX RR, but the verbiage says  
"if a CNAME record is found __instead__". In other words, if you  
expected an MX RR but got a CNAME RR, then you need to chase down the  
CNAME and ask for *its* MX RR instead.

So again, I don't really even see how RFC2821/5 can be used to justify  
having CNAMEs in the MX RDATA.

Cheers,
D

--

Derek J. Balling
Manager of Systems Administration
Vassar College
124 Raymond Ave
Box 0406 - Computer Center 229
Poughkeepsie, NY 12604
W:	(845) 437-7231
C:	(845) 249-9731

--Apple-Mail-524-152558118
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 12, 2007, at 5:33 PM, Trevor Paquette wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><span style="font-size: 10pt; font-family: Arial, sans-serif; ">However, in talking to TrendMicro, they say that this syntax is perfectly valid and that RFC 2821 overrides the MX to CNAME limitation. The following website is their stance on this:<a href="http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&amp;id=EN-1035667" style="color: blue; text-decoration: underline; ">http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&amp;id=EN-1035667</a></span></div></div></div></span></blockquote><div><br class="webkit-block-placeholder"></div><div>I'll speak to how TrendMicro appears to be misinterpreting RFC2821. :-)</div><div><br class="webkit-block-placeholder"></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; ">"Domain names are used as names of hosts and of other entities in the domain&nbsp;name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail exchanger records to be used to deliver mail instead of representing a host name."&nbsp;</div></div><div><br class="webkit-block-placeholder"></div><div>This is defining "what a domain is". &nbsp;A "label", as defined in RFC1035, is (in simple terms) the left portion of a DNS record. If you're looking at a record like:</div><div><br class="webkit-block-placeholder"></div><div>foo IN MX 0 mailhost</div><div><br class="webkit-block-placeholder"></div><div>"foo" is the label, and that label is made up of a domain name. There are other places domain names might appear (such as in CNAME or MX RDATA), but I don't think anything in RFC2821/2.3.5 is saying that MXs can have hosts that resolve to CNAMEs in their RDATA.</div><div><br class="webkit-block-placeholder"></div><div>They further reference section 5, quoting:</div><div><br class="webkit-block-placeholder"></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; ">"Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name."</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; ">The process this is describing is&nbsp;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><span class="Apple-tab-span" style="white-space:pre">	</span>[1]&nbsp;I have mail for 'name'.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><span class="Apple-tab-span" style="white-space:pre">	</span>[2]&nbsp;Do an MX lookup for 'name'<br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><span class="Apple-tab-span" style="white-space:pre">	</span>[3] If I get a CNAME RR instead of an MX RR, repeat step [2] with the RDATA of the CNAME RDATA<br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><span class="Apple-tab-span" style="white-space:pre">	</span>[4] Handle MXes that were found in step [3]&nbsp;<br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><span class="Apple-tab-span" style="white-space:pre">	</span><br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; ">The key here is that you're asking for an MX RR, but the verbiage says "if a CNAME record is found __instead__". In other words, if you expected an MX RR but got a CNAME RR, then you need to chase down the CNAME and ask for *its* MX RR instead.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; "><br class="webkit-block-placeholder"></div></div></div><div>So again, I don't really even see how RFC2821/5 can be used to justify having CNAMEs in the MX RDATA.</div><div><br class="webkit-block-placeholder"></div><div>Cheers,</div><div>D</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div><br class="webkit-block-placeholder"></div><div>Derek J. Balling<br>Manager of Systems Administration<br>Vassar College<br>124 Raymond Ave<br>Box 0406 - Computer Center 229<br>Poughkeepsie, NY 12604<br>W:<span class="Apple-tab-span" style="white-space: pre; ">	</span>(845) 437-7231<br>C:<span class="Apple-tab-span" style="white-space: pre; ">	</span>(845) 249-9731</div><div><br class="webkit-block-placeholder"></div></div></span><br class="Apple-interchange-newline"></div></span></div></span><br class="Apple-interchange-newline"> </div><br></body></html>
--Apple-Mail-524-152558118--

--Apple-Mail-525-152558198
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-525-152558198--

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: MX to CNAME and (mis)interptretation of 2821
Date:  Thu, 13 Dec 2007 00:13:07 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 17
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Trevor Paquette wrote:

> Would it also be possible to state directly within the next
> revision of the RFC where or not this RFC overrides the 
> provision 10.3 of RFC 2181.

The Last Call for 2821bis ends 2007-12-24:

<http://tools.ietf.org/html/draft-klensin-2821bis> is 2821bis,
and <http://permalink.gmane.org/gmane.ietf.announce/22584> is
a copy of the running Last Call.

> I don't want to leave things left to misinterpretation.

I've seen at least one flamewar about this on another list. 

 Frank

Content-class: urn:content-classes:message
Subject: MX to CNAME and (mis)interptretation of 2821
Date: Wed, 12 Dec 2007 15:33:21 -0700
From: "Trevor Paquette" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83D0F.321C9844
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm currently at odds with a few folks regarding the interpretation of
RFC 2821 and the case of MX records that resolve to CNAMEs. I'm hoping
that those here, who are authoritative when it comes to this RFC, can
shed some light.

Take the following case:

% nslookup -q=mx fleetpride.com

Non-authoritative answer:

fleetpride.com  mail exchanger = 10 in.sjc.mx.trendmicro.com.

fleetpride.com  mail exchanger = 20 mx-in01.mail-abuse.org.

fleetpride.com  mail exchanger = 20 mx-in02.mail-abuse.org.

fleetpride.com  mail exchanger = 20 mx-in03.mail-abuse.org.

Authoritative answers can be found from:

fleetpride.com  nameserver = ns1-auth.sprintlink.net.

fleetpride.com  nameserver = ns2-auth.sprintlink.net.

fleetpride.com  nameserver = ns3-auth.sprintlink.net.

ns1-auth.sprintlink.net internet address = 206.228.179.10

ns2-auth.sprintlink.net internet address = 144.228.254.10

ns3-auth.sprintlink.net internet address = 144.228.255.10

% nslookup in.sjc.mx.trendmicro.com.

Non-authoritative answer:

in.sjc.mx.trendmicro.com        canonical name =
in.mx.trendmicro-fail-over.akadns.net.

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.15

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.16

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.1

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.2

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.3

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.4

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.13

Name:   in.mx.trendmicro-fail-over.akadns.net

Address: 216.99.131.14

According to RFC 2181, this is invalid. You cannot have an MX record
that resolves to a CNAME.

However, in talking to TrendMicro, they say that this syntax is
perfectly valid and that RFC 2821 overrides the MX to CNAME limitation.
The following website is their stance on this:
http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&i
d=EN-1035667

However, in talking to others, they say that TrendMicro is
misinterpreting the RFC. I'll admit after reading 2821, I could
interpret things both ways.

This is why I come to you folks who are responsible for this RFC. Who is
right? Is MX -> CNAME now allowed by 2821, or is TrendMicro in the
wrong?

Would it also be possible to state directly within the next revision of
the RFC where or not this RFC overrides the provision 10.3 of RFC 2181.
I don't want to leave things left to misinterpretation.

 

--

Trevor Paquette

Director, Information Technology and Systems

TeraGo Networks Inc.

300, 300 Manning Road NE

Calgary, Ab T2E 8K4

http://www.terago.ca <http://www.terago.ca/> 

W: (403) 668-5321

C: (403) 703-8738

 

------_=_NextPart_001_01C83D0F.321C9844
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns="http://www.w3.org/TR/REC-html40"
xmlns:ns0="urn:schemas-microsoft-com:office:smarttags">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Arial","sans-serif";
	color:windowtext;
	font-weight:normal;
	font-style:normal;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>I&#8217;m
currently at odds with a few folks regarding the interpretation of RFC 2821 and
the case of MX records that resolve to CNAMEs. I&#8217;m hoping that those
here, who are authoritative when it comes to this RFC, can shed some light.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Take
the following case:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>%
nslookup -q=mx fleetpride.com<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Non-authoritative
answer:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
mail exchanger = 10 in.sjc.mx.trendmicro.com.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
mail exchanger = 20 mx-in01.mail-abuse.org.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
mail exchanger = 20 mx-in02.mail-abuse.org.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
mail exchanger = 20 mx-in03.mail-abuse.org.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Authoritative
answers can be found from:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
nameserver = ns1-auth.sprintlink.net.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
nameserver = ns2-auth.sprintlink.net.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>fleetpride.com&nbsp;
nameserver = ns3-auth.sprintlink.net.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>ns1-auth.sprintlink.net
internet address = 206.228.179.10<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>ns2-auth.sprintlink.net
internet address = 144.228.254.10<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>ns3-auth.sprintlink.net
internet address = 144.228.255.10<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>%
nslookup in.sjc.mx.trendmicro.com.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Non-authoritative
answer:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>in.sjc.mx.trendmicro.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
canonical name = in.mx.trendmicro-fail-over.akadns.net.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.15<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.16<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.1<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.2<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.3<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.4<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.13<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Name:&nbsp;&nbsp;
in.mx.trendmicro-fail-over.akadns.net<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Address:
216.99.131.14<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>According
to </span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>RFC
2181, this is invalid. You cannot have an MX record that resolves to a CNAME.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>However,
in talking to TrendMicro, they say that this syntax is perfectly valid and that
RFC 2821 overrides the MX to CNAME limitation. The following website is their
stance on this: <a
href="http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&amp;id=EN-1035667">http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&amp;id=EN-1035667</a><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>However,
in talking to others, they say that TrendMicro is misinterpreting the RFC. I&#8217;ll
admit after reading 2821, I could interpret things both ways.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>This
is why I come to you folks who are responsible for this RFC. Who is right? Is
MX -&gt; CNAME now allowed by 2821, or is TrendMicro in the wrong?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Would
it also be possible to state directly within the next revision of the RFC where
or not this RFC overrides the provision 10.3 of RFC 2181. I don&#8217;t want to
leave things left to misinterpretation.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>--<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><ns0:PersonName><span
 style='color:navy'>Trevor Paquette</span></ns0:PersonName><span
style='color:navy'><o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Director, Information Technology and Systems</span><span
style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>TeraGo Networks Inc.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>300, </span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><ns0:Street><ns0:address><span
  style='color:navy'>300 Manning Road NE</span></ns0:address></ns0:Street><span
style='color:navy'><o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><ns0:City><ns0:place><span
  style='color:navy'>Calgary</span></ns0:place></ns0:City><span
style='color:navy'>, Ab T2E 8K4<o:p></o:p></span></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;color:navy'><a
href="http://www.terago.ca/"><span style='font-family:"Arial","sans-serif";
color:blue'>http://www.terago.ca</span></a></span><span style='font-size:10.0pt;
font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>W: (403) 668-5321<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>C: (403) 703-8738</span><span style='font-size:12.0pt;font-family:
"Times New Roman","serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;</span><o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C83D0F.321C9844--

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
To: David MacQuigg <[email-masked]>
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Date: Tue, 11 Dec 2007 12:09:35 -0800
Sender: [email-masked]

On Dec 11, 2007, at 10:12 AM, David MacQuigg wrote:

> At 12:34 AM 12/6/2007 -0800, Douglas Otis wrote:
>
>> For each direct source of spam, there are 4 sources of spam  
>> emerging from tens of millions of MTAs as DSNs.  The abuse of DSNs  
>> is seriously eroding email's integrity.
>
> "Bounce spam" is easy to block.  Just don't accept a DSN for any  
> message you didn't send.  This can be automated with an  
> authentication code in the return address on your outgoing mail.

This can only be done when the domain is able to impose a restriction  
on permitted MSAs.

>> Few MTAs can operate and accept message for all recipients.  The  
>> inability for MTAs to handle all possible traffic exposes valid  
>> recipients to being discovered.
>
> Hiding valid email addresses is a fundamentally insoluble problem.   
> If legitimate senders can find out when an address is invalid (which  
> they must if we are to preserve reliability), then spammers can do  
> the same.  Perhaps we can sacrifice some reliability for a little  
> more security, e.g. by sending "nosuch recipient" rejects only when  
> the sender is authenticated and reputable.  The rest can be  
> tempfailed until they give up.

This is solvable.  TBR can both limit discovery of valid email- 
addresses AND greatly improve delivery integrity.

>> Providers of domain names, IP addresses, or certificates have a  
>> conflict of interest, and are unable to prevent access to spammers.
>
> Unwilling, not unable.

Unwilling, and likely unwise.  There remains an inherent conflict of  
interest.  Using registration to limit access may also lead to forms  
of extortion.  What type of non-repudiation protects innocent  
domains?  Must all messages be signed by a CA?  What limits the number  
of certificates issued?  Should all certificates be aged 30 days  
before being accepted?

>> SMTP can not even mandate the use of an MX record to avoid  
>> searching for policy records.
>>
>> Reputation assessments of the last hop IP address is causing  
>> spammers to merge their traffic with other domains.  Often this  
>> merging is accomplished through compromised residential systems.   
>> The doubling rate is at six months, quickly making last hop  
>> reputation assessments less meaningful.
>
> I'm not seeing this at my receiver.  I don't understand how it could  
> work.  Please give more details on what you are seeing.  e.g. How  
> are you doing the last-hop authentication?

Messages can be submitted as legitimate users, but likely originate  
from compromised systems.  Correlating source patterns and overall  
volume determines the trend.

> Network owners can block IP ranges assigned to residential  
> customers, either a port 25 block, or a policy published in DNS  
> (e.g. the Spamhaus Policy Block List).  I guess this is another case  
> of unwilling, not unable.

Blocking port 25 is not a complete solution.  Compromised systems can  
bypass such blocks.  In the case of compromised systems, abuse is  
widely diffused such that rate limiting and outbound content filtering  
offers diminished relief.

>> While DKIM attempts to provide essential transport information, it  
>> is also prone to replay abuse and employs public key cryptography  
>> where sign-once / send-many gives transmitters a resource advantage.
>>
>> Grey-listing does not afford any long term strategy.  However, the  
>> use of temp errors can help avoid a complete denial of service as a  
>> triage strategy for limited receiver resources.  Reputation is then  
>> used to establish priority.  Processing undesired messages can  
>> exceed 99% at very high volumes.  This is not how the Internet  
>> should work.  A basic change to SMTP is needed to shift the burden  
>> toward the transmitter.
>
> I agree completely, except that I would not call simple extensions  
> "basic changes".  The only thing I would change about SMTP, if I  
> could turn back the clock, would be to make the HELO name a  
> declaration of Identity, not a meaningless machine name.

Agreed, but then this also runs into conflicts of interest.  An email- 
provider often does not want credit.  TBR demands an identity, a  
matching MailFrom, and an MX record.  In addition, TBR better  
identifies a problem source, and not just the last MTA "holding the  
bag" so to speak.

>> Greylisting increases the number of transactions per message, so  
>> ultimately, this is headed in the wrong direction.
>
> I think there is too much worry about these "extra transactions".   
> With a properly designed receiver, the number of transactions added  
> for greylisted or challenged messages should be very small compared  
> to the rest of the mailflow.  Tempfails or challenges should go only  
> to the small percentage that is neither whitelisted nor clearly spam.

When spam must comply with grey-listing, transactions will  
dramatically increase.  The vast majority of email is spam where a  
growing percentage can not be detected based upon content.

>> The TBR reference exchange can be done within a single transaction.  
>> The transmitter is required to hold messages until the receiver is  
>> ready.  With a high level of source granularity, message  
>> origination reputation should be able match the transmitter's level  
>> of abuse and not breed super spam.  References can be retained for  
>> a period of time, where abuse pattern can be detected and used to  
>> silently expunge abusive sources.
>
> I like this proposal.  Yet another tool for our arsenal.  The weak  
> link is getting senders to implement it.  If we expect senders to do  
> anything at all, it must be zero-cost and zero-risk.

The advantage afforded is prompt delivery.  The alternative is Temp  
fail, and then a subsequent retry.  TBR avoids head of line blocking  
that Temp fail will cause, and reduces recipient resources needed to  
absorb all traffic, desired or not.

After discussing the TBR proposal in Vancouver, it appears several  
changes are needed.  These changes are aimed at supporting a queuing  
architecture, instead of immediately supplanting a queue structure  
with XAM.  The requested changes are possible, although requires a  
somewhat different command structure.

-Doug

Date: Tue, 11 Dec 2007 14:04:58 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics
Sender: [email-masked]

John C Klensin wrote:

>But one of the implied goals for 2821bis has been making the
>spec easier to read and understand without a comprehensive
>understanding of how it is organized.  So, with the
>understanding that this is a question and not a recommendation
>(since I do not have an opinion), would it be useful to insert
>text in the command descriptions for the commands that have only
>a single positive reply (EHLO/HELO, DATA, RSET, NOOP, and QUIT)
>that explicitly identifies the code that is expected for a
>normal/successful reply?
>
I think this would help implementors.

>Or would that be just clutter that
>makes the document longer to no good end?
>  
>

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Sun, 09 Dec 2007 14:40:36 -0000
Subject: Re: New Issue: NOOP clarification
Content-description: Mail message body
Sender: [email-masked]

Argh!  Stop this madness!

RFC 2821 introduced an incompatibility with NOOP.  I'd've gone right ahead 
and implemented the optional argument without a second thought, with no 
intention for my client to ever use NOOP (or, indeed, RSET - even when 
caching connections, there simply isn't a need because you just have to 
try the next transaction to find out if link is dead).  I didn't notice 
the optional argument when reading both 821 and 2821, though, and nor did 
anyone else using liberal and/or modern implementations of SMTP which 
rigorously follow spec.  Even if the server falls over, it's a rare case 
indeed that it should result in session termination, and there's still a 
chance your logging intentions are satisfied even when you get non-250 
responses to NOOP when using arguments (not that I think they're actually 
*justified*, nor that, indeed, there are many real uses for NOOP in 
"Normal" operation).  But this has been as good as law for the past - hang 
on a sec - six years, so that it's kind of hard to justify changing things 
again.  Lastly, there are still uses for HELO even when a client is an 
otherwise fully-capable ESMTP implementation - it mightn't want any 
extensions, so it naturally won't bother to ask for them (I know, it's 
unlikely but it's possible and the spec provides for it).  Given that the 
whole HELO fallback thing is a hack that relies on servers actually 
working as intended by RFC 821 when the first command is EHLO and when 
EHLO isn't supported (they don't and to this day sendmail is still using 
the ESMTP keyword in the banner as indicator by default), I don't think we 
should condition any aspect of the protocol on whether or not we were an 
old or new client introducing ourselves - we merely do whatever is asked 
of us with extended commands.

So, in summary: if we do want to add any kind of note, it should do 
nothing more than state the change.  Like this:

Note that [RFC821] does not provide for arguments to the NOOP command.  If 
a client implementation sends arguments with NOOP commands when in a 
session to a server that conforms to [RFC821], it MUST expect responses 
with codes other than 250, but is otherwise free to conclude that the 
command has completed unless the session is terminated with the "421 
<domain> Service not available, closing transmission channel" response as 
described in section x.x.

(x.x being the number of a section somewhere - not got the draft to hand 
just now - that describes this global response.)

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Thu, 6 Dec 2007 21:17:46 +0100
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Greylisting pitfalls
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-11-18 18:34:27 +0100, Peter J. Holzer wrote:
> On 2007-11-18 11:28:25 -0500, David F. Skoll wrote:
> > Peter J. Holzer wrote:
> > > Just out of curiosity: Which version of Lotus was this?
> > 
> > This behavior was pointed out to me by a customer who
> > uses Lotus.  This is in his e-mail header:
> > 
> > X-MIMETrack: Serialize by Router on xxxx(Release
> >         7.0.2FP2|May 14, 2007)... rest deleted
> 
> Interesting. That's exactly the version we use. Of course we wouldn't
> notice this in production (the Domino servers don't deliver directly and
> the smarthost doesn't greylist them, of course) but the issue should
> have come up during pre-production tests.

Our Domino admin and I did some experiments today. As far as we can
tell, Domino handles greylisting fine, but we didn't test very
thoroughly.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--kfjH4zxOES6UT95V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--kfjH4zxOES6UT95V--

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: New incompatible Tricks promotes change
Date: Thu, 6 Dec 2007 10:50:45 -0800
Sender: [email-masked]

On Dec 6, 2007, at 2:06 AM, Hector Santos wrote:

> Change promotes chaos which strives for equilibrium which instigates  
> a new round of survival of the fittest, deviation and imperfection,  
> thus the cycle begins again.
>
> Trick XYZ requires change like any other trick. If change is what we  
> want, IMO your particular trick no longer applies - there are by far  
> more simpler solutions.
>
> SMTP v3.0 needs registration and enforcement ideas.  Thats all - two  
> fundamental ideas that we are very careful not to revisit again.

Hector,

Even when everything is authenticated, some type of temporal, opaque  
identifier is needed to deal with repeatedly abusive sources.   
Registration serves as a means to rate-limit abuser access, but that  
is not a complete solution.

TBR allows offering "questionable" transmitters a choice -

1) Receive a temp error, or

2) Provide a nonspoofable, content immutable, and opaque source  
reference

The TBR reference does not require receivers to expend resources  
associated with obtaining keys, cryptographic analysis, obtaining  
extensive address list of all hosts used on behalf of a domain, or  
investigating all permissions at every hop.  Bot nets are making  
receiver resource intensive analysis impractical, to say the least.

Expect registration and enforcement to be the role of different  
parties.  Don't expect email providers to proactively play the role of  
enforcer.  They naturally have conflicted interests with a desire is  
to attract as many users as possible.  A large number of users in  
itself, allows, and may invite, lax enforcement.  Those offering  
access to services often operate at thin margins where customer  
support represents a substantial component of their overhead.  Dealing  
with a compromised system often requires hours of labor and a high  
level of interaction.

There are lucrative business models for either party, however SMTP  
currently and significantly lacks a means for fine grain enforcement.  
The interests of those offering registration are significantly  
different from those attempting to keep lines of communication clear.   
Those offering email services and those blocking abuse should not be  
seen as being adversaries.  The latter is more prone to DDoS attack  
where it is very much in their interest to keep the number of  
compromised systems in check.  As such, they offer notification with a  
place to go for resolution, many such companies even offer free  
remdiation.

TBR is not a trick defeated by changing a message's format.  TBR can  
not be defeated by lying about some header within the message.  TBR  
does not depend upon _anything_ that would give the transmitter an  
advantage over that of the receiver.  In that sense, TBR can remain a  
long term solution unlike most other efforts or proposed solutions.   
By not having any identifier with a granularity smaller than the  
domain or the client's IP address, too often those providing  
enforcement have created problems for the providers.  This tends to  
put them at odds.  Levels of abuse can be expected to rise unless  
finer grain enforcement becomes possible.  After all, we all want to  
get along.  Sounding a bit like Jerry McGuire, help us to help you.

TBR offers a fine grain, opaque, identifier at an extremely low  
resource cost from the perspective of the receiver.  TBR is NOT about  
conserving the Internet.  TBR is about providing an effective and  
scalable mean of enforcement which acknowledges the different roles of  
transmitter and receiver, or email and anti-abuse provider.  TBR is  
not a clever trick.  It is dead simple and can be very effective.

-Doug

Date: Thu, 6 Dec 2007 15:17:18 +0000
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> How would you describe what they do do?

Sendmail and (recent versions of) Postfix never add a Sender: field to the
header. Exim (by default) adds a Sender: field corresponding to the
authenticated sender if this is different from the From: field, which is
what 822 and 2822 and 4409 suggest. Traditional Unix MUAs don't bother
showing the Sender: field, but Microsoft Outlook is quite keen on it.
Therefore in our environment messages from role addresses tend to show up
in Outlook as "from person on behalf of role" which is annoying. I'm
inclined to give up on adding Sender: fields as specified and instead use
non-standard annotations in the Received: fields to record the
authenticated sender (as in this message).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY SOLE LUNDY FASTNET: WESTERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER IN SOLE, LUNDY AND FASTNET. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN
THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Thu, 06 Dec 2007 08:58:21 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "David F. Skoll" <[email-masked]>
CC: [email-masked]
Subject: Re: 2822 To: header (was Re: [ietf-dkim] Mailing lists as 2822-Sender)
Sender: [email-masked]

David F. Skoll wrote:
> Hector Santos wrote:
> 
> [David Skoll]
>>>> Otherwise, you risk exposing Bcc: addresses.
> 
> [Ned Freed]
>>> Exactly.
> 
> [Hector Santos]
>> I don't see it Ned, and reviewing this is putting a hurting on my brain.

In direct offline response to your BCC concern, but you moved back here 
and failed to show an important pieces of the response, what I said 
off-list can be summarized as follows:

A) The MUA is responsible for pulling the BCC, so there is no risk of 
exposure.

B) In the rare scenario where there the MUA creating a Multiple To:, and 
a Bcc message, and there is no headers sent, there is no risk because 
there were be 2 or more separate messages created by the post mail 
processor, not MSA or MDA, one for each and each one assigned a TO: with 
its corresponding recipient address.  So there is absolute no risk of 
exposure.

As to why it may done, I also said:

C) A primary reason, as Ned pointed out too, is to offer strict 822 
compatibility.

D) The presentation layer is important here. Customers will REAM you
if you don't tell in the the To: field in presentation devices.

E) It might be assigned something else like "To: All" depending if the 
message is going to some special local conference forum or even gated 
newsgroup.

F) There are still applications, like prints, instant message, cell 
phone text mail, even fax jobs where local mail bots are used.

All was in direct response to the concern you had with BCC.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 06 Dec 2007 08:00:36 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "David F. Skoll" <[email-masked]>
CC: [email-masked]
Subject: Re: 2822 To: header (was Re: [ietf-dkim] Mailing lists as 2822-Sender)
Sender: [email-masked]

David,

If you are going to move an off-list private conversation into public 
using selective quoting in an attempt to show some point that appears to 
goes against anything I said in the off-list conversation, then it is 
only fair that you QUOTE more extensive relevant information I provided.

Not cool.

You suggested there is a RISK of exposing BCC: addresses and I explained 
in quite extensive detail why that is not case.

Do you care to quote any of that?  Or should I?

I am not going to waste any more time on this.

-- 
Hector Santos, CTO
http://www.santronics.com

David F. Skoll wrote:
> Hector Santos wrote:
> 
> [David Skoll]
>>>> Otherwise, you risk exposing Bcc: addresses.
> 
> [Ned Freed]
>>> Exactly.
> 
> [Hector Santos]
>> I don't see it Ned, and reviewing this is putting a hurting on my brain.
> 
> The canonical example I always like to give is:
> 
> MAIL FROM:<[email-masked]>
> RCPT TO:<[email-masked]>
> 
> If the RCPT address is a mailing list, you may not wish to expose that
> fact in the To: header.  The SMTP server does not have enough information
> about the sensitivity of the RCPT argument to know whether or not it's
> safe to put it in a header.
> 
>> But I hope it wasn't misunderstood that we are not talking about a MSA
>> or MDA doing this. But a post acceptance mail processor, importer, etc,
>> responsible for storage the direct mail.
> 
> See above.  The SMTP RCPT argument can be sensitive.  And if you mean
> adding a To: header after alias expansion, etc. then you are no longer
> talking about the x821 RCPT argument.
> 
> Regards,
> 
> David.
> 
> 
> 

Date: Thu, 06 Dec 2007 07:19:01 -0500
From: "David F. Skoll" <[email-masked]>
To: [email-masked]
Subject: Re: 2822 To: header (was Re: [ietf-dkim] Mailing lists as 2822-Sender)
Sender: [email-masked]

Hector Santos wrote:

[David Skoll]
>>> Otherwise, you risk exposing Bcc: addresses.

[Ned Freed]
>> Exactly.

[Hector Santos]
> I don't see it Ned, and reviewing this is putting a hurting on my brain.

The canonical example I always like to give is:

MAIL FROM:<[email-masked]>
RCPT TO:<[email-masked]>

If the RCPT address is a mailing list, you may not wish to expose that
fact in the To: header.  The SMTP server does not have enough information
about the sensitivity of the RCPT argument to know whether or not it's
safe to put it in a header.

> But I hope it wasn't misunderstood that we are not talking about a MSA
> or MDA doing this. But a post acceptance mail processor, importer, etc,
> responsible for storage the direct mail.

See above.  The SMTP RCPT argument can be sensitive.  And if you mean
adding a To: header after alias expansion, etc. then you are no longer
talking about the x821 RCPT argument.

Regards,

David.

Date: Thu, 06 Dec 2007 05:06:37 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Douglas Otis <[email-masked]>
CC: [email-masked]
Subject: New incompatible Tricks promotes change
Sender: [email-masked]

Doug,

Change promotes chaos which strives for equilibrium which instigates a 
new round of survival of the fittest, deviation and imperfection, thus 
the cycle begins again.

Trick XYZ requires change like any other trick. If change is what we 
want, IMO your particular trick no longer applies - there are by far 
more simpler solutions.

SMTP v3.0 needs registration and enforcement ideas.  Thats all - two 
fundamental ideas that we are very careful not to revisit again.

What we have today is akin to a filtration by osmosis process.  If you 
don't fit a certain size or shape, you are filtered.  In an organic 
world, those filtered can adapt to the attributes required.

The typical problem is that the osmosis filters get clogged up which can 
increase pressures and slowing down the flow rates.

One typical solution is to use special desirable chemical/DNA markings 
that can be detected thus allowing for an infinity, chemical or 
electro-magnetism based separation.

This allows for multiple streams of osmosis filters: One group for 
special DNS markings and another group for the rest.

Of course, in a living organic world, adaptation with the DNA markings 
are possible, so now we institute a control process for the the feed 
containing DNA markings.

To help accelerate the process, only special DNA markings will be used 
which are compatible with our special, trade secret, catalyst injections 
  which the DNA has an affinity changing their DNA state to one of 
higher quality offering even better filtration by osmosis.

I knew I can apply my old chemical engineering training for something :-)

-- 
Hector Santos, CTO
http://www.santronics.com

Douglas Otis wrote:
> 
> 
> On Dec 5, 2007, at 6:51 PM, John C Klensin wrote:
> 
>> This type of reasoning is exactly the reason why some of us are 
>> skeptical about greylisting and any other technique that works well 
>> only if it is used by sufficiently few people.   If it starts being 
>> used enough, the spammers have the incentive to figure out how to 
>> simulate the behavior that gets past the traps and then, sooner or 
>> later, it isn't worth bothering with.  The skepticism leads some of us 
>> to wander away from conversations about how wonderfully effective the 
>> technique while muttering "arms race".   Others wander off in a 
>> slightly different directions muttering "making the bad guys smarter 
>> is really not a good strategy"
>>
>> At least the first of those sources of muttering noises does not 
>> suggest that you shouldn't use a method that works for you as long as 
>> it does work for you (others might disagree about that). It does mean, 
>> I think, that you should be somewhat careful about praising the method 
>> to others or assuming that it will last forever.  And then there is 
>> the part I worry about most, which is that we will make basic changes 
>> to the email protocols in order to make things work better, for a 
>> short time, for these relatively short-life-expectancy techniques.
> 
> SMTP's inability to reliably identify where a message originated has 
> caused inordinate reliance on content filtering.  While at first, 
> content filtering had been fairly effective, this in turn has caused 
> spammers to improve their obfuscation techniques at a rate that has 
> become impractical for receivers to match with resources.
> 
> For each direct source of spam, there are 4 sources of spam emerging 
> from tens of millions of MTAs as DSNs.  The abuse of DSNs is seriously 
> eroding email's integrity.
> 
> Few MTAs can operate and accept message for all recipients.  The 
> inability for MTAs to handle all possible traffic exposes valid 
> recipients to being discovered.
> 
> Providers of domain names, IP addresses, or certificates have a conflict 
> of interest, and are unable to prevent access to spammers.
> 
> SMTP can not even mandate the use of an MX record to avoid searching for 
> policy records.
> 
> Reputation assessments of the last hop IP address is causing spammers to 
> merge their traffic with other domains.  Often this merging is 
> accomplished through compromised residential systems.  The doubling rate 
> is at six months, quickly making last hop reputation assessments less 
> meaningful.
> 
> While DKIM attempts to provide essential transport information, it is 
> also prone to replay abuse and employs public key cryptography where 
> sign-once / send-many gives transmitters a resource advantage.
> 
> Grey-listing does not afford any long term strategy.  However, the use 
> of temp errors can help avoid a complete denial of service as a triage 
> strategy for limited receiver resources.  Reputation is then used to 
> establish priority.  Processing undesired messages can exceed 99% at 
> very high volumes.  This is not how the Internet should work.  A basic 
> change to SMTP is needed to shift the burden toward the transmitter.  
> Greylisting increases the number of transactions per message, so 
> ultimately, this is headed in the wrong direction.
> 
> The TBR reference exchange can be done within a single transaction.  The 
> transmitter is required to hold messages until the receiver is ready.  
> With a high level of source granularity, message origination reputation 
> should be able match the transmitter's level of abuse and not breed 
> super spam.  References can be retained for a period of time, where 
> abuse pattern can be detected and used to silently expunge abusive sources.
> 
> -Doug

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Date: Thu, 6 Dec 2007 00:34:49 -0800
Sender: [email-masked]

On Dec 5, 2007, at 6:51 PM, John C Klensin wrote:

> This type of reasoning is exactly the reason why some of us are  
> skeptical about greylisting and any other technique that works well  
> only if it is used by sufficiently few people.   If it starts being  
> used enough, the spammers have the incentive to figure out how to  
> simulate the behavior that gets past the traps and then, sooner or  
> later, it isn't worth bothering with.  The skepticism leads some of  
> us to wander away from conversations about how wonderfully effective  
> the technique while muttering "arms race".   Others wander off in a  
> slightly different directions muttering "making the bad guys smarter  
> is really not a good strategy"
>
> At least the first of those sources of muttering noises does not  
> suggest that you shouldn't use a method that works for you as long  
> as it does work for you (others might disagree about that). It does  
> mean, I think, that you should be somewhat careful about praising  
> the method to others or assuming that it will last forever.  And  
> then there is the part I worry about most, which is that we will  
> make basic changes to the email protocols in order to make things  
> work better, for a short time, for these relatively short-life- 
> expectancy techniques.

SMTP's inability to reliably identify where a message originated has  
caused inordinate reliance on content filtering.  While at first,  
content filtering had been fairly effective, this in turn has caused  
spammers to improve their obfuscation techniques at a rate that has  
become impractical for receivers to match with resources.

For each direct source of spam, there are 4 sources of spam emerging  
from tens of millions of MTAs as DSNs.  The abuse of DSNs is seriously  
eroding email's integrity.

Few MTAs can operate and accept message for all recipients.  The  
inability for MTAs to handle all possible traffic exposes valid  
recipients to being discovered.

Providers of domain names, IP addresses, or certificates have a  
conflict of interest, and are unable to prevent access to spammers.

SMTP can not even mandate the use of an MX record to avoid searching  
for policy records.

Reputation assessments of the last hop IP address is causing spammers  
to merge their traffic with other domains.  Often this merging is  
accomplished through compromised residential systems.  The doubling  
rate is at six months, quickly making last hop reputation assessments  
less meaningful.

While DKIM attempts to provide essential transport information, it is  
also prone to replay abuse and employs public key cryptography where  
sign-once / send-many gives transmitters a resource advantage.

Grey-listing does not afford any long term strategy.  However, the use  
of temp errors can help avoid a complete denial of service as a triage  
strategy for limited receiver resources.  Reputation is then used to  
establish priority.  Processing undesired messages can exceed 99% at  
very high volumes.  This is not how the Internet should work.  A basic  
change to SMTP is needed to shift the burden toward the transmitter.   
Greylisting increases the number of transactions per message, so  
ultimately, this is headed in the wrong direction.

The TBR reference exchange can be done within a single transaction.   
The transmitter is required to hold messages until the receiver is  
ready.  With a high level of source granularity, message origination  
reputation should be able match the transmitter's level of abuse and  
not breed super spam.  References can be retained for a period of  
time, where abuse pattern can be detected and used to silently expunge  
abusive sources.

-Doug

Content-class: urn:content-classes:message
Subject: RE: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Date: Wed, 5 Dec 2007 20:33:39 -0800
From: "Alex Bobotek" <[email-masked]>
To: "Sabahattin Gucukoglu" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Making a sufficent set of honeypots minimally distinguishable from valid
addresses 
should be a consideration in spam defense.  A very large number of mine
have the 
same SMTP acceptance policies and latencies as valid accounts.  

As for the other honeypots (undefended by RBLs, etc.), they'll go when
they stop
being useful.  Benign diversity is a great thing.  Incompatibility (a la
graylisting)
doesn't meet the "benign" criterion.

Regards,

Alex Bobotek
alex bobotek.net

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sabahattin 
> Gucukoglu
> Sent: Wednesday, December 05, 2007 9:30 AM
> To: [email-masked]
> Subject: Everyone Greylists Except Honeypots ... So Let's Not 
> Spam Honeypots!
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Does this notion bother anyone, in particular?
> 
> The argument for greylisting is apparently no longer - and if 
> it is, it can't be for *much* longer - that, "So what if we 
> can't detect non-MTSs anymore?  We can still trap the bad 
> ones by letting our favourite non- greylisting BL spamtraps 
> capture them!"
> 
> So all Mr. Bad Guy needs to do now is realise the significant 
> uptake of greylisting for this one purpose, and never spam 
> any host that seems to accept all initial transactions.  They 
> can do this simply by not entering the DATA state.  And if 
> that's used as metric, by sharing data amongst themselves as 
> to the exact purpose of non-greylisting hosts.
> 
> Any thoughts?
> 
> Cheers,
> Sabahattin
> 
> - --
> Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
> Address harvesters, snag this: [email-masked]
> Phone: +44 20 88008915
> Mobile: +44 7986 053399
> http://sabahattin-gucukoglu.com/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8
> Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
> 
> iQA/AwUBR1bgNSNEOmEWtR2TEQJeGACfRn3DRGVvi0C1+ucvPJpW44J6wq8AoLbo
> qLQCroHslVRBW0AZk6MFyDAh
> =KFk2
> -----END PGP SIGNATURE-----
> 
> 

Date: Wed, 05 Dec 2007 21:51:03 -0500
From: John C Klensin <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>
cc: [email-masked]
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Sender: [email-masked]

--On Wednesday, 05 December, 2007 19:17 +0000 Sabahattin
Gucukoglu <[email-masked]> wrote:

> This isn't a proposal, I'm just thinking like a spammer for a
> moment  (urgh).  I don't think you've understood what I'm
> saying up until now,  though.  This is just a terrible thought
> - that the lasting argument for  greylisting's continued
> existence is kind of dead if it becomes so  absolutely
> prevalent that spammers go back to square one, that of
> stepping  very carefully so as to avoid trapping themselves.
> Knowing who the  spamtraps are won't require any special skill
> or cooperation if legitimate  receivers rely on BLs actually
> catching spamtrap mail, because (of course)  the MTS can now
> be easily tricked into revealing the purpose of the  spamtrap
> address - that is, since it now accepts every kind of mail
> from  anywhere, it *must* be intended as bate.
>...

This type of reasoning is exactly the reason why some of us are
skeptical about greylisting and any other technique that works
well only if it is used by sufficiently few people.   If it
starts being used enough, the spammers have the incentive to
figure out how to simulate the behavior that gets past the traps
and then, sooner or later, it isn't worth bothering with.  The
skepticism leads some of us to wander away from conversations
about how wonderfully effective the technique while muttering
"arms race".   Others wander off in a slightly different
directions muttering "making the bad guys smarter is really not
a good strategy"

At least the first of those sources of muttering noises does not
suggest that you shouldn't use a method that works for you as
long as it does work for you (others might disagree about that).
It does mean, I think, that you should be somewhat careful about
praising the method to others or assuming that it will last
forever.  And then there is the part I worry about most, which
is that we will make basic changes to the email protocols in
order to make things work better, for a short time, for these
relatively short-life-expectancy techniques.

    john

Date: Wed, 05 Dec 2007 16:56:36 -0500
From: "David F. Skoll" <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: 2822 To: header (was Re: [ietf-dkim] Mailing lists as 2822-Sender)
Sender: [email-masked]

Hector Santos wrote:

> in the same vain many SMTP receivers will fill in the missing 822
> required fields.

>    FROM:  <<-- x821.MailFrom
>    To:    <<-- x821.RcptTo

The latter should never be done.  If there's a missing To: header,
an SMTP receiver should synthesize:

     To: undisclosed-recipients;

Otherwise, you risk exposing Bcc: addresses.

(I suppose it's safe for the MDA to add a To: header upon final delivery
to one and only one recipient.)

Regards,

David.

Date: Wed, 05 Dec 2007 16:29:31 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Dave Crocker <[email-masked]>
CC: Tony Finch <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Dave Crocker wrote:
> 
> 
> Tony Finch wrote:
>>>      "The "Sender:" field specifies the
>>>    mailbox of the agent responsible for the actual transmission of the
>>>    message."
>>
>> Popular MTA implementations (Sendmail, Postfix) do not implement the
>> Sender: header the way 822 and 2822 suggest,
> 
> How would you describe what they do do?

Well, if SendMail/PostFix is operating like the rest of the world... If 
missing, a SMTP receiver MIGHT do:

    Sender: <-- x821.MailFrom

in the same vain many SMTP receivers will fill in the missing 822 
required fields.

    FROM:  <<-- x821.MailFrom
    To:    <<-- x821.RcptTo

and they MUST do this if they want to SUPPORT the presentation layers.

But sender is not a given because it is not a 822 required field. In 
fact, I seem to recall, it was only in recent years that we even 
bothered with Sender in our mailers.

Only a few sites will reject such empty headers in the DATA block. Off 
hand, I know of one, HOTMAIL.COM and they only started to reject mail 
without the headers when SENDER-ID support was added to HOTMAIL.COM.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Wed, 05 Dec 2007 16:14:38 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Steve Dorner <[email-masked]>
CC: [email-masked], Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Ha! Yammer-To-Author! Hilarious!

Thanks for making my day. :-)

-- 
Hector Santos, CTO
http://www.santronics.com

Steve Dorner wrote:
> 
> At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
>> Frankly I think [Resent-] should be deprecated, because it causes so 
>> much trouble.
> 
> Along with From, Sender, and Reply-To.  :-)
> 
> I see no straightening out of the tangle we are in regarding all these 
> fields.  We keep trying to tweak the rules, tweak compliance, etc, so 
> that we get a system where everybody can conveniently do what they want, 
> and I don't think it's possible.
> 
> Frankly, I think we either just give it up and live with it, or define 
> entirely new fields with narrow, specific meanings that enable agents to 
> put together the operations we like.
> 
> Eg, deprecate (softly and over time) Sender, and replace with:
> 
> Original-Injector:
> List-Injector:
> Translated-Injector:
> Fuelled-Injector:
> ...
> 
> Deprecate Reply-To:, and replace with:
> 
> Yammer-To-Author:
> Yammer-To-List:
> Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
> ...
> 
> We have to get very specific about labelling who did what to whom if we 
> hope to have a situation that is satisfying to our sense of the right 
> progression of the universe.
> 
> Some of these fields probably would need to be multiple, and even 
> order-maintained.  They might need syntax above and beyond what is 
> currently allowed for recipient fields.  There would probably be a fair 
> number of them.
> 
> But there's so much useless junk flying around in email now, several 
> dozen more addressing fields would hardly be noticed.  :-)
> 
> My guess is that "living with it" is going to win.
> 
> 
> 

Date: Wed, 05 Dec 2007 13:14:24 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Tony Finch wrote:
>>      "The "Sender:" field specifies the
>>    mailbox of the agent responsible for the actual transmission of the
>>    message."
> 
> Popular MTA implementations (Sendmail, Postfix) do not implement the
> Sender: header the way 822 and 2822 suggest,

How would you describe what they do do?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 05 Dec 2007 16:05:25 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: FYI: Email Standards Compliance Project
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Actually it's not all that bad.
> 
> If you accept as a premise that email messages are put together by 
> "designers" using HTML and CSS for rendering on the screens of "readers" 
> (both words from email-standards.org), then I don't think you can 
> improve very much on what the email-standards.org people are doing. 

But isn't i such a minor part of the total ergonomics. Don't you think?

> They don't seem to care much about being able to quote in 
 > a reply, and so on, and so forth, so there's certainly scope for
 > improvement, but most  HTML/mail proposals I've seen are much
 > worse than theirs.

Right.  I only too a quick look, and its acid test was pretty much about 
'style' - one group's (probably 1 person) opinion - and we know everyone 
has one. :-)   So if they believe AOL looks "Prettier" that doesn't make 
it the email standard and god no, I really hope everyone don't looks and 
feel the same way - how boring would that be? :-)

> I could only think of one easy security attack that their test affords. 
> (Lazy implementers may allow more attacks, but isn't that always the case?)

AJAX and mail previewers seems to be gaining.  I was blown away by my 
customers almost near riot in getting it added to our web mail system. 
Now I really do like it myself.

Here's a public access view:
      http://winserver.com/public/code/html-recentmail.wcx?uf=0&mp=1&age`

What we found out was how much really helps in the low bandwidth 
customer situations such as Chucke Cheese Restaurants whose 450+ odd 
stores all have low bandwidth 64kb connections to HQ support with our 
mail system.

Anyway, there are so many other considerations for an "MUA Email 
Standard" outside the x822 area.  Of course it is all subjective.

Long live the MUA battles!

-- 
Hector Santos, CTO
http://www.santronics.com

Date: Wed, 05 Dec 2007 15:45:21 -0500
From: "David F. Skoll" <[email-masked]>
To: [email-masked]
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Sender: [email-masked]

Sabahattin Gucukoglu wrote:

> Not now.  The subject line is the idea some spammer has when Greylisting 
> is implemented across the board and it's clear they have to target 
> greylisted hosts.

First of all, it's not clear to me that more than a few percent of SMTP
servers will ever implement greylisting, so I don't think that's much
of a danger.

Secondly, the whole point behind honeypots is that they should appear to
be "real", so if greylisting *does* become widespread, honeypots will
simply implement greylisting too.

Regards,

David.

Date: Wed, 5 Dec 2007 11:55:28 -0800
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
>Frankly I think [Resent-] should be deprecated, because it causes so 
>much trouble.

Along with From, Sender, and Reply-To.  :-)

I see no straightening out of the tangle we are in regarding all 
these fields.  We keep trying to tweak the rules, tweak compliance, 
etc, so that we get a system where everybody can conveniently do what 
they want, and I don't think it's possible.

Frankly, I think we either just give it up and live with it, or 
define entirely new fields with narrow, specific meanings that enable 
agents to put together the operations we like.

Eg, deprecate (softly and over time) Sender, and replace with:

Original-Injector:
List-Injector:
Translated-Injector:
Fuelled-Injector:
...

Deprecate Reply-To:, and replace with:

Yammer-To-Author:
Yammer-To-List:
Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
...

We have to get very specific about labelling who did what to whom if 
we hope to have a situation that is satisfying to our sense of the 
right progression of the universe.

Some of these fields probably would need to be multiple, and even 
order-maintained.  They might need syntax above and beyond what is 
currently allowed for recipient fields.  There would probably be a 
fair number of them.

But there's so much useless junk flying around in email now, several 
dozen more addressing fields would hardly be noticed.  :-)

My guess is that "living with it" is going to win.

Date: Wed, 5 Dec 2007 19:53:20 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> Well, let's get back to first princples.  RFC 2822 3.6.2:
>
>      "The "Sender:" field specifies the
>    mailbox of the agent responsible for the actual transmission of the
>    message."

Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest, so even before you consider
mailing list managers you need to be very careful about RFC lawyering.

Microsoft MUAs present message headers in a way that works best if normal
messages do not have a Sender: field and mailing list messages do have one.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. HIGH OR VERY HIGH IN FASTNET AND SHANNON, ROUGH OR VERY ROUGH IN
LUNDY AND IRISH SEA. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY
POOR.

Date: Wed, 5 Dec 2007 20:45:44 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: FYI: Email Standards Compliance Project
Sender: [email-masked]

Carl S. Gutekunst answers me and ultimately Dave Crocker:
>>>    <http://www.email-standards.org/>
>>>
>>> which seeks to rate MUAs and webmail sites for standards compliance.
>>
>> Not quite. It rates them for HTML display standards compliance. If a 
>> mail reader has perfect HTML, CSS and javascript support, it gets 
>> full points from that site.
> ... and probably fails any reasonable security/privacy test.

Actually it's not all that bad.

If you accept as a premise that email messages are put together by 
"designers" using HTML and CSS for rendering on the screens of 
"readers" (both words from email-standards.org), then I don't think you 
can improve very much on what the email-standards.org people are doing. 
They don't seem to care much about being able to quote in a reply, and 
so on, and so forth, so there's certainly scope for improvement, but 
most HTML/mail proposals I've seen are much worse than theirs.

I could only think of one easy security attack that their test affords. 
(Lazy implementers may allow more attacks, but isn't that always the 
case?)

Arnt

Date: Wed, 5 Dec 2007 19:44:12 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Pete Resnick <[email-masked]>, John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

On Tue, 4 Dec 2007, [email-masked] wrote:
>
> I don't recall anyone considering using Resent- fields for this until
> just now, but I could easily have missed it

I think it's a cute idea, but Resent- fields are an interop nightmare
because the 822 specification is too weak to work in general (e.g. a
sequence of multiple resendings) and the 2822 specification is not
entirely compatible and not widely implemented.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN SOUTH.
ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

From: "Sabahattin Gucukoglu" <[email-masked]>
To: John C Klensin <[email-masked]>
Date: Wed, 05 Dec 2007 19:17:29 -0000
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi John,

On 5 Dec 2007 at 13:08, John C Klensin <[email-masked]> said:

> --On Wednesday, 05 December, 2007 17:30 +0000 Sabahattin
> Gucukoglu <[email-masked]> wrote:
> 
> > Does this notion bother anyone, in particular?
> > 
> > The argument for greylisting is apparently no longer - and if
> > it is, it  can't be for *much* longer - that, "So what if we
> > can't detect non-MTSs  anymore?  We can still trap the bad
> > ones by letting our favourite non- greylisting BL spamtraps
> > capture them!"
> > 
> > So all Mr. Bad Guy needs to do now is realise the significant
> > uptake of  greylisting for this one purpose, and never spam
> > any host that seems to  accept all initial transactions.  They
> > can do this simply by not entering  the DATA state.  And if
> > that's used as metric, by sharing data amongst  themselves as
> > to the exact purpose of non-greylisting hosts.
> > 
> > Any thoughts?
> > 
> > Cheers,
> > Sabahattin
> 
> First, your subject line appears to be wrong to me: "everyone"
> other than honeypots do not greylist.

Not now.  The subject line is the idea some spammer has when Greylisting 
is implemented across the board and it's clear they have to target 
greylisted hosts.  This is what greylisters say will happen, of course, as 
it most certainly will eventually.  And when it does, the only lasting 
counterattack is RBLs and similar, which spammers have a vested interest 
in not getting listed on because if they did then every single time a spam 
run gets caught a whole bunch of hosts don't accept their mail after a 
delay just long enough for the spammers to incriminate themselves.  (Sorry 
for assuming, as I sometimes do, that you can read my mind.)

> Second, if I correctly understand what you are proposing above
> (and it is possible that I do not), why do you believe that the
> spammers will cooperate in behaving the way you want/ expect?

This isn't a proposal, I'm just thinking like a spammer for a moment 
(urgh).  I don't think you've understood what I'm saying up until now, 
though.  This is just a terrible thought - that the lasting argument for 
greylisting's continued existence is kind of dead if it becomes so 
absolutely prevalent that spammers go back to square one, that of stepping 
very carefully so as to avoid trapping themselves.  Knowing who the 
spamtraps are won't require any special skill or cooperation if legitimate 
receivers rely on BLs actually catching spamtrap mail, because (of course) 
the MTS can now be easily tricked into revealing the purpose of the 
spamtrap address - that is, since it now accepts every kind of mail from 
anywhere, it *must* be intended as bate.

I suppose the continued practice of hiding spamtraps in obscure places and 
relying on their being found by robots alone can still work even with 
greylisting in effect, but the results are probably much less useable 
because there's no mail evidence to coroborate the spamminess of the 
trap's input without waiting for the usual greylisting delay (assuming the 
spammer really does come back, as will be the case later).  Still, no 
doubt it would be the next defense - just auto-blacklist any attempted use 
of bogus addresses and then share.  I know though that I wouldn't trust my 
traps' inputs alone all to be spam, and have on a couple of occasions had 
to moderate input from misinformed humans trying to send mail into the 
feed on a couple of the more exposed addresses.

> They have about zero incentive to go to extra effort to not send
> mail to particular addresses unless doing so will net them a
> _huge_ (think severals orders of magnitude) increase in the
> number of messages that get delivered.

So we'll imagine that's happened.  Even now, quite a few greylistings are 
aborted on a friend's machine of mine for spams that get through because 
of the class C exception rule; zombies on the same ISP as initial sender 
just happen to redo the transaction as part of their campaign, often 
within minutes of the initial time (5 mins) running out.  I'm sure the 
spammers are keeping their eyes open on this.  Also, spamtraps look and 
feel just like regular email addresses until mail is sent to them, so 
spammers have no more or less reason to try them over regular accounts.

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Wed, 05 Dec 2007 13:32:30 -0500
From: "David F. Skoll" <[email-masked]>
To: [email-masked]
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Sender: [email-masked]

Sabahattin Gucukoglu wrote:

> Does this notion bother anyone, in particular?

[Avoid spamming hosts that do NOT greylist because they are probably
 honeypots.]

Except we greylist after the final "." after DATA.  So that eliminates
that attack.  Also, greylisting is not *that* widely used, so a strategy
of not spamming non-greylisting servers would probably be counterproductive.

Regards,

David.

Date: Wed, 05 Dec 2007 13:08:07 -0500
From: John C Klensin <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>, [email-masked]
Subject: Re: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Sender: [email-masked]

--On Wednesday, 05 December, 2007 17:30 +0000 Sabahattin
Gucukoglu <[email-masked]> wrote:

> Does this notion bother anyone, in particular?
> 
> The argument for greylisting is apparently no longer - and if
> it is, it  can't be for *much* longer - that, "So what if we
> can't detect non-MTSs  anymore?  We can still trap the bad
> ones by letting our favourite non- greylisting BL spamtraps
> capture them!"
> 
> So all Mr. Bad Guy needs to do now is realise the significant
> uptake of  greylisting for this one purpose, and never spam
> any host that seems to  accept all initial transactions.  They
> can do this simply by not entering  the DATA state.  And if
> that's used as metric, by sharing data amongst  themselves as
> to the exact purpose of non-greylisting hosts.
> 
> Any thoughts?
> 
> Cheers,
> Sabahattin

First, your subject line appears to be wrong to me: "everyone"
other than honeypots do not greylist.

Second, if I correctly understand what you are proposing above
(and it is possible that I do not), why do you believe that the
spammers will cooperate in behaving the way you want/ expect?
They have about zero incentive to go to extra effort to not send
mail to particular addresses unless doing so will net them a
_huge_ (think severals orders of magnitude) increase in the
number of messages that get delivered.

     john
     http://www.rhyolite.com/anti-spam/you-might-be.html

Date: Wed, 05 Dec 2007 12:46:44 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
CC: [email-masked]
Subject: Re: FYI: Email Standards Compliance  Project
Sender: [email-masked]

Dave Crocker wrote:
> 
> FOlks,
> 
> Just got sent a pointer to:
> 
>    <http://www.email-standards.org/>
> 
> which seeks to rate MUAs and webmail sites for standards compliance.
> 
> d/

<html>
<body>
<H4>Oh gosh!</H4>
</body>
</html>

-- 
Hector Santos, CTO
http://www.santronics.com

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Wed, 05 Dec 2007 17:30:28 -0000
Subject: Everyone Greylists Except Honeypots ... So Let's Not Spam Honeypots!
Content-description: Mail message body
Sender: [email-masked]

Does this notion bother anyone, in particular?

The argument for greylisting is apparently no longer - and if it is, it 
can't be for *much* longer - that, "So what if we can't detect non-MTSs 
anymore?  We can still trap the bad ones by letting our favourite non-
greylisting BL spamtraps capture them!"

So all Mr. Bad Guy needs to do now is realise the significant uptake of 
greylisting for this one purpose, and never spam any host that seems to 
accept all initial transactions.  They can do this simply by not entering 
the DATA state.  And if that's used as metric, by sharing data amongst 
themselves as to the exact purpose of non-greylisting hosts.

Any thoughts?

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Cc: [email-masked]
From: "Derek J. Balling" <[email-masked]>
To: [email-masked]
Subject: Re: FYI: Email Standards Compliance  Project
Date: Wed, 5 Dec 2007 12:13:01 -0500
Sender: [email-masked]

--Apple-Mail-337--475750055
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

> Just got sent a pointer to:
>
>   <http://www.email-standards.org/>
>
> which seeks to rate MUAs and webmail sites for standards compliance.

In fairness, the only "compliance" they are testing is HTML-message  
compliance.

Nothing that actually relates to SMTP specifications at all, sadly. :-(

--

Derek J. Balling
Manager of Systems Administration
Vassar College
124 Raymond Ave
Box 0406 - Computer Center 229
Poughkeepsie, NY 12604
W: (845) 437-7231
C: (845) 249-9731

--Apple-Mail-337--475750055
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-337--475750055--

Date: Wed, 05 Dec 2007 09:14:37 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Pete Resnick wrote:
> On 12/1/07 at 3:30 PM +0000, John Levine wrote:
>> RFC 2822 section 3.6.2 describes originator fields.  By my reading it 
>> is pretty clear that a list should add a Sender: field with the list's 
>> name since it's the list that's sending the mail.
> 
> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 2919) 
> if they want to indicate something. Fields in the original message 
> should be preserved as-is.

Well, let's get back to first princples.  RFC 2822 3.6.2:

      "The "Sender:" field specifies the
    mailbox of the agent responsible for the actual transmission of the
    message."

Is a message fully delivered to a mailing list processor, or is the mailing
list processor merely an odd kind of MTA?  I think there is no controversy
that it is fully delivered, with respect to the mail handling service.  This
means that the mailing list does indeed then "post" the message (back) into
the message stream. In the abstract, then, each posting is for a "new" message.

However...

Perhaps the new posting is really exactly the same as the original message,
except for the addressee list, so that the original Sender field value is
semantically valid?  To me, this has the benefit of being the most relevant
question and the detriment of being pretty subjective.  But then, email
identity strings involve a fair amount of subjectivity already, so it's
probably no major burden to have this one (too.)

Perhaps the mailing list has made significant changes to the message.
Certainly taking multiple messages, to produce a digest, qualifies but I think
other changes do, too.  Where is the limit?  I have no idea.  Since the
mailing list and the original author have a cooperative arrangement, I'm happy
to let them decide.

But the key point is that it means that retaining or replacing the Sender 
value is not a rigid decision.  In other words, it *is* a decision that the 
mailing list operator needs to make explicitly, but the choice entirely 
depends upon the amount of violence that list software does to messages it 
re-posts.

As you (Pete) said in a separate conversation, the underlying question is what 
the Sender address needs to be used for and what will serve that need best.

I don't know that we have much culture around legitimate use of that value, by 
receivers or downstream handlers.

>> Section 3.6.6 describes resent headers.  One could make a plausible 
>> argument that a list should add a Resent-Sender: rather than a Sender: 
>> but it's reasonable to do it either way.
> 
> Mailing lists using Resent-* fields gives me the willies. Resent-* 
> fields were intended for MUAs resending mail. They weren't intended for 
> mailing lists.

Resent was an entirely reasonable idea, but it is one that proved far more
problematic than beneficial.  It works from a simplistic model that seemed 
like a wonderful idea at the time and, IMO, has since shown to merely add 
confusion and complexity rather than benefit.

Frankly I think it should be deprecated, because it causes so much trouble.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 05 Dec 2007 08:52:01 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: FYI: Email Standards Compliance Project
Sender: [email-masked]

Arnt Gulbrandsen wrote:
>>    <http://www.email-standards.org/>
>>
>> which seeks to rate MUAs and webmail sites for standards compliance.
>
> Not quite. It rates them for HTML display standards compliance. If a 
> mail reader has perfect HTML, CSS and javascript support, it gets full 
> points from that site. 

... and probably fails any reasonable security/privacy test.

<csg>

Date: Wed, 5 Dec 2007 16:46:56 +0000
From: "Peter Bowyer" <[email-masked]>
To: [email-masked]
Subject: Re: FYI: Email Standards Compliance Project
Sender: [email-masked]

On 05/12/2007, Dave Crocker <[email-masked]> wrote:
>
> FOlks,
>
> Just got sent a pointer to:
>
>    <http://www.email-standards.org/>
>
> which seeks to rate MUAs and webmail sites for standards compliance.

I thought for a moment they might be testing for compliance with email
RFCs.. unfortunately not, it's all about web standards compliance :-(

-- 
Peter Bowyer
Email: [email-masked]

Date: Wed, 5 Dec 2007 17:41:11 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: FYI: Email Standards Compliance Project
Sender: [email-masked]

Dave Crocker writes:
> Just got sent a pointer to:
>
>    <http://www.email-standards.org/>
>
> which seeks to rate MUAs and webmail sites for standards compliance.

Not quite. It rates them for HTML display standards compliance. If a 
mail reader has perfect HTML, CSS and javascript support, it gets full 
points from that site.

Arnt

Date: Wed, 05 Dec 2007 08:21:11 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: FYI: Email Standards Compliance  Project
Sender: [email-masked]

FOlks,

Just got sent a pointer to:

    <http://www.email-standards.org/>

which seeks to rate MUAs and webmail sites for standards compliance.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 05 Dec 2007 13:06:29 +0000
To: Pete Resnick <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Parsing a header
Sender: [email-masked]

At 22:08 03/12/2007, Pete Resnick wrote:

>[Not clear on why this is on ietf-smtp instead of ietf-822, but anyway...]
>
>On 12/3/07 at 7:53 PM +0100, Frank Ellermann wrote:
>
>>Paul Smith wrote:
>>>syntactically correct formations of the line could be:
>>>
>>>From: "Joe (Joseph) Bloggs" <[email-masked]>
>>>or
>>>From: (Joe \(Joseph\) Bloggs) [email-masked]
>>>or even
>>>From: Joe (\(Joseph\)) Bloggs <[email-masked]>
>>
>>Or From: "Joe \(Joseph\) Bloggs" <joe@example>
>>or From: Joe (Joseph) Bloggs <joe@example>
>
>or From: Joe "\(Joseph\)" Bloggs <[email-masked]>
>or From: Joe "(Joseph)" Bloggs <[email-masked]>
>
>But Frank is exactly right: The original thing is not a legal phrase 
>in any of these standards.

Thanks to everyone who replied to this. Sorry it was on the wrong list!

I'm happy now that it's been confirmed that it was a syntactically 
incorrect formation, so how it was interpreted is obviously 
implementation determined. (In our case, it was interpreted very 
badly - ie 'no displayname, no email address', so we've improved on 
that, but it was interesting to know how other people would handle it.)

Date: Tue, 04 Dec 2007 20:16:29 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC: John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Pete Resnick wrote:
> 
> [Apologies for duplicates, if any. List issues and decided to Cc 
> ietf-822 and ietf-smtp.]
> 
> On 12/1/07 at 3:30 PM +0000, John Levine wrote:
> 
>> RFC 2822 section 3.6.2 describes originator fields.  By my reading it 
>> is pretty clear that a list should add a Sender: field with the list's 
>> name since it's the list that's sending the mail.
> 
> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 2919) 
> if they want to indicate something. Fields in the original message 
> should be preserved as-is.

Unfortunately, that is not the common practice by many MLS (Mail List 
Server) systems.

Both Sender: and Reply-To: are quite often changed.

The practice is to match the Sender with the Return-path or more 
specifically who was the x821.Mail From address.  That why it works for 
MUA users in the first place and naturally falls in line when a mailing 
list owner redistributed the mail.

The problem of course, we have complicated the 1 to 1 email system into 
a 1 to Many group ware, conferencing system and there are all kinds of 
considerations here.  It is not a simple CC concept and its not a old 
school SMTP level group list forwarding concept where we don't have a 
full blown, feature rich separate but integrated List Server products 
out there.

You also have the school of thought that once an "Conference Message", 
and that is what it really is, reaches the final destination/delivery, 
only the message and TO: FROM: SUBJECT and DATE: is "copyrighted" by the 
user. The transparent network control header trace lines are no longer 
his business.  That is a long time deeply held practice across different 
mail networks.

But if the concern is the Sender: header will be replaced a MLS, thats 
really a small potato in the big barrel of many other common MLS common 
optional offerings:

    - Sender: replacement
    - Reply-To:
    - MIME, HTML, Attachments stripping
    - Footers and quite possibly headers
    - Message Wrapping with HTML FRAME, IF RAME or DIV tags
    - Digest Consolations

what else?

To me, DKIM needs to conform with what exist. Not the other way around. 
  Of course, we can make changes to our MLS systems to help make DKIM 
work better, but the idea that we will be eliminating long establish 
ideas like above, is probably a little unrealistic, not going to happen.

The better idea is for the new system (DKIM signer) to have better 
knowledge of where it is sending its mail and do not sign headers that 
are very likely to change.  This is indicated in RFC 4871 as one of many 
possible strategies in deciding which headers to sign.  Thats the more 
realistic approach to this issue.

Of course, my opinion.

-- 
Hector Santos, CTO
http://www.santronics.com

From: [email-masked]
Cc: John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Tue, 04 Dec 2007 16:27:55 -0800 (PST)
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> [Apologies for duplicates, if any. List issues and decided to Cc
> ietf-822 and ietf-smtp.]

> On 12/1/07 at 3:30 PM +0000, John Levine wrote:

> > RFC 2822 section 3.6.2 describes originator fields.  By my reading
> > it is pretty clear that a list should add a Sender: field with the
> > list's name since it's the list that's sending the mail.

> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC
> 2919) if they want to indicate something. Fields in the original
> message should be preserved as-is.

> > Section 3.6.6 describes resent headers.  One could make a plausible
> > argument that a list should add a Resent-Sender: rather than a
> > Sender: but it's reasonable to do it either way.

> Mailing lists using Resent-* fields gives me the willies. Resent-*
> fields were intended for MUAs resending mail. They weren't intended
> for mailing lists.

Rathole alert.

The question of what mailing lists should or should not do to message headers
in general and originator fields in particular has been one of the most hotly
debated topics in email over the years, and I've seen no indication that any
consensus has formed around a particular position.

The working that was chartered some years back to attempt to deal with this
self-destructed.

Plenty of people (like Pete, apparently) believe that mailing lists should not
mess around with originator headers at all, ever. There was a time when this
position was so prevalent that the operators of mailing list expanders
routinely got flamed for operating in any other way.

Others believe that it is perfectly OK for mailing lists to insert Sender:
fields. There's even a school of thought that says a From: should be inserted
(haven't seen too many proponents of that one since 2822 came out, but it may
still exist).

I don't recall anyone considering using Resent- fields for this until just now,
but I could easily have missed it - these debates frequently have descended
into nasty personal attacks, causing me to tune out.

Speaking as an implementor of mailing list software, I've long since given up
trying to tell people how this should be configured. As a result our software
lets people do whatever they want in this regard. And that's exactly what
people do - whatever they want.

My personal opinion is that a rule either way on originator field issue would
be better than the current situation. But I also think it is unlikely that
consensus can be reached on one.

				Ned

Date: Tue, 4 Dec 2007 15:52:16 -0800
To: John Levine <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

[Apologies for duplicates, if any. List issues and decided to Cc 
ietf-822 and ietf-smtp.]

On 12/1/07 at 3:30 PM +0000, John Levine wrote:

>RFC 2822 section 3.6.2 describes originator fields.  By my reading 
>it is pretty clear that a list should add a Sender: field with the 
>list's name since it's the list that's sending the mail.

Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 
2919) if they want to indicate something. Fields in the original 
message should be preserved as-is.

>Section 3.6.6 describes resent headers.  One could make a plausible 
>argument that a list should add a Resent-Sender: rather than a 
>Sender: but it's reasonable to do it either way.

Mailing lists using Resent-* fields gives me the willies. Resent-* 
fields were intended for MUAs resending mail. They weren't intended 
for mailing lists.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Parsing a header
Date:  Tue, 4 Dec 2007 00:35:37 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 6
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:
 
> Not clear on why this is on ietf-smtp instead of ietf-822

I almost always start on the wrong of the two lists, and in
that case I was happy that it's not also always only me. ;-)

From: [email-masked]
Cc: [email-masked]
Date: Mon, 03 Dec 2007 14:37:08 -0800 (PST)
Subject: Re: Parsing a header
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> [Not clear on why this is on ietf-smtp instead of ietf-822, but anyway...]

> On 12/3/07 at 7:53 PM +0100, Frank Ellermann wrote:

> >Paul Smith wrote:
> >>syntactically correct formations of the line could be:
> >>
> >>From: "Joe (Joseph) Bloggs" <[email-masked]>
> >>or
> >>From: (Joe \(Joseph\) Bloggs) [email-masked]
> >>or even
> >>From: Joe (\(Joseph\)) Bloggs <[email-masked]>
> >
> >Or From: "Joe \(Joseph\) Bloggs" <joe@example>
> >or From: Joe (Joseph) Bloggs <joe@example>

> or From: Joe "\(Joseph\)" Bloggs <[email-masked]>
> or From: Joe "(Joseph)" Bloggs <[email-masked]>

> But Frank is exactly right: The original thing is not a legal phrase
> in any of these standards.

Frank is also correct in point out that we don't have rules for how to deal
with such invalid syntax. And specifying such rules is a rathole I'd really
like to avoid.

More generally, there's a vast range of stuff that's close to being allowed but
isn't. I don't have a problem discussing how to handle such cases, but once it
is determined that the material is syntactically invalid it becomes an
operational issue, not a specification issue.

FWIW, I tried this specific example with our heuristic fixup parser and it
converted it to

    Joe Joseph Bloggs <[email-masked]>

which isn't bad but isn't what I would have guessed it would do. Guess I need
to go review the code since I've clearly forgotten some details.

				Ned

Date: Mon, 3 Dec 2007 14:08:21 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Parsing a header
Sender: [email-masked]

[Not clear on why this is on ietf-smtp instead of ietf-822, but anyway...]

On 12/3/07 at 7:53 PM +0100, Frank Ellermann wrote:

>Paul Smith wrote:
>>syntactically correct formations of the line could be:
>>
>>From: "Joe (Joseph) Bloggs" <[email-masked]>
>>or
>>From: (Joe \(Joseph\) Bloggs) [email-masked]
>>or even
>>From: Joe (\(Joseph\)) Bloggs <[email-masked]>
>
>Or From: "Joe \(Joseph\) Bloggs" <joe@example>
>or From: Joe (Joseph) Bloggs <joe@example>

or From: Joe "\(Joseph\)" Bloggs <[email-masked]>
or From: Joe "(Joseph)" Bloggs <[email-masked]>

But Frank is exactly right: The original thing is not a legal phrase 
in any of these standards.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Parsing a header
Date:  Mon, 3 Dec 2007 19:53:10 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 37
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Paul Smith wrote:
 
> From: Joe \(Joseph\) Bloggs <[email-masked]>
 
> My reading of RFC 2822 says that this is three "tokens", 'Joe',
> '\' and an unfinished comment '(Joseph) Bloggs <[email-masked]>'

I think it's "Joe" followed by a syntax error, how you resume
parsing after an error, e.g. arriving at "unfinished comment",
not at all, or ignoring an invalid quoted-pair, isn't specified.

> the '\' before the '(' isn't a quoting '\' but a real '\'.

The real backslash is a real syntax error at this place.

> Outside comments you use " characters for quoting.

Quoted pairs can also appear within quoted strings, or in
domain-literal, maybe more, not only in comments.  And
quoted strings aren't allowed everywhere, e.g. not as a
domain-literal, domain-literals use square brackets.

> syntactically correct formations of the line could be:
 
> From: "Joe (Joseph) Bloggs" <[email-masked]>
> or
> From: (Joe \(Joseph\) Bloggs) [email-masked]
> or even
> From: Joe (\(Joseph\)) Bloggs <[email-masked]>

Or From: "Joe \(Joseph\) Bloggs" <joe@example>
or From: Joe (Joseph) Bloggs <joe@example>

Using the new 2821bis style of a TLD address,
we're on the SMTP list... :-)

 Frank

Date: Mon, 3 Dec 2007 15:17:52 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Parsing a header
Cc: Hector Santos <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Paul Smith writes:
> At 12:29 03/12/2007, you wrote:
>> Paul Smith wrote:
>>> How do you think you should parse this header according to RFC 2822?
>>> From: Joe \(Joseph\) Bloggs <[email-masked]>
>>
>> My view is why are you parsing the display name?
>
> To display in an email client.

In a somewhat similar case, I first do real 822 parsing, then if that 
fails, I scan for "@", and from each "@" left and right until I hit 
",", EOL, BOL, "<" or ">". If I hit the right number of the right 
things around each "@", and the localpart and domain seem sensible, I 
assume that I've found all the email addresses in the header field and 
disregard the display-names.

In case of the field you quote I'd probably end up displaying just

     From: [email-masked]

This fallback isn't perfect, but it's also not too complex and it finds 
the significant data in a lot of bad header fields. And who cares, 
really? If anyone really wants the display-name to be displayed, let 
him/her encode it according to RFC 822.

Arnt

Date: Mon, 03 Dec 2007 13:36:04 +0000
To: Hector Santos <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: Parsing a header
Sender: [email-masked]

At 12:29 03/12/2007, you wrote:
>Paul Smith wrote:
>>How do you think you should parse this header according to RFC 2822?
>>From: Joe \(Joseph\) Bloggs <[email-masked]>
>>My reading of RFC 2822 says that this is three "tokens", 'Joe', '\' 
>>and an unfinished comment '(Joseph) Bloggs <[email-masked]>'
>>As far as I can see you can have quoted pairs like '\)' in 
>>comments, but not outside comments, so the '\' before the '(' isn't 
>>a quoting '\' but a real '\'. Outside comments you use " characters 
>>for quoting.
>>Is this right, or am I missing something?
>>AFAICS, syntactically correct formations of the line could be:
>>From: "Joe (Joseph) Bloggs" <[email-masked]>
>>or
>>From: (Joe \(Joseph\) Bloggs) [email-masked]
>>or even
>>From: Joe (\(Joseph\)) Bloggs <[email-masked]>
>
>Hi Paul,
>
>I am not sure the second one is valid legacy format.

Why not?

>My view is why are you parsing the display name?

To display in an email client. I want to split the field into two 
parts - the address and the display name.

>There is really just two parts here:
>
>     angle-addr   -->  <[email-masked]>
>     display-name -->  everything else, who cares!
>
>Generally, you have this two formats to check:
>
>     displayname <addr-spec>      current
>     addr-spec (displayname)      legacy

Generally - but it isn't that simple AFAICS. In the second, the 
'(displayname)' is simply a comment (included in the CFWS part of 
'obs-mbox-list')

obs-mbox-list in RFC 2822 is defined as

obs-mbox-list   =       1*([mailbox] [CFWS] "," [CFWS]) [mailbox]

So, for all except the last mailbox, the comment should come after 
the mailbox, but for the last one, it should come before. It also 
looks like you also aren't allowed a comment if you only have one mailbox??

Our parser will handle the comment either before or after the mailbox 
in both cases, as we've seen both of these.

AFAICS RFC 822 just allows comments anywhere, so before or after are 
both allowed by RFC 822. Potentially, RFC 822 would allow
From: (Joe) joe(that's Joseph)@joe(that's joe's company (oh yes it is)).com

Also the form
displayname <addr-spec>
says that 'displayname' is a 'phrase',  which can be 1*word or obs-phrase
and obs-phrase can contain CFWS

So, RFC 2822 lets you have

From: Joe (Joseph) Bloggs <[email-masked]>

Here, "Joseph" is an allowed comment in the displayname part of the 
header field. Comments support quoted-pairs, but the rest of the 
displayname part doesn't seem to. Hence my original question :)

If you don't handle this correctly, you'd have problems with:

From: Joe (Joseph \)  Bloggs <[email-masked]> \(my company) <[email-masked]>

Here, the display name is "Joe", with a comment "Joseph )  Bloggs 
<[email-masked]> (my company", and an email address <[email-masked]>
You have to parse the comments to know that the '\)' after the '(' is 
not a closing of the comment, but a quoted-pair character.

Also, simply checking for <address> first here would break things, as 
<[email-masked]> isn't the address.

Also, '<addr-spec>' is angle-addr, which can be obs-angle-addr which 
is defined as
[CFWS] "<" [obs-route] addr-spec ">" [CFWS]

So, you could have

From: Joe (Joseph) Bloggs <[email-masked]> (Another comment)

or (to be really awkward)
From: Joe (Joseph\) Bloggs <[email-masked]> ) <[email-masked]> (Another 
comment \) <[email-masked]> )

Since comments are allowed after the <addr-spec> in obs-angle-addr

So - parsing it isn't that simple...

To make things even more fun, you can have comments inside the <> as 
well in RFC 2822 - see obs-route. You're unlikely to have them since 
people don't generally use source routes any more, but you need to be 
able to parse them.

Date: Mon, 03 Dec 2007 07:29:53 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: Parsing a header
Sender: [email-masked]

Paul Smith wrote:
> 
> How do you think you should parse this header according to RFC 2822?
> 
> From: Joe \(Joseph\) Bloggs <[email-masked]>
> 
> My reading of RFC 2822 says that this is three "tokens", 'Joe', '\' and 
> an unfinished comment '(Joseph) Bloggs <[email-masked]>'
> 
> As far as I can see you can have quoted pairs like '\)' in comments, but 
> not outside comments, so the '\' before the '(' isn't a quoting '\' but 
> a real '\'. Outside comments you use " characters for quoting.
> 
> Is this right, or am I missing something?
> 
> AFAICS, syntactically correct formations of the line could be:
> 
> From: "Joe (Joseph) Bloggs" <[email-masked]>
> or
> From: (Joe \(Joseph\) Bloggs) [email-masked]
> or even
> From: Joe (\(Joseph\)) Bloggs <[email-masked]>

Hi Paul,

I am not sure the second one is valid legacy format.

My view is why are you parsing the display name?

There is really just two parts here:

     angle-addr   -->  <[email-masked]>
     display-name -->  everything else, who cares!

Generally, you have this two formats to check:

     displayname <addr-spec>      current
     addr-spec (displayname)      legacy

The display name should be passive and transparent.

So the parser should first check for the angle-addr for the address and 
everything else becomes the display name.

If there is no angle address, then look for the quote string or comment 
for the display name and the remainder is the address.  In fact, as I 
mentioned above, the second example does not appear to be valid as the 
comment should follow the address.  Therefore, you can check for the 
first space as a delimiter if there is no angle address.  But even if it 
was acceptable, you can detect it is not a valid address since it is 
commented.

Makes sense?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 03 Dec 2007 11:00:40 +0000
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: Parsing a header
Sender: [email-masked]

How do you think you should parse this header according to RFC 2822?

From: Joe \(Joseph\) Bloggs <[email-masked]>

My reading of RFC 2822 says that this is three "tokens", 'Joe', '\' 
and an unfinished comment '(Joseph) Bloggs <[email-masked]>'

As far as I can see you can have quoted pairs like '\)' in comments, 
but not outside comments, so the '\' before the '(' isn't a quoting 
'\' but a real '\'. Outside comments you use " characters for quoting.

Is this right, or am I missing something?

AFAICS, syntactically correct formations of the line could be:

From: "Joe (Joseph) Bloggs" <[email-masked]>
or
From: (Joe \(Joseph\) Bloggs) [email-masked]
or even
From: Joe (\(Joseph\)) Bloggs <[email-masked]>

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Possible ambiguity in SMTP RFC2821 - your opinon please
Date:  Mon, 3 Dec 2007 03:52:26 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 12
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

> 2821bis clearly permits single-component (TLD-only) domains

http://www.openspf.org/?action=browse&diff=1&id=RFC_4408/Errata

If 2821bis permits it it can't be an 4408-erratum.  Of course
it's still not possible to use TLDs directly in an SPF policy,
RFC 4408 is based more on RFC 3696 and 2821 than 2821bis for
obvious reasons.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: New Issue: NOOP clarification
Date:  Sun, 2 Dec 2007 18:39:10 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 74
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:

> Does this make since? After the ABNF statement, add a note:
>     Syntax:
>        "NOOP" [ SP String ] CRLF
>     Note: If the SMTP client is required to fall back to a
>     HELO because it has connected to a legacy SMTP server following
>     RFC 821 (STD 10) specifications, then all follow up commands MUST
>     conform to RFC 821 command syntax. e.g., the client MUST not
>     send a string with the NOOP command.

No general discussion necessary at this point, you can trim the note:

|     Note: If the SMTP client used the HELO command as explained
|     in section 3.1, then it MUST NOT send a string with NOOP.

We could also twist it:  "If and only if" ... "then the server MAY
reject a NOOP command with a string as RFC 821 syntax error".  

The consequence "better do not try this after HELO" is obvious, 
but a MAY still allows for whatever caused the introduction of
this oddity in 2821.

>     If the client issued a "NOOP string" command before the EHLO,
>     it is possible to received a negative response 421 or 500
>     from a legacy SMTP server. In this case, the client MAY
>     use this negative response to proceed with a  HELO fall
>     back command.

In the twisted KISS style that could be:

|     A server supporting only RFC 821 syntax MAY treat a NOOP
|     command with a string as syntax error (500).

We can't use a "legacy" qualifier, it's not defined in the draft.
As John explained 421 is unrelated to the problem at hand, it is
always allowed when a server wants to get rid of a(ll) client(s).

> Of course, as John pointed out, it would of been better if the
> MS server had use 500 instead of 421.

Yes, better don't mention 421 here, 2821bis is the spec., it's not
some kind of Exchange or Sendmail manual.

> Of course, I don't think this is material for the specs. But at
> least we have a unofficial work around available to avoid mail
> delivery issues.

Don't send spam with NOOP, nobody is going to read it, and MS even
rejects it, well done... <gd&r>

> I can only guess "logging" were on people's mind. Thats how we
> are using it.

NOOP as User-Agent emulation ?  Apparently that doesn't fly, maybe
that's a good thing, servers behaving differently depending on the
"client identification" are a nuisance in other protocols.

> Now that I think about it, I seem to recall Microsoft's Caller-ID 
> proposal taking  NOOP to another level:
 
>      http://tools.ietf.org/html/draft-atkinson-callerid-00

Omigod, "enhanced NOOP", that certainly fits with "XML over DNS".
 
> Caller ID for E-mail was MS's original entry into the mix of LMAP

It was anything but not an "L" in LMAP, compare the original LMAP
draft as explained in <http://en.wikipedia.org/wiki/MARID>.  

This blatant case of [censored] is now Internet history, RFC 4405
has no "enhanced NOOP" (also has no "embraced" or "extended" NOOP).

 Frank

Cc: [email-masked], [email-masked]
From: Douglas Otis <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Subject: Re: Mailing lists as 2822-Sender
Date: Sun, 2 Dec 2007 00:42:45 -0800
Sender: [email-masked]

On Dec 1, 2007, at 1:11 PM, Frank Ellermann wrote:

> John Levine wrote on the DKIM list:
>>
>> This has nothing to do with DKIM, Sender-ID, or anything other than  
>> RFCs 2822 and 822.
>
> Doug's SSP-TPA is related to DKIM and I think it mentions the PRA.

SSP-TPA can deal with PRA related headers, but only because headers  
other than From may also represent who originated the message.

The SSP-TPA draft provides a means to assert scope.  Scope is broken  
down into three areas:

1) From originating header (Normal SSP scope)
2) Other than From originating headers (Sender, and Resent-*)

For example, a mailing list might wish to assert identities associated  
with email-addresses within the Sender header are "authenticated".   
The current DKIM base specification prevents i= semantics from being  
able to make this assertion.

3) TPA-SSP also provides a MAILFROM policy assertion that might be  
used when issuing a DSN.

Currently, there is the F-i, O-i, and M-i assertions.  From feedback  
on the list, perhaps F-a, O-a, and M-a, could be added, where the i=  
identity would then track the account gaining access, rather than  
indicating an identity associated with an email-address found in an  
originating header (Originating with a small 'o') has been  
authenticated.

In addition to ensuring a mistake is not made regarding an assumption  
of authentication or uniqueness, being able to express scope better  
defends a DKIM validation process.

<rant>
Levels of abuse are doubling at an interval far less than that for  
hardware's performance doubling.  Several product lines have been  
dropped when coping with abuse was not economically practical.  In  
addition, detecting obfuscation techniques also demands a steep  
increase in resources.  (The sky is not falling, but the horizon looks  
very dark.)

Source reputation may be a means to deal with this growing abuse  
problem.  Unfortunately, a rising percentage of abuse is being sent  
through large provider's outbound MTAs.

Users being blocked by their own provider confronts a conflict of  
interest.  Often the provider's desire is to reduce operational costs  
and minimize support efforts.  When the large provider is completely  
blocked by receiving domains, a sizeable support cost will be created  
for both transmitting and receiving domains due to a resulting high  
level of collateral blocking.  When users are blocked individually by  
many receiving domains, the user just might understand the problem to  
be theirs.  This understanding could be reinforced when many different  
failure notifications clearly indicate their account has earned a bad  
reputation.  When these users contact those blocking them, support  
costs will also be distributed, often to those in the business of  
blocking abusive sources.

DKIM might allow such a clear user notification when SSP or TPA-SSP  
records include a scope parameter.

DKIM could help solve the large domain abuse problem in a way that  
justifies resources needed to validate DKIM signatures.  Without an  
ability for the receiver to resolve problems at a smaller granularity  
than the domain, issues related to bots and replay abuse will likely  
cause DKIM validation to be bypassed for all but those domains being  
phished.
</rant>

> RFC 4406 requires to violate the quoted 2821(bis) MUSTard for its  
> purposes, it even got an IESG note about the fact.  And (2)822(upd)  
> doesn't mention mailing lists explicitly.  Now is a good time to get  
> this right, as my attempt to switch to the rfc822 list failed, I now  
> try the smtp list, it's a potential bug in 2821bis.

The conflict appears to be in RFC4406 section 7.2 regarding  
recommendations to inject Resent-From or Sender headers when forwarding.

While Sender-ID has created problems for mailing-lists, forwarding  
also causes problems.  Resolving all addresses used by a domain makes  
abuse less tractable, in addition to placing DNS itself in peril.  If  
email ever embraces IPv6, this would double the related overhead and  
risk related to IP address path registration.

It this weren't such a rate-hole, TPA-SSP records could include scope  
assertions declaring DKIM's relationships to SMTP clients, and whether  
all outbound messages are always signed by the domain's SMTP clients.   
SMTP client assertions would provide a far safer alternative to IP  
address path registrations.

-Doug

Date: Sat, 01 Dec 2007 23:55:32 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: New Issue: NOOP clarification
Sender: [email-masked]

Peter J. Holzer wrote:
> This is an incompatible change in the protocol, as a client conforming
> to RFC 2821 is of course perfectly correct in sending the optional
> parameter while the server conforming to RFC 821 is equally correct in
> rejecting it. 

Ok, this is just practice. :-) I am just winging it. Not proposing it 
should be added. Just food for thought.

Does this make since? After the ABNF statement, add a note:

    Syntax:
       "NOOP" [ SP String ] CRLF

    Note: If the SMTP client is required to fall back to a
    HELO because it has connected to a legacy SMTP server following
    RFC 821 (STD 10) specifications, then all follow up commands MUST
    conform to RFC 821 command syntax. e.g., the client MUST not
    send a string with the NOOP command.

    If the client issued a "NOOP string" command before the EHLO,
    it is possible to received a negative response 421 or 500
    from a legacy SMTP server. In this case, the client MAY
    use this negative response to proceed with a  HELO fall
    back command.

Of course, as John pointed out, it would of been better if the MS server 
had use 500 instead of 421.

But at least implementators who are aware of this do have a work around. 
  Our CBV issues the NOOP before the EHLO, so we can possibly use this 
unique response to continue the section:

   S: 220 example.com Microsoft ESMTP MAIL Service ....
   C: NOOP WCSAP v2.09 Wildcat! Sender Authentication Protocol ..
   S: 421 5.5.2 Syntax error (command line too long)
   C: EHLO mail.winserver.com

Of course, I don't think this is material for the specs. But at least we 
have a unofficial work around available to avoid mail delivery issues.

> There is a way for the client to handle this problem: Send the optional
> parameter only if the server recognized EHLO (since then it claims to
> conform to 2821) and omit it otherwise. But 2821 contains no hint that
> the parameter is new and incompatible with 821, so this issue is only
> apparent if you compare the two RFCs. 

Right. For the scenario like above where the NOOP is issued before the 
EHLO, then I don't see no choice but detect this unique response and 
continue with an EHLO.   I am guessing, but if it was truly a strict 821 
system, it might issue the 500 "invalid syntax"" response.

Of course, we could also change our code to issue the NOOP after EHLO or 
HELO is determined.  If it fall backs to HELO, then we know for sure not 
to issue the NOOP string, in that case, we probably won't even issue 
NOOP at all since the main purpose for here was to allow the server to 
log it.  That is how it currently used today by CBV systems.

> RFC 2821 also introduced the
> extension mechanism, which allows adding additional parameters to
> existing commands. For some reason, this was not used for NOOP, but an
> incompatible change was made in the core protocol (which I admit I don't
> understand: What is the purpose of this parameter? Why was it added at
> all? To reflect actual usage or just because somebody thought it might
> be useful?)

I can only guess "logging" were on people's mind. Thats how we are using 
it.  However, for one CBV system I am aware off, based on their "How it 
works" documentation, they are adding a 32 bit unique hex hash number (8 
characters) for tracing and also to help detect loops (show how).

Now that I think about it, I seem to recall Microsoft's Caller-ID 
proposal taking  NOOP to another level:

     http://tools.ietf.org/html/draft-atkinson-callerid-00

Caller ID for E-mail was MS's original entry into the mix of LMAP 
(domain::ip association) protocols which eventually merged with SPF to 
create SENDER-ID:

   5.2 SMTP Security Considerations

   ...

   Specifically, prior to sending any SMTP MAIL commands, an SMTP
   client SHOULD send to its server an SMTP NOOP command (see section

     The 40 case-insensitive characters of the hexadecimal encoding
     of the SHA1 hash of the entire data provided previously by the
     server in its EHLO response (that is, the entire sequence of
     characters matching the ehlo-ok-rsp production found in section
     4.1.1.1 of [rfc2821]).

   By including a pseudorandom string as part of its EHLO response, an
   SMTP server can have reasonable confidence that, upon the receipt
   of such a NOOP command, the SMTP client is in fact receiving its
   responses, and one-side TCPIP hijacking is not occurring. Note that,
   as a security consideration, the SMTP server provides no indication
   in response to the NOOP as to whether a correct hash value was
   provided.

And I would swear I seen other drafts that attempt to use NOOP for some 
"authentication" purpose as well.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Mailing lists as 2822-Sender
Date:  Sun, 2 Dec 2007 01:04:59 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 24
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Peter J. Holzer wrote:

  [3.9]
>> Note "the message header section [...] MUST be left unchanged".  
 
>> We're in Last Call about this, this will be the "law", if you
>> think it is flawed please say so - but better not only on the
>> DKIM list.

> Thanks for pointing this out. I do think this is flawed. Not
> only prevents this inserting or altering a "Sender" field,

I'd be tempted to accept this as collateral damage, but this...

> it also contradicts RFC 2369 (a proposed standard), which 
> recommends inserting various "List-*" fields into the header.

...is of course serious.  The Last Call was premature, we need
to go through the complete draft, one section per week, or a
similar approach.  Now I'm very curious what John thinks of
touching MUSTard in 2821bis, I recall his comment about a MUST
in my "4409 to STD" proposal (also related to 4406 oddities).

 Frank

Date: Sat, 01 Dec 2007 19:02:22 -0500
From: John C Klensin <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>, [email-masked]
Subject: Re: New Issue: NOOP clarification
Sender: [email-masked]

--On Sunday, 02 December, 2007 00:25 +0100 "Peter J. Holzer"
<[email-masked]> wrote:

>...
> This is an incompatible change in the protocol, as a client
> conforming to RFC 2821 is of course perfectly correct in
> sending the optional parameter while the server conforming to
> RFC 821 is equally correct in rejecting it. 
>...
> For some reason, this was not used for
> NOOP, but an incompatible change was made in the core protocol
> (which I admit I don't understand: What is the purpose of this
> parameter? Why was it added at all? To reflect actual usage or
> just because somebody thought it might be useful?)

My recollection is that DRUMS was trying to reflect existing
practice.  While I haven't searched the archives, the odds that
this was done by accident and without discussion are very small.

   john

Date: Sun, 2 Dec 2007 00:25:38 +0100
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: New Issue: NOOP clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--MfFXiAuoTsnnDAfZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-11-30 00:09:57 -0500, Hector Santos wrote:
> Ok, I searched:  SMTP proxy "421 5.5.2"
> 
> Very interesting! This seems this is an issue with the Microsoft 
> Internet Security and Acceleration (ISA) server. MS has this KB 
> description and resolution for it:
> 
>     http://support.microsoft.com/kb/312213
> 
> It was definitely following RFC 821!!  From the article:

I think there is a lesson to learn here. In RFC 821 the syntax of the
NOOP command was:

    NOOP <CRLF>

No optional parameter or even trailing spaces allowed. A server
conforming to RFC 821 is completely correct in rejecting a NOOP command
with a parameter (a 421 return code is of course quite bizarre here.
IMHO a 501 code would be most appropriate). 

In RFC 2821 an optional parameter was added:

   Syntax:
      "NOOP" [ SP String ] CRLF

This is an incompatible change in the protocol, as a client conforming
to RFC 2821 is of course perfectly correct in sending the optional
parameter while the server conforming to RFC 821 is equally correct in
rejecting it. 

There is a way for the client to handle this problem: Send the optional
parameter only if the server recognized EHLO (since then it claims to
conform to 2821) and omit it otherwise. But 2821 contains no hint that
the parameter is new and incompatible with 821, so this issue is only
apparent if you compare the two RFCs. RFC 2821 also introduced the
extension mechanism, which allows adding additional parameters to
existing commands. For some reason, this was not used for NOOP, but an
incompatible change was made in the core protocol (which I admit I don't
understand: What is the purpose of this parameter? Why was it added at
all? To reflect actual usage or just because somebody thought it might
be useful?)

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--MfFXiAuoTsnnDAfZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--MfFXiAuoTsnnDAfZ--

Date: Sun, 2 Dec 2007 00:01:47 +0100
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Mailing lists as 2822-Sender
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-12-01 22:11:28 +0100, Frank Ellermann wrote:
> 
> John Levine wrote on the DKIM list:
> 
> >> Would the mailing list software replace the Sender: Scott header
> >> field, or would it reject the submission ?
>  
> > Replace it, since the list is the Sender: for the mail it sends.
> 
> Okay, let's say that's what "some" (= maybe almost all) lists do.
> 
> But it's not specified in RFC 1123 5.3.6(b), therefore also not in
> RFC 2821 3.10, and most important not in I-D.klensin-2821bis 3.9:
> 
> | 3.9.  Mailing Lists and Aliases
> |
> | An SMTP-capable host SHOULD support both the alias and the list
> | models of address expansion for multiple delivery.  When a message
> | is delivered or forwarded to each address of an expanded list form,
> | the return address in the envelope ("MAIL FROM:") MUST be changed
> | to be the address of a person or other entity who administers the
> | list.  However, in this case, the message header section (RFC2822
> | [9]) MUST be left unchanged; in particular, the "From" field of
> | the header section is unaffected.
> 
> Note "the message header section [...] MUST be left unchanged".  
> 
> We're in Last Call about this, this will be the "law", if you think
> it is flawed please say so - but better not only on the DKIM list.

Thanks for pointing this out. I do think this is flawed. Not only
prevents this inserting or altering a "Sender" field, it also
contradicts RFC 2369 (a proposed standard), which recommends inserting
various "List-*" fields into the header.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--W/nzBZO5zC0uMSeA--

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Mailing lists as 2822-Sender
Date:  Sat, 1 Dec 2007 22:11:28 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 39
Reply-To: "Frank Ellermann" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

John Levine wrote on the DKIM list:

>> Would the mailing list software replace the Sender: Scott header
>> field, or would it reject the submission ?
 
> Replace it, since the list is the Sender: for the mail it sends.

Okay, let's say that's what "some" (= maybe almost all) lists do.

But it's not specified in RFC 1123 5.3.6(b), therefore also not in
RFC 2821 3.10, and most important not in I-D.klensin-2821bis 3.9:

| 3.9.  Mailing Lists and Aliases
|
| An SMTP-capable host SHOULD support both the alias and the list
| models of address expansion for multiple delivery.  When a message
| is delivered or forwarded to each address of an expanded list form,
| the return address in the envelope ("MAIL FROM:") MUST be changed
| to be the address of a person or other entity who administers the
| list.  However, in this case, the message header section (RFC2822
| [9]) MUST be left unchanged; in particular, the "From" field of
| the header section is unaffected.

Note "the message header section [...] MUST be left unchanged".  

We're in Last Call about this, this will be the "law", if you think
it is flawed please say so - but better not only on the DKIM list.

> This has nothing to do with DKIM, Sender-ID, or anything other
> than RFCs 2822 and 822.

Doug's SSP-TPA is related to DKIM and I think it mentions the PRA.
RFC 4406 requires to violate the quoted 2821(bis) MUSTard for its
puposes, it even got an IESG note about the fact.  And (2)822(upd)
doesn't mention mailing lists explicitly.  Now is a good time to
get this right, as my attempt to switch to the rfc822 list failed,
I now try the smtp list, it's a potential bug in 2821bis.

 Frank

Date: Sat, 01 Dec 2007 15:10:02 -0500
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>, Bill McQuillan <[email-masked]>
cc: SMTP Discussion <[email-masked]>
Subject: Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics
Sender: [email-masked]

--On Saturday, 01 December, 2007 13:56 -0500 Hector Santos
<[email-masked]> wrote:

> 
> Bill McQuillan wrote:
>  >
>  > My copy of draft-klensin-rfc2821bis-06 would suggest 512
> characters:
>  >
>  > 4.5.3.1.4.  command line
>  >
>  >    The maximum total length of a command line including the
>  >    command word and the <CRLF> is 512 characters.  SMTP
>  >    extensions may be used to increase this limit.
>  >
> 
> Yes and note we have semantics for increasing but not lowering.
> 
> However, check this out:
> 
>        http://www.securityfocus.com/infocus/1654
>...
> What "bugs me" is the only reason they even suggest increasing
> NOOP to
> 38   is to cure mail delivery problems with their own Exchange
> servers
> who are "padding NOOP."  Well, what about the rest of the
> world?

Hector,

There is absolutely no question that this stuff exhibits a
problem.  The difficulty is that 2821 / 2821bis appear to be
fairly clear about what the right behavior is.  

The Microsoft knowledge base article you cited has a provision
for comments at the bottom.  I sent in a comment indicating that
the article was seriously off-base, and the behavior a violation
of the standard.  Who knows if that will do any good, but it
seemed like the right thing to try.  By contrast, as several
people have pointed out, making more changes to 2821 -- a
document that is being unread or deliberately ignored now--
won't help.

Almost the same issue applies to this Securityfocus piece.  The
author is wrong.  I don't know whether he is wrong because he
doesn't know that there is a standard, knows but hasn't bothered
to read it, or knows and doesn't think it is relevant.
Probably, someone who has the energy should write and comment,
either on that article or as a separate piece.   I assume that
they would accept, post, and link in such a piece.  If the
consequence of having such an article --one that was clear and
well-documented -- was damage to this author's credibility, that
would not be a bad consequence.  But it seems to me that the
cure for bad information is, where possible, corrected
information in the place where the bad stuff appeared.  

Saying something that is already said in 2821bis yet another
time (either in the document or on this list) is not helpful
unless it can be demonstrated that what _is_ there is ambiguous
or confusing to those who are reading carefully and wanting to
understand.  

    john

Date: Sat, 01 Dec 2007 13:56:30 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Bill McQuillan <[email-masked]>
CC: SMTP Discussion <[email-masked]>
Subject: Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics
Sender: [email-masked]

Bill McQuillan wrote:
 >
 > My copy of draft-klensin-rfc2821bis-06 would suggest 512 characters:
 >
 > 4.5.3.1.4.  command line
 >
 >    The maximum total length of a command line including the
 >    command word and the <CRLF> is 512 characters.  SMTP
 >    extensions may be used to increase this limit.
 >

Yes and note we have semantics for increasing but not lowering.

However, check this out:

       http://www.securityfocus.com/infocus/1654

According to this recommended setup, the allowed effective limits are:

      EHLO       65   (71 - 6)
      HELO       65   (71 - 6)
      MAIL FROM  254  (266 - 12)
      RCPT TO    256  (266 - 10)
      NOOP       32   (38 - 6)

This is so bad.

What "bugs me" is the only reason they even suggest increasing NOOP to
38   is to cure mail delivery problems with their own Exchange servers
who are "padding NOOP."  Well, what about the rest of the world?

-- 
Hector Santos, CTO
http://www.santronics.com

Date: Sat, 01 Dec 2007 10:43:45 -0500
From: John C Klensin <[email-masked]>
To: Bill McQuillan <[email-masked]>, SMTP Discussion <[email-masked]>
Subject: Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics
Sender: [email-masked]

Absolutely right.  My apologies.  I wonder what aberration of
memory caused me to come up with 1000?

The general reasoning, of course, still stands.

   john

--On Saturday, 01 December, 2007 00:31 -0800 Bill McQuillan
<[email-masked]> wrote:

> 
> 
> On Fri, 2007-11-30, John C Klensin wrote:
> 
>> So, if others agree with my interpretation, I propose to
>> modify the description of 500 quoted above by adding to the
>> end...
> 
>> 		Similarly, producing a "command line too long" message
>> 		for a command line shorter than 1000 characters would
>> 		violate the provisions of Section 4.5.3.1.4.
> 
> My copy of draft-klensin-rfc2821bis-06 would suggest 512
> characters:
> 
> 4.5.3.1.4.  command line
> 
>    The maximum total length of a command line including the
> command word    and the <CRLF> is 512 characters.  SMTP
> extensions may be used to    increase this limit.

Date: Sat, 1 Dec 2007 00:31:24 -0800
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: rfc2821 New Issue: Section 4.3.2, the "anywhere" codes, and related topics
Sender: [email-masked]

On Fri, 2007-11-30, John C Klensin wrote:

> So, if others agree with my interpretation, I propose to modify
> the description of 500 quoted above by adding to the end...

> 		Similarly, producing a "command line too long" message
> 		for a command line shorter than 1000 characters would
> 		violate the provisions of Section 4.5.3.1.4.

My copy of draft-klensin-rfc2821bis-06 would suggest 512 characters:

4.5.3.1.4.  command line

   The maximum total length of a command line including the command word
   and the <CRLF> is 512 characters.  SMTP extensions may be used to
   increase this limit.

-- 
Bill McQuillan <[email-masked]>