Subject: Re: draft-murchison-lmtp-ignorequota-01
From: Chris Newman <[email-masked]>
To: [email-masked], [email-masked]
Cc: Ken Murchison <[email-masked]>, SMTP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Date: Fri, 31 Aug 2001 11:35:30 -0700
List-Id: <ietf-smtp.imc.org>

--On Friday, August 31, 2001 13:07 -0400 [email-masked] wrote:
> No problem - can whoever ends up doing the RFC make sure to include
> that in the 'Security Considerations' section (or maybe even go so far as
> to only allow passing LDAP key/value pairs if other means have been used
> to authenticate the submitter)?

Of course.  That's why we have security considerations section.

> Ned knows how to use the building blocks, Chris knows how, Larry knows
> how, people keep claiming I know how - but I can think of a number of
> vendors that *will* get it wrong unless they're specifically told "Here,
> use one of these 3 blocks - don't use the green ones though, they need
> purple ones too to make them fit..."

Unfortunately, the people who tend to get it wrong tend to be the same 
people who don't read the security considerations section.  While I 
definitely support good security consideration sections describing fairly 
concrete scenarios, we can't go so far as to explain how to build a secure 
computer system in every RFC.

		- Chris

To: [email-masked]
cc: Chris Newman <[email-masked]>, Ken Murchison <[email-masked]>, SMTP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01 
From: [email-masked]
Date: Fri, 31 Aug 2001 13:07:32 -0400
Sender: [email-masked]

On Fri, 31 Aug 2001 09:15:17 PDT, [email-masked] said:
> > And the mail store should trust these values why?
> 
> Because there's a trust relationship between the mail store and the transfer
> agent, brought about by some sort of explicit configuration. The transfer agent
> may be identifiable as such in a variety of ways: SASL authentication,
> physically secure link, VPN, etc.

No problem - can whoever ends up doing the RFC make sure to include
that in the 'Security Considerations' section (or maybe even go so far as
to only allow passing LDAP key/value pairs if other means have been used to
authenticate the submitter)?

SASL is pretty well understood - I'd have no problem with "if the other
end SASL-authenticated that they're the MTA, believe their LDAP".  On the other
hand, I've seen more than one case where people used crypto boxes at both
ends of a leased line to run a secure PPP link - but one end or the other
was also on a subnet, did not do per-interface filtering of packets, and
was subject to TCP seq num prediction attacks...

Similar comments apply to most VPN handwaving - there's good VPN products,
and they're crappy ones.

Ned knows how to use the building blocks, Chris knows how, Larry knows how,
people keep claiming I know how - but I can think of a number of vendors
that *will* get it wrong unless they're specifically told "Here, use one of
these 3 blocks - don't use the green ones though, they need purple ones too
to make them fit..."

> This sort of thing is done all the time and works quite well.

This sort of things is done all the time and written about on Bugtraq too ;)

> Hardly. We have all the tools necessary to do such things securely and without
> them becoming invitations to passing bad data around. The real risk here is
> stale data, not bad data.

Yes, as long as the tools are correctly used.  If they're not used, or used
incorrectly, bad data is a danger.

/Valdis

Date: Fri, 31 Aug 2001 09:15:17 -0700 (PDT)
From: [email-masked]
Subject: Re: draft-murchison-lmtp-ignorequota-01
To: [email-masked]
Cc: Chris Newman <[email-masked]>, Ken Murchison <[email-masked]>, SMTP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

> On Thu, 30 Aug 2001 15:24:19 PDT, Chris Newman said:
> > RCPT TO:<[email-masked]> LDAP=attr:value:attr:value,value:attr:value

> And the mail store should trust these values why?

Because there's a trust relationship between the mail store and the transfer
agent, brought about by some sort of explicit configuration. The transfer agent
may be identifiable as such in a variety of ways: SASL authentication,
physically secure link, VPN, etc.

This sort of thing is done all the time and works quite well.

> Even though LTMP is a *local* protocol, this is still inviting to be passed
> bad data.  If the message store asks the LDAP server itself, it can at
> least use whatever security LDAP has to verify that it's talking to the LDAP
> server, and at the very least, it knows that it's being given answers to
> queries IT asked.

Hardly. We have all the tools necessary to do such things securely and without
them becoming invitations to passing bad data around. The real risk here is
stale data, not bad data.

				Ned

To: Chris Newman <[email-masked]>
cc: Ken Murchison <[email-masked]>, SMTP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01 
From: [email-masked]
Date: Thu, 30 Aug 2001 22:48:28 -0400
Sender: [email-masked]

On Thu, 30 Aug 2001 15:24:19 PDT, Chris Newman said:
> RCPT TO:<[email-masked]> LDAP=attr:value:attr:value,value:attr:value

And the mail store should trust these values why?

Even though LTMP is a *local* protocol, this is still inviting to be passed
bad data.  If the message store asks the LDAP server itself, it can at
least use whatever security LDAP has to verify that it's talking to the LDAP
server, and at the very least, it knows that it's being given answers to
queries IT asked.

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Date: Thu, 30 Aug 2001 19:01:24 -0700
From: Chris Newman <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
To: Ken Murchison <[email-masked]>
Cc: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

--On Thursday, August 30, 2001 21:05 -0400 Ken Murchison <[email-masked]> 
wrote:
> Interesting, but since neither I nor Cyrus IMAP need this right now,
> I'll defer to you on this one.  Unless you think that these "deliver
> options" mechanisms belong in the same draft.

My instinct is they don't belong in the same draft since the scoping of the 
attributes is different.  The "FLAGS" have globally standard meaning, while 
the meaning of LDAP attributes tend to be somewhat site-dependent and/or 
product-dependent.  But I thought I'd raise the issue in case someone else 
felt they should be combined.

		- Chris

Date: Thu, 30 Aug 2001 21:05:33 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Chris Newman <[email-masked]>
CC: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
Sender: [email-masked]

Chris Newman wrote:
> 
> --On Thursday, August 30, 2001 17:42 -0400 Ken Murchison <[email-masked]>
> wrote:
> > I *think* Larry and I had discussed somthing like this before
> > implementing IGNOREQUOTA.  Are you proposing something like an
> > extensible FLAGS keyword, ie:
> >
> > RCPT TO:<[email-masked]> FLAGS=qa
> >
> > where:
> >
> > q = no quota check
> > a = no acl check
> >
> > I figure that using single-letter flags would be better than keywords,
> > since it would keep the max length of the RCPT command down to a
> > manageable level.
> >
> > Thoughts?
> 
> Yes, I like the FLAGS proposal better.  We might want to have the LMTP
> server ignore unknown letters to make it simpler to extend later.

Right.  I was thinking the same thing.

Should we limit the flags in any way (ie alpha-numeric, uppercase-only)
or allow any printable char?

Should we setup a registry at IANA for the flags?

If I write up a draft, should it document just the flags mechanisms, or
should it also mention the 'q' and 'a' flags?

> Another extension I've been thinking of along these lines is one to pass
> attribute-value pairs from LDAP.  Contemplate this scenario:
> 
>                                              +--------+
>                                            ->|  LDAP  |<-
>                                           /  +--------+  \
>                                          /                \
>                                         /                  \
>                                        /                    \
>                                       /                      \
>                     +---------------------+             +-----------+
> incoming mail --->  | SMTP relay for site |---LMTP----->| mailstore |
>                     +---------------------+             +-----------+
> 
> Now since the SMTP relay has to do an LDAP lookup for each recipient to
> find the right backend mailstore, wouldn't it be cool if the SMTP relay
> also passed along all the LDAP attributes the mailstore needed so the
> mailstore didn't have to look up the recipient in LDAP again?
> 
> Seems like saving one network round trip per recipient in this scenario
> might be worth the extra complexity needed to pass freeform LDAP-style
> attribute value-list pairs.
> 
> So perhaps something like:
> 
> RCPT TO:<[email-masked]> LDAP=attr:value:attr:value,value:attr:value

Interesting, but since neither I nor Cyrus IMAP need this right now,
I'll defer to you on this one.  Unless you think that these "deliver
options" mechanisms belong in the same draft.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Aug 2001 15:24:19 -0700
From: Chris Newman <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
To: Ken Murchison <[email-masked]>
Cc: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

--On Thursday, August 30, 2001 17:42 -0400 Ken Murchison <[email-masked]> 
wrote:
> I *think* Larry and I had discussed somthing like this before
> implementing IGNOREQUOTA.  Are you proposing something like an
> extensible FLAGS keyword, ie:
>
> RCPT TO:<[email-masked]> FLAGS=qa
>
> where:
>
> q = no quota check
> a = no acl check
>
> I figure that using single-letter flags would be better than keywords,
> since it would keep the max length of the RCPT command down to a
> manageable level.
>
> Thoughts?

Yes, I like the FLAGS proposal better.  We might want to have the LMTP 
server ignore unknown letters to make it simpler to extend later.

Another extension I've been thinking of along these lines is one to pass 
attribute-value pairs from LDAP.  Contemplate this scenario:

                                             +--------+
                                           ->|  LDAP  |<-
                                          /  +--------+  \
                                         /                \
                                        /                  \
                                       /                    \
                                      /                      \
                    +---------------------+             +-----------+
incoming mail --->  | SMTP relay for site |---LMTP----->| mailstore |
                    +---------------------+             +-----------+

Now since the SMTP relay has to do an LDAP lookup for each recipient to 
find the right backend mailstore, wouldn't it be cool if the SMTP relay 
also passed along all the LDAP attributes the mailstore needed so the 
mailstore didn't have to look up the recipient in LDAP again?

Seems like saving one network round trip per recipient in this scenario 
might be worth the extra complexity needed to pass freeform LDAP-style 
attribute value-list pairs.

So perhaps something like:

RCPT TO:<[email-masked]> LDAP=attr:value:attr:value,value:attr:value

		- Chris

Date: Thu, 30 Aug 2001 17:42:43 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Chris Newman <[email-masked]>
CC: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
Sender: [email-masked]

Chris,

I *think* Larry and I had discussed somthing like this before
implementing IGNOREQUOTA.  Are you proposing something like an
extensible FLAGS keyword, ie:

RCPT TO:<[email-masked]> FLAGS=qa

where: 

q = no quota check
a = no acl check

I figure that using single-letter flags would be better than keywords,
since it would keep the max length of the RCPT command down to a
manageable level.

Thoughts?

Ken

Chris Newman wrote:
> 
> This is a special case of a general problem.
> 
> We do quota override for messages from a voicemail gateway, so it certainly
> has value.
> 
> But it would also be nice to have other "delivery flags" passed along.  We
> have a delivery flag which indicates the subaddress came from a sieve
> script, so the ACL check on subfolder delivery is suppressed.
> 
>                 - Chris
> 
> --On Thursday, August 30, 2001 10:59 -0400 Ken Murchison <[email-masked]>
> wrote:
> 
> > I just submitted the following draft update:
> >
> > http://www.oceana.com/ftp/drafts/draft-murchison-lmtp-ignorequota-01.txt
> >
> > All feedback is welcome.  FYI, this extension has been implemented in
> > Cyrus IMAP since v2.0.11.
> >
> > Regards,
> > Ken
> > --
> > Kenneth Murchison     Oceana Matrix Ltd.
> > Software Engineer     21 Princeton Place
> > 716-662-8973 x26      Orchard Park, NY 14127
> > --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Aug 2001 12:33:14 -0700
From: Chris Newman <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
To: Ken Murchison <[email-masked]>, SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>
Cc: Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

This is a special case of a general problem.

We do quota override for messages from a voicemail gateway, so it certainly 
has value.

But it would also be nice to have other "delivery flags" passed along.  We 
have a delivery flag which indicates the subaddress came from a sieve 
script, so the ACL check on subfolder delivery is suppressed.

		- Chris

--On Thursday, August 30, 2001 10:59 -0400 Ken Murchison <[email-masked]> 
wrote:

> I just submitted the following draft update:
>
> http://www.oceana.com/ftp/drafts/draft-murchison-lmtp-ignorequota-01.txt
>
> All feedback is welcome.  FYI, this extension has been implemented in
> Cyrus IMAP since v2.0.11.
>
> Regards,
> Ken
> --
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: Ken Murchison <[email-masked]>
cc: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01 
From: [email-masked]
Date: Thu, 30 Aug 2001 13:37:18 -0400
Sender: [email-masked]

On Thu, 30 Aug 2001 12:34:52 EDT, Ken Murchison said:
> > What this really is is just a hack to get the "you're over quota, clean
> > your inbox" messaging into the mailbox, isn't it?
> 
> It could be used for this purpose, but that is not its sole purpose. 
> This can be used by an admin who wants to guarantee delivery of an
> important message regardless of the state of the quota.

"over quota" doesn't do it for me as a purpose.  However, "dont bounce
this msg due to quota" *does* do it for me... ;)

(Now to go and read the draft and look for authentication/authorization
issues ;)

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Date: Thu, 30 Aug 2001 12:34:52 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Lyndon Nerenberg <[email-masked]>
CC: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01
Sender: [email-masked]

Lyndon Nerenberg wrote:
> 
> What this really is is just a hack to get the "you're over quota, clean
> your inbox" messaging into the mailbox, isn't it?

It could be used for this purpose, but that is not its sole purpose. 
This can be used by an admin who wants to guarantee delivery of an
important message regardless of the state of the quota.

> That *definately*
> doesn't belong in LMTP. Instead, have the IMAP server generate obnoxious
> [ALERT] responses until the user gets back under quota.

I agree that this is how users _should_ be notified about quota
problems.

If it turns out that nobody wants to see this extension move forward,
then we'll kill the draft and just make this a private extension in
Cyrus.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Organization: ACI Worldwide - Advanced Technology Group
To: Ken Murchison <[email-masked]>
cc: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: draft-murchison-lmtp-ignorequota-01 
Date: Thu, 30 Aug 2001 09:43:25 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

What this really is is just a hack to get the "you're over quota, clean
your inbox" messaging into the mailbox, isn't it? That *definately*
doesn't belong in LMTP. Instead, have the IMAP server generate obnoxious
[ALERT] responses until the user gets back under quota.

--lyndon

Date: Thu, 30 Aug 2001 11:00:42 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Koti <[email-masked]>
CC: [email-masked]
Subject: Re: I want to know all RFCs related SMTP issuses.
Sender: [email-masked]

Take a look at: 

http://www.imc.org/rfcs.html#hosttohost

Koti wrote:
> 
> Hi,
> 
> I want to know all RFCs related SMTP issuses.
> I now only RFC 821 written in 1982, I believe
> there are some revised RFCs are there for SMTP.
> And there might be some RFCs on specific topics
> like authentication, Could you please mail me the
> RFCs  regarding SMTP? ( Just RFC number - main issue of the RFC)
> 
> Thanks,
> - Koteswara Rao
> Ph: 040 6513274 Extn: 8842
> JUNO online services Dev Pvt Ltd.
> GPR building, Begumpet,
> Hyderabad, India
> ----------------------------------------------------------------
> When one door of happiness closes, another opens; but often we look so long
> at the closed door
> that we do not see the one, which has opened for us. - Hellen Keller.
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Aug 2001 10:59:00 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: SMTP mailing list <[email-masked]>, IMAP mailing list <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>
Subject: draft-murchison-lmtp-ignorequota-01
Sender: [email-masked]

I just submitted the following draft update:

http://www.oceana.com/ftp/drafts/draft-murchison-lmtp-ignorequota-01.txt

All feedback is welcome.  FYI, this extension has been implemented in
Cyrus IMAP since v2.0.11.

Regards,
Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Thu, 30 Aug 2001 10:57:47 +0300
Subject: RE:I want to know all RFCs related SMTP issuses.
From: "Levent Serinol"<[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

please check www.ietf.org. There you can obtain rfc index.

P.S. new version of rfc821 is rfc2821

> Hi,
> 
> I want to know all RFCs related SMTP issuses.
> I now only RFC 821 written in 1982, I believe
> there are some revised RFCs are there for SMTP.
> And there might be some RFCs on specific topics
> like authentication, Could you please mail me the
> RFCs  regarding SMTP? ( Just RFC number - main issue of the RFC)
> 
> Thanks,
> - Koteswara Rao
> Ph: 040 6513274 Extn: 8842
> JUNO online services Dev Pvt Ltd.
> GPR building, Begumpet,
> Hyderabad, India
> ----------------------------------------------------------------
> When one door of happiness closes, another opens; but often we look
so long
> at the closed door
> that we do not see the one, which has opened for us. - Hellen
Keller.
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 

#exclude <windows.h>

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: I want to know all RFCs related SMTP issuses.
Date: Thu, 30 Aug 2001 12:28:14 +0530
Sender: [email-masked]

Hi,

I want to know all RFCs related SMTP issuses.
I now only RFC 821 written in 1982, I believe
there are some revised RFCs are there for SMTP.
And there might be some RFCs on specific topics
like authentication, Could you please mail me the
RFCs  regarding SMTP? ( Just RFC number - main issue of the RFC)

Thanks,
- Koteswara Rao
Ph: 040 6513274 Extn: 8842
JUNO online services Dev Pvt Ltd.
GPR building, Begumpet,
Hyderabad, India
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so long
at the closed door
that we do not see the one, which has opened for us. - Hellen Keller.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Date: Sun, 12 Aug 2001 19:17:53 +0200
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Keith Moore <[email-masked]>, Chip Rosenthal <[email-masked]>
cc: [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Sender: [email-masked]

--On 08/11/2001 11:11 AM -0400 Keith Moore <[email-masked]> wrote:

> perhaps instead of asterisks, the banner should be replaced with 
> 
> 220-This SMTP session is being munged by a cisco firewall that is
> 220-installed at x.y.z.  If something breaks, the problem is likely
> 220-to be in the firewall, rather than your mail client or the server.
> 220-If you don't like this, contact our marketing department
> 220-and they'll explain to you that things are really supposed to be
> 220-this way.  Of course they're all lying bastards, but it's easier
> 220 to believe them than it is to stop selling buggy products.

With my cisco hat on:

- I know of historically three issues with the PIX:
  1 The greeting message
  2 (Proper) ESMTP handling
  3 Problem with terminating '.' in the data command when the bytes
    CR,LF,.,CR,LF ends up across a packet boundary

Number 3 is fixed in a release of the software released in june. People
should definitly upgrade. Fixed releases are 5.3(2) and 6.0(1).

Number 1 and 2 are still on my list...

I'll keep you updated, and I am happy if all of you (privately) keep me
updated on your experiences. I know you are unhappy, I am unhappy myself,
but people writing the code seems to now be able to "do the right thing".

So regardless of how bad you feel, if you have time to write down what you
have found, send it to me personally.

   paf

Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

From: Keith Moore <[email-masked]>
To: Chip Rosenthal <[email-masked]>
cc: [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Date: Sat, 11 Aug 2001 11:11:53 -0400
Sender: [email-masked]

perhaps instead of asterisks, the banner should be replaced with 

220-This SMTP session is being munged by a cisco firewall that is
220-installed at x.y.z.  If something breaks, the problem is likely
220-to be in the firewall, rather than your mail client or the server.
220-If you don't like this, contact our marketing department
220-and they'll explain to you that things are really supposed to be
220-this way.  Of course they're all lying bastards, but it's easier
220 to believe them than it is to stop selling buggy products.

Date: Sat, 11 Aug 2001 00:54:21 -0500
From: Chip Rosenthal <[email-masked]>
To: [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

[apologies in advance for the rant]

On Fri, Aug 10, 2001 at 10:37:48PM -0400, [email-masked] wrote:
> Yes, it's that bad, and yes, Keith is justified. ;)

It's worse than bad.  It's evil and stupid.

If the host is a public mail server then the banner provides useful
information.  Munging the banner is a bug, not a feature.  If I want
to tailor the banner, then I will configure my mail system to do so.

If the host is not a public mail server, then the service should be
blocked entirely, not munged.

This obfuscation, therefore, serves no valuable purpose and its use
can only be a detriment.

The chip on my shoulder is because I had to do mail system debugging
across a Cisco PIX inserted by a network manager who refused to believe
his network could be messing with the SMTP session I was trying to
analyze.

-- 
Chip Rosenthal              Now we buy spam at the grocery store,
http://www.unicom.com/      cause you can't eat the fish no more.
<[email-masked]>             - Little Village

To: Paul Smith <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
From: [email-masked]
Date: Fri, 10 Aug 2001 22:37:48 -0400
Sender: [email-masked]

On Fri, 10 Aug 2001 22:31:36 BST, Paul Smith said:
> At 12:40 10/08/2001 -0400, Keith Moore wrote:
> >there's a popular SMTP firewall that puts asterisks in the initial
> >(220) SMTP greeeting.  I'd like to know who makes it.
> >
> >because the developers should be lined up and shot.
> Why? What's wrong with asterisks in the greeting? (it's not us, by the way, 
> I'm just interested in why that's a problem)

The asterisks aren't a problem.  The asterisks however are the banner for
a totally borked SMTP server.  I've caught these critters doing the MOST
astounding things.  For starters, I think they *STILL* are unable to
advertise ESMTP.  That's OK, because even if they don't advertise ESMTP,
and as a result you don't send an EHLO, and don't send an 8bitmime
encoding, it will STILL bounce the mail for having an illegal 8bitmime
attachment sometimes.  For all the heat that Exchange has taken
recently on the IETF list, it's a paragon of goodness and careful
design compared to this creeping-horror monstrosity.

I was once debugging a mail problem with a co-worker, and we poked
the problem hosts's port 25, saw all the asterisks, and basically
gave up.  My co-worker had some descriptive phrases for the product
that involved anatomicaly unlikely interactions with a beast of burden.
I didn't see any need to correct his assessment....

Yes, it's that bad, and yes, Keith is justified. ;)

/Valdis

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: [email-masked], "Paul Smith" <[email-masked]>, [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 20:36:07 -0400
Sender: [email-masked]

I suppose I could see that happening in the DATA phase.  But
for the cases that I've seen recently, it's always been with
some command that has a short response.  in such cases neither 
the payload nor the response should be big enough to require 
fragmentation.

Keith

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Cc: "Paul Smith" <[email-masked]>, <[email-masked]>
Subject: RE: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 17:29:42 -0700
Importance: Normal
Sender: [email-masked]

> > PMTU probing?
> 
> why should PMTU probing take several minutes?  especially between a 
> firewall and the SMTP server inside the firewall, on an already-
> established connection?

Unless the firewall is busy handling Code Red analysis -- which is
pretty likely right now, by the way -- this was the only thing that
comes to mind as something I have seen take awhile.  If ICMP 'must
fragment' messages are being dropped, the TCP stack has to decide
its dealing with a broken network and start experimenting with 
smaller packets.

-d

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: [email-masked], "Paul Smith" <[email-masked]>, [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 20:26:25 -0400
Sender: [email-masked]

> PMTU probing?

why should PMTU probing take several minutes?  especially between a 
firewall and the SMTP server inside the firewall, on an already-
established connection?

Keith

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Cc: "Paul Smith" <[email-masked]>, <[email-masked]>
Subject: RE: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 17:19:28 -0700
Importance: Normal
Sender: [email-masked]

> > "timely" meaning greater than 2-10 minutes mandated by RFC2821, or
> > "timely" meaning less than a second like a normal SMTP server?
> 
> closer to the former.

PMTU probing?

-d

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: [email-masked], "Paul Smith" <[email-masked]>, [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 20:03:40 -0400
Sender: [email-masked]

> > actually, a greeting line consisting entirely of asterisks isn't legal -
> > the greeting line is supposed to contain the hostname of the SMTP server.
> > but that's not what I was complaining about.
> 
> True, but is this lack of hostname causing interop problems (worthy of
> being shot, as you mentioned)?

as far as I know, that's not causing interop problems.
 
> > basically I've noticed that such firewalls, for some reason, tend to
> > confuse SMTP servers to the extent that they don't always respond to
> > commands in a timely fashion.
> 
> "timely" meaning greater than 2-10 minutes mandated by RFC2821, or
> "timely" meaning less than a second like a normal SMTP server?

closer to the former.

Keith

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Cc: "Paul Smith" <[email-masked]>, <[email-masked]>
Subject: RE: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 16:40:28 -0700
Importance: Normal
Sender: [email-masked]

> actually, a greeting line consisting entirely of asterisks isn't legal -
> the greeting line is supposed to contain the hostname of the SMTP server.
> but that's not what I was complaining about.

True, but is this lack of hostname causing interop problems (worthy of
being shot, as you mentioned)?

> basically I've noticed that such firewalls, for some reason, tend to 
> confuse SMTP servers to the extent that they don't always respond to 
> commands in a timely fashion.

"timely" meaning greater than 2-10 minutes mandated by RFC2821, or
"timely" meaning less than a second like a normal SMTP server?

-d

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Paul Smith" <[email-masked]>, "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting? 
Date: Fri, 10 Aug 2001 19:24:00 -0400
Sender: [email-masked]

> > >there's a popular SMTP firewall that puts asterisks in the initial
> > >(220) SMTP greeeting.  I'd like to know who makes it.
> > >
> > >because the developers should be lined up and shot.
> > 
> > Why? What's wrong with asterisks in the greeting? (it's not us, by the way,
> > I'm just interested in why that's a problem)
> 
> Asterisks are legal.  I'm sure there is something else the firewall is
> doing wrong that caught Keith's attention, and the only identifying element
> is the asterisks.

actually, a greeting line consisting entirely of asterisks isn't legal -
the greeting line is supposed to contain the hostname of the SMTP server.
but that's not what I was complaining about.

basically I've noticed that such firewalls, for some reason, tend to 
confuse SMTP servers to the extent that they don't always respond to 
commands in a timely fashion.

Keith

From: "Dan Wing" <[email-masked]>
To: "Paul Smith" <[email-masked]>, "Keith Moore" <[email-masked]>, <[email-masked]>
Subject: RE: who makes the firewall that puts asterisks in the initial greeting?
Date: Fri, 10 Aug 2001 15:10:49 -0700
Importance: Normal
Sender: [email-masked]

> >there's a popular SMTP firewall that puts asterisks in the initial
> >(220) SMTP greeeting.  I'd like to know who makes it.
> >
> >because the developers should be lined up and shot.
> 
> Why? What's wrong with asterisks in the greeting? (it's not us, by the way, 
> I'm just interested in why that's a problem)

Asterisks are legal.  I'm sure there is something else the firewall is
doing wrong that caught Keith's attention, and the only identifying element
is the asterisks.

-d

Date: Fri, 10 Aug 2001 22:31:36 +0100
To: Keith Moore <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: who makes the firewall that puts asterisks in the initial greeting?
Cc: [email-masked]
Sender: [email-masked]

At 12:40 10/08/2001 -0400, Keith Moore wrote:

>there's a popular SMTP firewall that puts asterisks in the initial
>(220) SMTP greeeting.  I'd like to know who makes it.
>
>because the developers should be lined up and shot.

Why? What's wrong with asterisks in the greeting? (it's not us, by the way, 
I'm just interested in why that's a problem)

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

Date: Fri, 10 Aug 2001 14:08:48 -0700
From: Gregory Neil Shapiro <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: who makes the firewall that puts asterisks in the initial greeting?
Sender: [email-masked]

moore> there's a popular SMTP firewall that puts asterisks in the initial
moore> (220) SMTP greeeting.  I'd like to know who makes it.

Cisco.

To: [email-masked]
Subject: who makes the firewall that puts asterisks in the initial greeting?
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Fri, 10 Aug 2001 12:40:17 -0400
Sender: [email-masked]

there's a popular SMTP firewall that puts asterisks in the initial
(220) SMTP greeeting.  I'd like to know who makes it.

because the developers should be lined up and shot.

Date: Mon, 6 Aug 2001 14:47:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Digital Gap. (was Re: Resume command for ESMTP? )
Sender: [email-masked]

[email-masked]
> What do you mean by "fix the TCP infrastructure"? If you are talking about
> fixing some problems on the TCP stack of protocols, you may be write, I do not
> know enough to now it. But, If you wanted to say "fix your telecommunication
> infrastructure", which you may meant, then I must say that imho that is not the
> way IETF should work.
>
> There is a tremendous difference between "our first world" and the "other's
> world". With the "society of information" that we are creating, the difference
> is being increased and we aren't doing anything, not to close the digital gap,
> but even to try to stop a little bit it's growth.
>
> I think that IETF's role is to develop protocols to make the "net" more
> UNIVERSAL for all of us, not only for the ones that have money, and fiber optics
> at the basement, but for every single human being on the planet. The answer
> Valdis is giving to the problem is: "get better connections and pay for the
> bandwidth". My question to it is: "Who is going to connect with fiber optic
> submarine cable the 1000 islands that Indonesia is made of?"

Do you actually know that the Indonesians have significant problems with
IP/TCP/SMTP? If so, are these problems in the domain of IP, in the domain
of TCP, or in the domain of SMTP?

If you don't know, you should sit down and figure out what the problem is.

RFCs 2488, 3002 and others talk about extremely slow or error-prone
networks and may be of interest to you.

--Arnt

From: [email-masked]
To: [email-masked]
Date: Mon, 6 Aug 2001 10:29:36 +0200
Subject: Digital Gap. (was Re: Resume command for ESMTP? )
Sender: [email-masked]

> Am taking further followups to [email-masked] where it belongs...

I agree that follow-ups on the topic belong to smtp lists, but I think that in
those messages you were talking about two issues, one of which it belongs in the
ietf list. (At least I see it that way).

>> So What do you think? Anybody that support the idea and want to develop it
>> further?
>
>Well.. I still think that the *proper* solution is to fix the TCP
infrastructure
>so that there isn't a NEED for a RESUME....

What do you mean by "fix the TCP infrastructure"? If you are talking about
fixing some problems on the TCP stack of protocols, you may be write, I do not
know enough to now it. But, If you wanted to say "fix your telecommunication
infrastructure", which you may meant, then I must say that imho that is not the
way IETF should work.

There is a tremendous difference between "our first world" and the "other's
world". With the "society of information" that we are creating, the difference
is being increased and we aren't doing anything, not to close the digital gap,
but even to try to stop a little bit it's growth.

I think that IETF's role is to develop protocols to make the "net" more
UNIVERSAL for all of us, not only for the ones that have money, and fiber optics
at the basement, but for every single human being on the planet. The answer
Valdis is giving to the problem is: "get better connections and pay for the
bandwidth". My question to it is: "Who is going to connect with fiber optic
submarine cable the 1000 islands that Indonesia is made of?"

Are the big corporations going to spend the money on developing the
communication networks at Africa, Asia South America and the pacific region (4/5
of the world's population) when there is no business plan to make it profitable?

Are the governments on this areas going to invest on this, when they do not have
stability, public health or education problems (and so on...) solved?

The way I read the request is: "Keep SMTP the way it is, if it works for many of
you; but lets develop a SMTP "enhance" that has "RESUME" feature for the ones
that need it." There would be SMTP servers and SMTP+ servers, both interoperable
and probably we would be helping a lot to those that really need it.

Regards,
Joaquin Rivera.

To: Franck Martin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Resume command for ESMTP? 
From: [email-masked]
Date: Sun, 05 Aug 2001 20:09:52 -0400
Sender: [email-masked]

--==_Exmh_-791313159P
Content-Type: text/plain; charset=us-ascii

Am taking further followups to [email-masked] where it belongs...

On Mon, 06 Aug 2001 10:11:33 +1200, Franck Martin said:
> The first principle, is not to store a mail part indifinitively, but to
> timeout it in the queue. The parameter should be left configurable. Let's
> say that the mail sender has 5mn to resume the session or it has to start
> from the beginning again. This would allow that the queue doesn't grow out
> of proportion because of errors.

Is there any evidence that it is common enough to have a network outage severe
enough that the TCP connection gets broken, but that within 5 minutes it's
resumable?

> The second principle, is that most servers do a content analysis based on
> the line received. The mail server, needs to know where it is in the
> session. Are we still in the headers or already in the content? Based on
> content anylysis of the mail being received the server may send an error
> back, like "Error content rejected", "Malformed error", "Message to big".
> The server trash the message and clear the session. This would take care of
> the sircam virus, like on my system where I block attachments with .exe or
> .lnk extensions. This is done easily on the fly while receiving the e-mails.
> Here the e-mail does not need to be fully received but as soon as a
> condition is met the session is closed.

Closing the session on the fly is *very* anti-standard.  Also, note that if
you close it on the fly, a standard conforming MTA will *retry* it.  Over and
over, as you keep closing the session on the fly.  A much better solution is
to wait until the final '.' is received, and THEN do something interesting.

See RFC2821, section 4.2.5 for details.

> I understand that a mail server with RESUME capability may need a bigger
> queue than one without, but HD space is cheap, and it saves huge amount of
> expensive bandwidth...

The problem is that it may be cheap to say "add another 500M to the spool"
for a *small* system.  However, when you start talking about *large* mail
systems, scaling becomes an important factor.  I spent some time at a recent
Sendmail workshop, and some of the people there were working on systems that
had to do a million deliveries an hour.  At these levels, even saying "just move
it to another queue for later" becomes problematic - it takes a lot of I/O to
sync everything to disk...

And remember - these "big systems" are the ones you're probably having the
trouble talking to.

> So What do you think? Anybody that support the idea and want to develop it
> further?

Well.. I still think that the *proper* solution is to fix the TCP infrastructure
so that there isn't a NEED for a RESUME....

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

--==_Exmh_-791313159P
Content-Type: application/pgp-signature

--==_Exmh_-791313159P--