Discussion:
MessageLabs 554 SMTP synchronisation error
(too old to reply)
Frank S. Bernhardt
2005-07-11 18:17:03 UTC
Permalink
Greetings all.

I'm getting grief from Message Labs in that they are complaining that
they are receiving a '554 SMTP synchronization error' when they do a
test connection to our 5.0.7 SCO OpenServer running Exim v4.50. I've
looked in the logs and can verify their error.

Now, a few things:

1) We do receive mail from them via their normal servers (not these
'NEW' ones that are not yet in production for us).

2) We receive email from the rest of the world.

3) When they do a telnet to us on port 25 they complain about a 'long'
delay and then the 554 message.

4) From a supposed print screen I see that they get this right after the
'Escape character is...' message with no greeting message displayed.

5) In the exim configure file I have '# host_lookup = *' commented out

6) When I do a telnet test from various other sites to the mail server,
I get an almost instantaneous greeting.

From the above, I deduce that the problem is at their end specifically,
I think that their servers don't handle or handle improperly ident
callbacks.

I checked the archives and I found a few references to MessageLabs but
nothing dealing with 554 errors.

I'm not a guru when it comes to stuff like this so any thoughts or
suggestions would be appreciated.

Thank you.
--
Regards

Frank S. Bernhardt
b.c.s.i.
14 Halton Court
Markham, ON. Canada
L3P 6R3

905-471-1691 Voice
905-471-3016 FAX

***@bcsi.ca

Registered Linux-User #312398 with the Linux Counter, http://counter.li.org.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Jakob Hirsch
2005-07-11 18:45:13 UTC
Permalink
Post by Frank S. Bernhardt
I'm getting grief from Message Labs in that they are complaining that
they are receiving a '554 SMTP synchronization error' when they do a
So they send their HELO/EHLO before getting your server's greeting.
There is a recent thread "SMTP protocol violation?" which covers this.
Post by Frank S. Bernhardt
3) When they do a telnet to us on port 25 they complain about a 'long'
delay and then the 554 message.
Most probably they block your ident lookup and send no reject packet
(tcp RST or icmp port-unreachable). So it's not your fault, but you
could surely lower your timeout (rfc1413_query_timeout) from the 30s
default (I have 2s).
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Giuliano Gavazzi
2005-07-11 21:19:01 UTC
Permalink
Post by Jakob Hirsch
Post by Frank S. Bernhardt
3) When they do a telnet to us on port 25 they complain about a 'long'
delay and then the 554 message.
Most probably they block your ident lookup and send no reject packet
(tcp RST or icmp port-unreachable). So it's not your fault, but you
could surely lower your timeout (rfc1413_query_timeout) from the 30s
default (I have 2s).
Post by Frank S. Bernhardt
4) From a supposed print screen I see that they get this [a 554
error] right after the 'Escape character is...' message with no
greeting message displayed.
I must say that I do not believe their claim.

g
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Jakob Hirsch
2005-07-11 22:50:24 UTC
Permalink
Post by Frank S. Bernhardt
4) From a supposed print screen I see that they get this [a 554
error] right after the 'Escape character is...' message with no
greeting message displayed.
Maybe their telnet client send something in order to negotiate some
connection parameter. They should try netcat, which has not such hidden
magic.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Carsten Koch-Mauthe
2005-07-12 05:25:37 UTC
Permalink
Hi,
Post by Jakob Hirsch
Post by Frank S. Bernhardt
4) From a supposed print screen I see that they get this [a 554
error] right after the 'Escape character is...' message with no
greeting message displayed.
Maybe their telnet client send something in order to negotiate some
connection parameter. They should try netcat, which has not such hidden
magic.
Try this:

=== Schnipp ===
smtp_enforce_sync Use: main Type: boolean Default: true

The SMTP protocol specification requires the client to wait for a response
from the server at certain points in the dialogue. Without PIPELINING
these synchronization points are after every command; with PIPELINING they
are fewer, but they still exist.

Some spamming sites send out a complete set of SMTP commands without
waiting for any response. Exim protects against this by rejecting a
message if the client has sent further input when it should not have. The
error response '554 SMTP synchronization error' is sent, and the connec-
tion is dropped. Testing for this error cannot be perfect because of
transmission delays (unexpected input may be on its way but not yet
received when Exim checks). However, it does detect many instances.

The check can be globally disabled by setting "smtp_enforce_sync" false.
|
If you want to disable the check selectively (for example, only for
|
certain hosts), you can do so by an appropriate use of a "control"
|
modifier in an ACL (see section 39.18). See also
|
"pipelining_advertise_hosts".
=== Schnapp ===

Gruss
Carsten
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Frank S. Bernhardt
2005-07-12 13:46:16 UTC
Permalink
Gutten tag.
Post by Carsten Koch-Mauthe
Hi,
Post by Jakob Hirsch
Post by Frank S. Bernhardt
4) From a supposed print screen I see that they get this [a 554
error] right after the 'Escape character is...' message with no
greeting message displayed.
Maybe their telnet client send something in order to negotiate some
connection parameter. They should try netcat, which has not such hidden
magic.
=== Schnipp ===
smtp_enforce_sync Use: main Type: boolean Default: true
The SMTP protocol specification requires the client to wait for a response
from the server at certain points in the dialogue. Without PIPELINING
these synchronization points are after every command; with PIPELINING they
are fewer, but they still exist.
Some spamming sites send out a complete set of SMTP commands without
waiting for any response. Exim protects against this by rejecting a
message if the client has sent further input when it should not have. The
error response '554 SMTP synchronization error' is sent, and the connec-
tion is dropped. Testing for this error cannot be perfect because of
transmission delays (unexpected input may be on its way but not yet
received when Exim checks). However, it does detect many instances.
The check can be globally disabled by setting "smtp_enforce_sync" false.
|
If you want to disable the check selectively (for example, only for
|
certain hosts), you can do so by an appropriate use of a "control"
|
modifier in an ACL (see section 39.18). See also
|
"pipelining_advertise_hosts".
=== Schnapp ===
Gruss
Carsten
Yes, I read that as well but I don't think I will need to do that.

I think I've got this under control now. As originally stated we have
been receiving e-mails from Message Labs on an on-going basis with no
problems. It's just that the tests from their new towers were failing
and they were telling me to 'fix my end'. I was fairly certain it wasn't
my fault but I just wanted to see what you guys thought and to cover my
backside.

In my last e-mail from Message Labs they kinda missed the point of the
30s timeout and I don't think they have an ident daemon running but we
will be doing another test at 2s. Their connectivity test tool is set to
use a 10s timeout so we should be ok as their real servers use a 2.5 -
3m timeout.

I think I've taken enough of all your valuable time on this matter and
I'm glad we didn't have to bother Philip with this. ;-)

Thank you all very much.
--
Regards

Frank S. Bernhardt
b.c.s.i.
14 Halton Court
Markham, ON. Canada
L3P 6R3

905-471-1691 Voice
905-471-3016 FAX

***@bcsi.ca

Registered Linux-User #312398 with the Linux Counter, http://counter.li.org.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Frank S. Bernhardt
2005-07-11 23:57:05 UTC
Permalink
Post by Giuliano Gavazzi
Post by Jakob Hirsch
3) When they do a telnet to us on port 25 they complain about a 'long'
delay and then the 554 message.
Most probably they block your ident lookup and send no reject packet
(tcp RST or icmp port-unreachable). So it's not your fault, but you
could surely lower your timeout (rfc1413_query_timeout) from the 30s
default (I have 2s).
I have e-mailed them and offered to do this for them. Does doing this
have any downsides to it, say security wise for 'others' connecting to
us? It's interesting to note that this problem only happens when they
are testing their connection to us from their 'new' bank of towers. Any
mail coming to us form their regular servers or any other server works
just fine.
Post by Giuliano Gavazzi
Post by Jakob Hirsch
4) From a supposed print screen I see that they get this [a 554
error] right after the 'Escape character is...' message with no
greeting message displayed.
I must say that I do not believe their claim.
g
Heh, I kinda thought the same thing, here is what they actually sent me:
With regards to my telnet sessions, these appears to connect
intermittently, giving a 554 Error and being very slow in response.
Please find below an example of a failed telnet session:

[***@europa netstar]$ telnet xx.xx.xx.xx 25
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
554 SMTP synchronization error
Connection closed by foreign host

I am obviously able to connect to something, but then the connection is
terminated.

If the firewall is not blocking any IP addresses, please take a look at
your mailserver settings.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Those are my x's. Is this a cut and paste job or a retype? Who knows. I
do think however that the actual testing is done by a program and not by
a human. They sent me the output (cut and paste?) which looks like some
kind of program output.

And this is what I see in the reject log:
2005-07-11 05:57:49 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[194.106.220.35] input=""
2005-07-11 05:58:03 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[194.106.220.51] input=""
2005-07-11 05:58:17 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[195.245.231.163] input=""
2005-07-11 05:58:31 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[195.245.231.211] input=""
2005-07-11 06:16:52 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[70.110.139.37] input=""
2005-07-11 06:19:11 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[81.204.146.185] input=""
2005-07-11 06:19:41 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[81.204.146.185] input=""
2005-07-11 06:25:26 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[80.5.230.225] input=""

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The time between each test would also lead me to believe that it is being done by a program.
Post by Giuliano Gavazzi
Tower 91 - 194.106.220.35
Tower 92 - 194.106.220.51
Tower 114 - 195.245.231.163
Tower 117 - 195.245.231.211
Tower 123 - 85.158.136.3
Tower 134 - 85.158.137.35
at least for the first 4 tests are. Not sure where the last 4 connections came from.

Well, at least I'm not totaly inept, err maybe. I admire you guys for doing this kinda stuff full time.

Thanks for your feedback. I'll inform you of the outcome.
--
Regards

Frank S. Bernhardt
b.c.s.i.
14 Halton Court
Markham, ON. Canada
L3P 6R3

905-471-1691 Voice
905-471-3016 FAX

***@bcsi.ca

Registered Linux-User #312398 with the Linux Counter, http://counter.li.org.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Giuliano Gavazzi
2005-07-12 00:47:19 UTC
Permalink
Post by Frank S. Bernhardt
2005-07-11 05:57:49 SMTP protocol violation: synchronization error
(input sent without waiting for greeting): rejected connection from
H=[194.106.220.35] input=""
Maybe Jakob suggestion is to the point, perhaps this is indeed some
telnet negotiation (it is too long since I developed a server that
talked telnet...). It would be useful if exim logged some escaped
form of whatever non-printable characters it receives. Having said
so, there are better ways of spending time than this, so please
Philip do not take note.

g
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Philip Hazel
2005-07-12 07:44:18 UTC
Permalink
Maybe Jakob suggestion is to the point, perhaps this is indeed some telnet
negotiation (it is too long since I developed a server that talked telnet...).
It would be useful if exim logged some escaped form of whatever non-printable
characters it receives. Having said so, there are better ways of spending time
than this, so please Philip do not take note.
Exim should already log what it has received in error, and it should
always escape non-printable characters in log lines. As requested, I
have ignored this message.
--
Philip Hazel University of Cambridge Computing Service,
***@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Marc Sherman
2005-07-12 12:18:55 UTC
Permalink
Post by Frank S. Bernhardt
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
554 SMTP synchronization error
Connection closed by foreign host
Those are my x's.
Please don't do that:
http://www.exim.org/eximwiki/MailingListEtiquette#head-a6f7fb5ce8816568569a321f783315207ec38063

- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Frank S. Bernhardt
2005-07-12 13:10:44 UTC
Permalink
Post by Marc Sherman
Post by Frank S. Bernhardt
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
554 SMTP synchronization error
Connection closed by foreign host
Those are my x's.
http://www.exim.org/eximwiki/MailingListEtiquette#head-a6f7fb5ce8816568569a321f783315207ec38063
- Marc
My apologys. I've seen other people do that and I thought that was
standard practice. I've bookmarked the etiquette page; I didn't even
know it existed.

If you would like me to repost with the IP address, I will.
--
Regards

Frank S. Bernhardt
b.c.s.i.
14 Halton Court
Markham, ON. Canada
L3P 6R3

905-471-1691 Voice
905-471-3016 FAX

***@bcsi.ca

Registered Linux-User #312398 with the Linux Counter, http://counter.li.org.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Marc Sherman
2005-07-12 13:31:02 UTC
Permalink
Post by Frank S. Bernhardt
My apologys. I've seen other people do that and I thought that was
standard practice. I've bookmarked the etiquette page; I didn't even
know it existed.
If you would like me to repost with the IP address, I will.
It seems like it could be helpful, so that others could try to replicate
this test.

- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Frank S. Bernhardt
2005-07-12 14:00:54 UTC
Permalink
Greeting Marc
Post by Marc Sherman
Post by Frank S. Bernhardt
My apologys. I've seen other people do that and I thought that was
standard practice. I've bookmarked the etiquette page; I didn't even
know it existed.
If you would like me to repost with the IP address, I will.
It seems like it could be helpful, so that others could try to
replicate this test.
- Marc
Certainly. If someone wants to wail away on it by all means.

207.188.76.86.

I'm a little paranoid right now because someone has been running a
dictionary attack on server for the last 2 days. * sigh *
--
Regards

Frank S. Bernhardt
b.c.s.i.
14 Halton Court
Markham, ON. Canada
L3P 6R3

905-471-1691 Voice
905-471-3016 FAX

***@bcsi.ca

Registered Linux-User #312398 with the Linux Counter, http://counter.li.org.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Suresh Ramasubramanian
2005-07-12 02:59:55 UTC
Permalink
Post by Jakob Hirsch
Post by Frank S. Bernhardt
3) When they do a telnet to us on port 25 they complain about a 'long'
delay and then the 554 message.
Most probably they block your ident lookup and send no reject packet
(tcp RST or icmp port-unreachable). So it's not your fault, but you
could surely lower your timeout (rfc1413_query_timeout) from the 30s
default (I have 2s).
0s would be far better for ident.

Also check for any smtp inspection firewalls between you and
messagelabs (pix? raptor?)

regards
--srs
--
***@frodo.hserus.net (Suresh Ramasubramanian)
***@ravel:/usr/src$ mv linux Gnu/Linux
mv: cannot move `linux' to `Gnu/Linux': No such file or directory
jaharkes @ cs.cmu.edu in reply to RMS on linux.kernel
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Marc Sherman
2005-07-12 12:22:02 UTC
Permalink
Post by Suresh Ramasubramanian
0s would be far better for ident.
Like religious wars much? It's quite useful to some people, on the
sending end, for you to have ident data in your receiving-side logs when
you go to report a problem.

- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Mark
2005-07-13 08:12:15 UTC
Permalink
Post by Marc Sherman
Post by Suresh Ramasubramanian
0s would be far better for ident.
Like religious wars much? It's quite useful to some people, on the
sending end, for you to have ident data in your receiving-side logs when
you go to report a problem.
Though in a large hosting environment where the bulk of the mail is
coming from other ISP mailhosts the ident information is next to
impossible. In my experience (other peoples will/may vary) I've yet to
have a situation where ident information would have helped speed the
resolution of a problem.
--
Mark <***@korenwolf.net>
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Ian FREISLICH
2005-07-12 12:49:48 UTC
Permalink
Post by Marc Sherman
Post by Suresh Ramasubramanian
0s would be far better for ident.
Like religious wars much? It's quite useful to some people, on the
sending end, for you to have ident data in your receiving-side logs when
you go to report a problem.
Out of interest what proportion of your logs have useful ident data?

I gave up on ident (asking and answering) nearly 10 years ago when
the vast majority of my calls were unanswered. Personally, I think
it's more important to keep your system time properly synchronised
so that your timestamps are useful.

Ian

--
Ian Freislich
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Alan J. Flavell
2005-07-12 13:20:23 UTC
Permalink
Post by Ian FREISLICH
Out of interest what proportion of your logs have useful ident data?
Depends what you mean by "useful".

I give you these, for example:

2005-07-06 22:51:54 H=(corporation.net) [168.187.205.3] U=CacheFlow Server
F=<***@corporation.net> rejected RCPT
Rejected - appears to be an unsecured proxy: CacheFlow Server

2005-07-07 18:03:25 H=(mailhub.vianetworks.nl) [194.250.136.80]
U=squid F=<***@noord.bart.nl> rejected RCPT
Rejected - appears to be an unsecured proxy: squid

There's still (years after this problem was first exposed) a moderate
number of such rejections in our log. In due course the IPs in
question turn up in blacklists (and indeed both of those IPs are well
and truly blacklisted now), and could be rejected on that or on other
grounds, but these characteristic idents seem to be a sure-fire
rejection, on the assumption that no-one is seriously going to run
their MTA with a user name of "squid", let alone "CacheFlow Server".

Sure, the original motive was multi-user systems, where individual
users might be attempting direct-to-MX SMTP, and I'd admit that this
scenario is far less usual than it used to be, for many different
reasons. But when reporting abuse to some remote site, it can still
be a useful handle.

Whether you choose to activate ident or not is entirely a matter for
your local policy, and I wouldn't for a moment try to tell you what to
do. But if you do activate it, then definitely set the timeout to
just a few seconds (we've used 7s for a considerable time, but I
suspect it could well be less and still serve its purpose). Ideally,
if a remote network is not going to respond to ident then it should
reject, rather than dropping the traffic on the floor and leaving us
to time out, but that isn't something we have any control over,
obviously.

best regards
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Marc Sherman
2005-07-12 13:34:57 UTC
Permalink
Post by Alan J. Flavell
Whether you choose to activate ident or not is entirely a matter for
your local policy, and I wouldn't for a moment try to tell you what to
do.
Oh, definitely. I wasn't arguing that ident should be required by
anyone at all, just taking issue with Suresh's categorical statement
that ident should be disabled by everyone.

- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Mark
2005-07-13 08:15:17 UTC
Permalink
Post by Alan J. Flavell
Post by Ian FREISLICH
Out of interest what proportion of your logs have useful ident data?
Depends what you mean by "useful".
2005-07-06 22:51:54 H=(corporation.net) [168.187.205.3] U=CacheFlow Server
Rejected - appears to be an unsecured proxy: CacheFlow Server
2005-07-07 18:03:25 H=(mailhub.vianetworks.nl) [194.250.136.80]
Rejected - appears to be an unsecured proxy: squid
There's still (years after this problem was first exposed) a moderate
number of such rejections in our log. In due course the IPs in
question turn up in blacklists (and indeed both of those IPs are well
and truly blacklisted now), and could be rejected on that or on other
grounds, but these characteristic idents seem to be a sure-fire
rejection, on the assumption that no-one is seriously going to run
their MTA with a user name of "squid", let alone "CacheFlow Server".
Under those conditions it would seem to be more sensible to bring the
ident lookup into an acl (is that possible?) and only test hosts on the
various dynamic IP lists.
--
Mark <***@korenwolf.net>
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Ted Cooper
2005-07-13 00:44:54 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Ian FREISLICH
Post by Marc Sherman
Post by Suresh Ramasubramanian
0s would be far better for ident.
Like religious wars much? It's quite useful to some people, on the
sending end, for you to have ident data in your receiving-side logs when
you go to report a problem.
Out of interest what proportion of your logs have useful ident data?
I gave up on ident (asking and answering) nearly 10 years ago when
the vast majority of my calls were unanswered. Personally, I think
it's more important to keep your system time properly synchronised
so that your timestamps are useful.
I still find the delay at the begining (30s by default) very useful for
getting rid of impatient spam sending servers (trojans mostly). They have a
simple SMTP client that just waits a certain time before sending - with a 30s
wait at the begining, they get an SMTP sync error.

As for useful Ident data? On the times that I have recieved it, it's always
been a sign of a compromised computer being abused :P I can't use it as a
marker though, because someone may set up a real one some day.

I can't really see what keeping the time right has to do with ident, but yes,
having the time right on all servers is essential. That's what ntpd is for
(and GPSClock if you can afford it).

Ted.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC1GQEHTFM6KkFI5oRArSJAKCXHj4kxLwyFYbcYKiHuvmVWzgiewCeJ5w+
e1OPJzTOeRZDZPerru1l49I=
=La5f
-----END PGP SIGNATURE-----
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Steve Lamb
2005-07-13 16:03:37 UTC
Permalink
Post by Ted Cooper
I can't really see what keeping the time right has to do with ident, but yes,
It doesn't. His point was that in order of importance keeping time synced
was of higher importance to him than ident data. Like one saying, "Between
meeting my inlaws or having my nuts waxed by a rather burly slavic woman with
a unibrow... I'll take the nut-waxing" to show distaste and disdane for the
inlaws.

Other than that, no relation.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Marc Sherman
2005-07-13 16:10:23 UTC
Permalink
Post by Steve Lamb
Post by Ted Cooper
I can't really see what keeping the time right has to do with
ident, but yes,
It doesn't. His point was that in order of importance keeping time
synced was of higher importance to him than ident data. Like one
saying, "Between meeting my inlaws or having my nuts waxed by a
rather burly slavic woman with a unibrow... I'll take the
nut-waxing" to show distaste and disdane for the inlaws.
The relationship is that ident and well synched clocks are both tools
that can be used to link events on multiple servers. Ident can be used
by having usernames from server A appear in the logs on server B.
Well-synched clocks can be used by having log entries from both servers
show the same time stamps.

- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Greg A. Woods
2005-07-13 18:23:51 UTC
Permalink
[ On Wednesday, July 13, 2005 at 12:10:23 (-0400), Marc Sherman wrote: ]
Subject: Re: [exim] MessageLabs 554 SMTP synchronisation error
The relationship is that ident and well synched clocks are both tools
that can be used to link events on multiple servers. Ident can be used
by having usernames from server A appear in the logs on server B.
Actually the point of IDENT is to provide a server with additional (and
possibly private) information about the connection to be logged along
with the transaction so that if the server administrator ever comes back
to the client administrator and asks for more details about what human
person might be responsible for the connection then the client admin can
ask for a copy of the IDENT information back again so it can be used to
correlate local logs with the event the server admin is asking about.

Indeed it is often considered an invasion of privacy to send local
user-ID information via IDENT to the server to be logged, especially
when that information is only supposed to be used in some kind of
abnormal situation.

As a result of these considerations many of us who do still provide
IDENT services will only ever use the encrypted variety. For example I
run "identd -C" on my system called "building" and my mail server makes
IDENT queries:

$ telnet mail 25
220-most.weird.com Smail-3.2.0.121-Pre (#1 2005-Jul-13)
220-ready at Wed, 13 Jul 2005 14:09:55 -0400 (EDT)
220 ESMTP supported
HELO building
250 most.weird.com Hello building ([QpNNMiE+Eq+T4IAvs/SxrQ1qnw4HMksMXG1tstbkm8AqGk4VhgzD4n9ldoyX07i8zStf6dRhOQ/fBAswFkDt/A==]@building.weird.com from address [204.92.254.24]).

Note that big long string of gobbledygook in the square brackets before
the '@' in the comment text of the 250 reply to my HELO.

It decrypts as follows:

# idecrypt
[QpNNMiE+Eq+T4IAvs/SxrQ1qnw4HMksMXG1tstbkm8AqGk4VhgzD4n9ldoyX07i8zStf6dRhOQ/fBAswFkDt/A==]
[Wed Jul 13 14:09:55 2005 UID=1000 GID=1000 PID=27625 CMD=telnet 204.92.254.24.57552->204.92.254.2.25]

(Note that's extended from what the standard identd's '-C' format, but
that's the level of detail I wanted my version to provide.)

Now the encryption I happen to use is only standard crypt(2), so 56-bit
DES, and so someone with a few IDENT replies, and especially with the
example above showing what it should look like, could soon decode my
key, but note there's an easy mechanism in the identd and idecrypt
programs to provide new keys on a regular basis, which would somewhat
increase the difficulty, perhaps beyond the utility of the information
that can be gained from the effort.

Note also this from the identd(8) manual page:

SECURITY CONSIDERATIONS

May leak information generally considered "private" unless
the -e flag or either the -L or -C flags are used.

The protocol is unprotected and is vulnerable to man-in-
the-middle attacks.


Make of that what you will, but note that with encryption the attacker
really would have to break my _current_ key before they could forge my
IDENT replies.
Well-synched clocks can be used by having log entries from both servers
show the same time stamps.
Note the timestamp is included in my IDENT reply so it really doesn't
matter if the server's clocks are in sync with the client clocks since
the clients original timestamp is available on demand. That's not
saying one shouldn't keep one's system clocks in sync with network time,
but rather just that should such synchronisation fail there's still a
chance of correlating logs between foreign systems if IDENT is used.
--
Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Renaud Allard
2005-07-13 12:23:02 UTC
Permalink
What I actually do is setting a very short timeout of 1 sec:
rfc1413_hosts = *
rfc1413_query_timeout = 1s

This is not too much of a burden to wait as low as 1 sec and can help rejecting some squid/cacheflow based spams.

my acl looks like this:

drop
condition = ${if eq{$sender_ident}{CacheFlow Server}{1}{0}}
message = Rejected - appears to be an unsecured proxy: $sender_ident

It may not be worth doing it considering the few amount spam I catch this way, but I prefer not having to scan the mail with spamassassin when I can afford detecting it earlier. Ident only wastes a network socket for one second while spamassassin does waste much more. And as some of my other antispam techniques rely on delaying mails if they meet some criterias, that's really not much of a burden to have it wait 1 more second.


On Wed, 13 Jul 2005 12:00:01 +0100
Subject: Re: [exim] MessageLabs 554 SMTP synchronisation error
Date: Wed, 13 Jul 2005 09:15:17 +0100
Post by Alan J. Flavell
Post by Ian FREISLICH
Out of interest what proportion of your logs have useful ident data?
Depends what you mean by "useful".
2005-07-06 22:51:54 H=(corporation.net) [168.187.205.3] U=CacheFlow Server
Rejected - appears to be an unsecured proxy: CacheFlow Server
2005-07-07 18:03:25 H=(mailhub.vianetworks.nl) [194.250.136.80]
Rejected - appears to be an unsecured proxy: squid
There's still (years after this problem was first exposed) a moderate
number of such rejections in our log. In due course the IPs in
question turn up in blacklists (and indeed both of those IPs are well
and truly blacklisted now), and could be rejected on that or on other
grounds, but these characteristic idents seem to be a sure-fire
rejection, on the assumption that no-one is seriously going to run
their MTA with a user name of "squid", let alone "CacheFlow Server".
Under those conditions it would seem to be more sensible to bring the
ident lookup into an acl (is that possible?) and only test hosts on the
various dynamic IP lists.
--
--
Nikademus
http://www.octools.com

.O.
..O
OOO

PGP key: http://www.llorien.org/gnupg/key.pub
Ted Cooper
2005-07-14 03:54:48 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What about the folowing then?
acl_smtp_connect
warn !hosts = +relay_from_hosts : +hetzner_nets
condition = ${if eq{$interface_port}{587} {no}{yes}}
delay = 30s
I find this works just as well. I don't use multiple interfaces so this is
pretty simple:

rfc1413_hosts = ! 192.168.32.0/24 : *
I said I think it is more important than ident. I find little value
in ident information. Maybe if it reported local time on the remote
machine, that would help for tracking reports but the data it reports
is IMHO pretty much useless otherwise.
It's the inherent delay I find useful, and it's really cheap. In the event I
get an ident response, it shows up in the log parsing and can be used to
trigger things (adding an IP to a block list).
Trusting the remote computer to supply more, unverifiable, information is
never going to be a good idea :P That's the main reason why email is such a
PITA now days.

Ted.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC1eIHHTFM6KkFI5oRAuiuAJwJ2xaTLeEelboojSfUNE45WZcCSACeJVhX
uohoASpO4POw2eLAPn0wY34=
=Kc5o
-----END PGP SIGNATURE-----
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
Loading...