Remote server causing "SMTP DATA-2 protocol error"

Hi,

We end up sending to alot of domains hosted by
securehostedemail.com. They are usually filters/etc for other
customers. You'll see them as something like
"inbound.hughes.net.cust.securehostedemail.com" when you
send to a hughes.net domain.

Ever since yesterday @ 00:27am Eastern we now seem to get a more
descriptive message, but its also
causing agita for sendmail :

Nov 20 00:27:16 erda sm-mta[89370]: lAK5RElH089368:
inbound.hughes.net.cust.securehostedemail.com.: SMTP DATA-2 protocol
error: 571 Requested action not taken: Message was spam or contained
virus
Nov 20 00:27:16 erda kernel: Nov 20 00:27:16 erda sm-mta[89370]:
lAK5RElH089368: inbound.hughes.net.cust.securehostedemail.com.: SMTP
DATA-2 protocol error: 571 Requested action not taken: Message was
spam or contained virus

Sendmail considers it bad enough that it sends it at critical,
which trips a FreeBSD Kernel Hack to take output to critical/console
and force it AGAIN into syslog.

This, in turn, makes our monitoring system cranky that theres
alot of kernel messages happening.

According to RFC-821, thats not a valid return code, but it
appears in RFC-1893 it is. Does sendmail follow the expanded RFC?

Is there some knob we can tweak to not have it consider it a
"SMTP DATA-2 protocol error"?

Thanks, Tuc

Re: Remote server causing "SMTP DATA-2 protocol error"

In article
<1885fc22-fa67-45b2-bf96-2849616cb79d@d61g2000hsa.googlegroups.com>,
Tuc wrote:

> Hi,
>
> We end up sending to alot of domains hosted by
> securehostedemail.com. They are usually filters/etc for other
> customers. You'll see them as something like
> "inbound.hughes.net.cust.securehostedemail.com" when you
> send to a hughes.net domain.
>
> Ever since yesterday @ 00:27am Eastern we now seem to get a more
> descriptive message, but its also
> causing agita for sendmail :
>
> Nov 20 00:27:16 erda sm-mta[89370]: lAK5RElH089368:
> inbound.hughes.net.cust.securehostedemail.com.: SMTP DATA-2 protocol
> error: 571 Requested action not taken: Message was spam or contained
> virus
> Nov 20 00:27:16 erda kernel: Nov 20 00:27:16 erda sm-mta[89370]:
> lAK5RElH089368: inbound.hughes.net.cust.securehostedemail.com.: SMTP
> DATA-2 protocol error: 571 Requested action not taken: Message was
> spam or contained virus
>
> Sendmail considers it bad enough that it sends it at critical,
> which trips a FreeBSD Kernel Hack to take output to critical/console
> and force it AGAIN into syslog.
>
> This, in turn, makes our monitoring system cranky that theres
> alot of kernel messages happening.

That seems like an unwise configuration.


> According to RFC-821, thats not a valid return code, but it
> appears in RFC-1893 it is. Does sendmail follow the expanded RFC?

You (and maybe the people at "securehostedemail.com") are misreading
RFC1893. The codes defined there are dot-separated and DO NOT equate to
the 3-digit response codes used in SMTP but rather are used in addition
to the 3-digit response code, with the original application being in DSN
messages. The way this should be done in SMTP responses is defined in
RFC2034. Sending a 571 response code is not technically wrong under
RFC821 (which allows for use of new codes based on a theory of their
construction) but that's not really a good idea.

What really makes that response from them Bad and Wrong is that they
have ENHANCEDSTATUSCODES in their EHLO response, but it looks like that
response is not consistent with the ENHANCEDSTATUSCODES extension to
SMTP (i.e. RFC2034)

> Is there some knob we can tweak to not have it consider it a
> "SMTP DATA-2 protocol error"?

1. You could lower the LogLevel setting until you don't see those.
2. You could change your syslog config to not send any mail messages to
the console.
3. You could modify the sendmail source to not generate the problematic
message, either by narrowly excluding goofball response codes and
ENHANCEDSTATUSCODES misimplementation from being considered SMTP
protocol errors or by changing the LogLevel at which they are logged to
some very high level or by reporting SMTP protocol errors at some other
syslog severity.

--
Now where did I hide that website...

Re: Remote server causing "SMTP DATA-2 protocol error"

On Nov 21, 6:45 pm, Bill Cole wrote:
> In article
> <1885fc22-fa67-45b2-bf96-2849616cb...@d61g2000hsa.googlegroups.com>,
> Tuc wrote:
> > Hi,
>
> > We end up sending to alot of domains hosted by
> > securehostedemail.com. They are usually filters/etc for other
> > customers. You'll see them as something like
> > "inbound.hughes.net.cust.securehostedemail.com" when you
> > send to a hughes.net domain.
>
> > Ever since yesterday @ 00:27am Eastern we now seem to get a more
> > descriptive message, but its also
> > causing agita for sendmail :
>
> > Nov 20 00:27:16 erda sm-mta[89370]: lAK5RElH089368:
> > inbound.hughes.net.cust.securehostedemail.com.: SMTP DATA-2 protocol
> > error: 571 Requested action not taken: Message was spam or contained
> > virus
> > Nov 20 00:27:16 erda kernel: Nov 20 00:27:16 erda sm-mta[89370]:
> > lAK5RElH089368: inbound.hughes.net.cust.securehostedemail.com.: SMTP
> > DATA-2 protocol error: 571 Requested action not taken: Message was
> > spam or contained virus
>
> > Sendmail considers it bad enough that it sends it at critical,
> > which trips a FreeBSD Kernel Hack to take output to critical/console
> > and force it AGAIN into syslog.
>
> > This, in turn, makes our monitoring system cranky that theres
> > alot of kernel messages happening.
>
> That seems like an unwise configuration.
>
> > According to RFC-821, thats not a valid return code, but it
> > appears in RFC-1893 it is. Does sendmail follow the expanded RFC?
>
> You (and maybe the people at "securehostedemail.com") are misreading
> RFC1893. The codes defined there are dot-separated and DO NOT equate to
> the 3-digit response codes used in SMTP but rather are used in addition
> to the 3-digit response code, with the original application being in DSN
> messages. The way this should be done in SMTP responses is defined in
> RFC2034. Sending a 571 response code is not technically wrong under
> RFC821 (which allows for use of new codes based on a theory of their
> construction) but that's not really a good idea.
>
> What really makes that response from them Bad and Wrong is that they
> have ENHANCEDSTATUSCODES in their EHLO response, but it looks like that
> response is not consistent with the ENHANCEDSTATUSCODES extension to
> SMTP (i.e. RFC2034)
>
> > Is there some knob we can tweak to not have it consider it a
> > "SMTP DATA-2 protocol error"?
>
> 1. You could lower the LogLevel setting until you don't see those.
> 2. You could change your syslog config to not send any mail messages to
> the console.
> 3. You could modify the sendmail source to not generate the problematic
> message, either by narrowly excluding goofball response codes and
> ENHANCEDSTATUSCODES misimplementation from being considered SMTP
> protocol errors or by changing the LogLevel at which they are logged to
> some very high level or by reporting SMTP protocol errors at some other
> syslog severity.
>
> --
> Now where did I hide that website...

Hi,

Whats an unwise configuration, my setup ? The kernel hack I can't
do anything about, its something that they put in ages ago... Anything
out to console ends up getting pumped back into syslog. My normal
line is :

*.err;kern.debug;auth.notice;mail.crit /dev/console

I'd still like to know REAL VALID (VALID is to me something
REALLY
nasty that needs attention immediately) mail.crit issues. I ran into
sendmail
doing this :

Oct 16 00:00:25 valhalla sm-mta[69206]: l9G40Kf5069206: SYSERR(root):
collect: I
/O error on connection from bd0614db.virtua.com.br,
from= om>
Oct 16 00:00:25 valhalla kernel: Oct 16 00:00:25 valhalla sm-
mta[69206]: l9G40Kf
5069206: SYSERR(root): collect: I/O error on connection from
bd0614db.virtua.com
..br, from=

on another server, and changed my line to :

*.err;kern.debug;auth.notice;mail.crit /dev/ttyv0

not something I'm proud of, but it doesn't pump back to syslog.
I just
wonder what I'm missing. Maybe I'll break it up that mail.crit is the
only thing
I send there.

securehostedemail.com looks like it was Critical Path that sold
out to
Tucows. I've tried reaching both parties, no replies from either. And
yes,
I'm guilty of Googling "SMTP error codes" and quickly scanning the
document to see X.7.1 is valid and thinking it mean X71. Also guilty
of
not reading RFC-821 that allowed for additional code, just that I
didn't
see it there and thought it was the case.

The code in sendmail generating this is in usersmtp.c is :

if (rstat != EX_PROTOCOL)
return rstat;
if (LogLevel > 1)
{
sm_syslog(LOG_CRIT, e->e_id,
"%.100s: SMTP DATA-2 protocol error: %s",
CurHostName,
shortenstring(SmtpReplyBuffer, 403));
}
return rstat;

And rstat is set here just above it :

if (r == 452)
rstat = EX_TEMPFAIL;
else if (REPLYTYPE(r) == 4)
rstat = xstat = EX_TEMPFAIL;
else if (REPLYTYPE(r) == 2)
rstat = xstat = EX_OK;
else if (REPLYCLASS(r) != 5)
rstat = xstat = EX_PROTOCOL;
else if (REPLYTYPE(r) == 5)
rstat = EX_UNAVAILABLE;
else
rstat = EX_PROTOCOL;

Thanks for the tweak suggestions :

1 - Its set to 9, I'd have to go way down to 1.. Not sure total
implications
2 - May do that.
3 - I don't like modifying a program if I don't have to, since I'll
always upgrade it and forget
to put the changes back in. :)

All that being said, does anyone know someone at Critical Path or
Tucows that might
be willing to listen about this?


Thanks, Tuc

Re: Remote server causing "SMTP DATA-2 protocol error"

Tuc wrote:

> According to RFC-821, thats not a valid return code, but it

This might sound pedantic, but I like to mention that RFC-2821 replaced
RFC-821 in April 2001; six years and a half ago.
This won't make any difference for your problem because the return code
is still invalid in RFC-2821, but it might be useful to have a pointer
to the right reference document stored in the archives of this thread.

Regards,

Kees.

--
Kees Theunissen.

Re: Remote server causing "SMTP DATA-2 protocol error"

In article
,
Tuc wrote:

> On Nov 21, 6:45 pm, Bill Cole wrote:
> > In article
> > <1885fc22-fa67-45b2-bf96-2849616cb...@d61g2000hsa.googlegroups.com>,
> > Tuc wrote:
> > > Hi,
> >
> > > We end up sending to alot of domains hosted by
> > > securehostedemail.com. They are usually filters/etc for other
> > > customers. You'll see them as something like
> > > "inbound.hughes.net.cust.securehostedemail.com" when you
> > > send to a hughes.net domain.
> >
> > > Ever since yesterday @ 00:27am Eastern we now seem to get a more
> > > descriptive message, but its also
> > > causing agita for sendmail :
> >
> > > Nov 20 00:27:16 erda sm-mta[89370]: lAK5RElH089368:
> > > inbound.hughes.net.cust.securehostedemail.com.: SMTP DATA-2 protocol
> > > error: 571 Requested action not taken: Message was spam or contained
> > > virus
> > > Nov 20 00:27:16 erda kernel: Nov 20 00:27:16 erda sm-mta[89370]:
> > > lAK5RElH089368: inbound.hughes.net.cust.securehostedemail.com.: SMTP
> > > DATA-2 protocol error: 571 Requested action not taken: Message was
> > > spam or contained virus
> >
> > > Sendmail considers it bad enough that it sends it at critical,
> > > which trips a FreeBSD Kernel Hack to take output to critical/console
> > > and force it AGAIN into syslog.
> >
> > > This, in turn, makes our monitoring system cranky that theres
> > > alot of kernel messages happening.
> >
> > That seems like an unwise configuration.
> >
> > > According to RFC-821, thats not a valid return code, but it
> > > appears in RFC-1893 it is. Does sendmail follow the expanded RFC?
> >
> > You (and maybe the people at "securehostedemail.com") are misreading
> > RFC1893. The codes defined there are dot-separated and DO NOT equate to
> > the 3-digit response codes used in SMTP but rather are used in addition
> > to the 3-digit response code, with the original application being in DSN
> > messages. The way this should be done in SMTP responses is defined in
> > RFC2034. Sending a 571 response code is not technically wrong under
> > RFC821 (which allows for use of new codes based on a theory of their
> > construction) but that's not really a good idea.
> >
> > What really makes that response from them Bad and Wrong is that they
> > have ENHANCEDSTATUSCODES in their EHLO response, but it looks like that
> > response is not consistent with the ENHANCEDSTATUSCODES extension to
> > SMTP (i.e. RFC2034)
> >
> > > Is there some knob we can tweak to not have it consider it a
> > > "SMTP DATA-2 protocol error"?
> >
> > 1. You could lower the LogLevel setting until you don't see those.
> > 2. You could change your syslog config to not send any mail messages to
> > the console.
> > 3. You could modify the sendmail source to not generate the problematic
> > message, either by narrowly excluding goofball response codes and
> > ENHANCEDSTATUSCODES misimplementation from being considered SMTP
> > protocol errors or by changing the LogLevel at which they are logged to
> > some very high level or by reporting SMTP protocol errors at some other
> > syslog severity.
>
>
> Hi,
>
> Whats an unwise configuration, my setup ? The kernel hack I can't
> do anything about, its something that they put in ages ago...

I made the comment in its context: that kernel hack strikes me as a very
bad idea on principle, and it surely should be taken into account when
deciding how you log things out of syslog.


> Anything
> out to console ends up getting pumped back into syslog. My normal
> line is :
>
> *.err;kern.debug;auth.notice;mail.crit /dev/console
>
> I'd still like to know REAL VALID (VALID is to me something
> REALLY
> nasty that needs attention immediately) mail.crit issues. I ran into
> sendmail
> doing this :
>
> Oct 16 00:00:25 valhalla sm-mta[69206]: l9G40Kf5069206: SYSERR(root):
> collect: I
> /O error on connection from bd0614db.virtua.com.br,
> from= > om>
> Oct 16 00:00:25 valhalla kernel: Oct 16 00:00:25 valhalla sm-
> mta[69206]: l9G40Kf
> 5069206: SYSERR(root): collect: I/O error on connection from
> bd0614db.virtua.com
> .br, from=

Which is NOT critical for the mail system itself. That's a zombie spam
source dropping offline unceremoniously. One could only hope that it's a
user waking up to the fact that his machine is owned and doing the right
thing (i.e. pulling the plug.) It is critical for that SMTP session, but
it does not indicate a problem for the mail system as a whole. Sendmail
log messages generally follow that pattern, and in the modern world that
is almost certain to mean that you are not going to care about most
mail.crit messages because they are only critical in the context of an
individual message.

Sendmail feeding standard syslog is not going to provide you a clean set
of system-critical messages. You have to filter the mail.crit (and
probably mail.error) messages in a more specific way to really get
everything that needs attention and nothing that doesn't.


> on another server, and changed my line to :
>
> *.err;kern.debug;auth.notice;mail.crit /dev/ttyv0
>
> not something I'm proud of, but it doesn't pump back to syslog.
> I just
> wonder what I'm missing. Maybe I'll break it up that mail.crit is the
> only thing
> I send there.

This is really a more complex system administration question, given that
you're wedded to having the kernel recycle console messages into syslog.
Depending on what your consoles actually are, it might make sense to not
have syslog itself send ANYTHING to the console, but rather to drop
those messages into a distinct file. It seems to me like the kernel hack
only makes any sense if you have messages going to the console that are
not coming through syslog and so cannot be directed to somewhere more
useful easily. The default syslog config for most systems is an antique
thing, a view into 1990 or so. You probably should think out what you're
actually doing with console messages with an understanding of the
advantages that *might* exist in your environment for the console over a
disk file:

1. Maybe your console(s) feed into some external monitoring system. That
could even be a wall of serial terminals with an operator half-looking
at them. In that case, you'll want to feed the console anything that
your console monitoring system needs to respond to.

2. A console message cannot be edited later. This means that it is a
good place to send messages that an attacker might want to scrub from
disk logs.

3. The console interface is usually the most robust output a system has,
being invulnerable to failures that will cause failures in sending
messages to disk, network, and even pseudo-terminal targets.

Historically, sendmail was a significant attack route and
message-critical errors were unusual enough that they were often worth
chasing down, particularly since the Sendmail monoculture in real mail
servers meant that Sendmail could understand the behavior of nearly
every other real SMTP client or server it talked to.

> securehostedemail.com looks like it was Critical Path that sold
> out to
> Tucows. I've tried reaching both parties, no replies from either. And
> yes,
> I'm guilty of Googling "SMTP error codes" and quickly scanning the
> document to see X.7.1 is valid and thinking it mean X71. Also guilty
> of
> not reading RFC-821 that allowed for additional code, just that I
> didn't
> see it there and thought it was the case.
>
> The code in sendmail generating this is in usersmtp.c is :
>
> if (rstat != EX_PROTOCOL)
> return rstat;
> if (LogLevel > 1)
> {
> sm_syslog(LOG_CRIT, e->e_id,
> "%.100s: SMTP DATA-2 protocol error: %s",
> CurHostName,
> shortenstring(SmtpReplyBuffer, 403));
> }
> return rstat;
>
> And rstat is set here just above it :
>
> if (r == 452)
> rstat = EX_TEMPFAIL;
> else if (REPLYTYPE(r) == 4)
> rstat = xstat = EX_TEMPFAIL;
> else if (REPLYTYPE(r) == 2)
> rstat = xstat = EX_OK;
> else if (REPLYCLASS(r) != 5)
> rstat = xstat = EX_PROTOCOL;
> else if (REPLYTYPE(r) == 5)
> rstat = EX_UNAVAILABLE;
> else
> rstat = EX_PROTOCOL;
>
> Thanks for the tweak suggestions :
>
> 1 - Its set to 9, I'd have to go way down to 1.. Not sure total
> implications

Probably not what you want.

> 2 - May do that.

Seems like the best approach, since the behavior of Sendmail isn't
really logically wrong, just not suited to your somewhat unusual logging
setup.

> 3 - I don't like modifying a program if I don't have to, since I'll
> always upgrade it and forget
> to put the changes back in. :)

It looks like you'd notice that, but I agree with the general point...

FWIW, it seems to me like the best code changes to 'fix' this would be
to switch to LOG_ERR for those messages.


> All that being said, does anyone know someone at Critical Path or
> Tucows that might
> be willing to listen about this?

I don't pass around personal email addresses for that sort of thing, but
I have seen a recent claim from a Tucows mail admin that mail to
postmaster@hostedemail.com reaches the eyeballs of people interested in
making sure their systems interoperate politely with the world.

--
Now where did I hide that website...