Prev: Migrating from postfix to Exim
Next: building postfix 2.7 from source
From: Wietse Venema on 12 Apr 2010 07:32
Emanuele Gallo:
> I don't think that it's the problem. My mail server is developed in C
> language and replies that I send to Postfix are strings.

As documented in RFC documents from 20 years ago, SMTP requires
that lines end in <CR><LF>.

> As I think you
> know, all strings in C are NULL terminated and there's no chance for

SMTP is not C.

Wietse

From: Emanuele on 12 Apr 2010 12:02
I know that NULL is there to indicate end of a string. But why if I do:

send(SMTPSocket,session->reply,strlen(session->reply)); // session->reply
is where I wrote the response code that ends with \r\n\0

it also sends '\0'?

strlen() shouldn't count \0, but Postfix receives '\0'.

However, I've tried to create session->reply without \0, but in many cases,
obviously, it contains garbage at the end (nevertheless, Postfix also
accepts strings with garbage). Take a look at mail.log:

Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: <
myMailServer.localhost[192.168.1.11]:25: 220 myMailServer.localhost SMTP
Service ready
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: >
myMailServer.localhost[192.168.1.11]:25: HELO manugal-desktop.localdomain
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: <
myMailServer.localhost[192.168.1.11]:25: 250 myMailServer.localhost SMTP
Service
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: server features: 0x1000
size 0
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: >
myMailServer.localhost[192.168.1.11]:25: MAIL
FROM:<manugal(a)manugal-desktop.localdomain>
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: <
myMailServer.localhost[192.168.1.11]:25: nugal-d-??&L?250 MAIL
FROM:<manugal(a)manugal-desktop.localdomain> OK //garbage in response


Il 12/04/2010 16:38, Aaron Wolfe ha scritto:

You are either misunderstanding fundamental programming concepts or
just being silly. NULL is there to indicate end of string, it is not
part of the string itself. if you concatenate two strings do you
expect a NULL in the middle of the new string? of course not. Your
program is broken, do not send NULL after cr/lf.

Good luck,
-Aaron


On Mon, Apr 12, 2010 at 4:40 AM, Emanuele Gallo <manugal83(a)gmail.com>
<manugal83(a)gmail.com> wrote:


I don't think that it's the problem. My mail server is developed in C
language and replies that I send to Postfix are strings. As I think you
know, all strings in C are NULL terminated and there's no chance for create
string that aren't NULL terminated. Moreover, as previously mentioned, my
server works well with Mozilla Thunderbird. If <CR><LF><NULL> were the
guilty, neither the first string ("220 myMailServer.localhost SMTP service
ready") would arrive.

Il 11/04/2010 22:48, Wietse Venema ha scritto:


Emanuele:



Ok, I've attached tcp dump. It contains only 8 packets because after the
HELO message, as you can see from logfile previously posted, there's no
more
communication.



Your server replies end in

<CR><LF><NULL>

That is not SMTP compliant.

Wietse
From: Victor Duchovni on 12 Apr 2010 12:10
On Mon, Apr 12, 2010 at 06:02:49PM +0200, Emanuele wrote:

> I know that NULL is there to indicate end of a string. But why if I do:
>
> send(SMTPSocket,session->reply,strlen(session->reply)); // session->reply
> is where I wrote the response code that ends with \r\n\0
>
> it also sends '\0'?

No.

> strlen() shouldn't count \0, but Postfix receives '\0'.

No, it does not. You can convince yourself of this by looking at the
traffic with tcpdump. Bugs in your not yet working SMTP client
are not Postfix issues, please do not add traffic to this list
unless you have a *verified* (provable, reproducible with clear
and correct evidence) issue in Postfix.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

From: Wietse Venema on 12 Apr 2010 13:04
Emanuele:
> I know that NULL is there to indicate end of a string. But why if I do:
>
> send(SMTPSocket,session->reply,strlen(session->reply)); // session->reply
> is where I wrote the response code that ends with \r\n\0
>
> it also sends '\0'?
>
> strlen() shouldn't count \0, but Postfix receives '\0'.

I suggest that you debug your application by looking at tcpdump
output. You have already learned how to capture an SMTP session
"on the wire".

You appear to be struggling with a string conversion problem,
namely, between the internal representation used in your C program,
and the external representation used in the SMTP protocol.

I think you're trying to avoid that conversion, and that would be
a mistake.

In SMTP, text lines end in <CR><LF>, and NULL characters are allowed
only in those places where the protocol syntax says so (NULL was
never allowed between <CR><LF> and the next server response).

In C, the default string representation is a character buffer with
an implicit length (indicated with the null-terminator). Postfix
uses a different internal representation: a character buffer with
an explicit length that is updated as data is added to the buffer.
This representation was chosen for convenience and safety.

Regardless of the internal string represenation, to convert from
C to SMTP one appends <CR><LF> on output; and to convert from SMTP
to C, one strips off the <CR><LF> on input.

Wietse

From: Emanuele Gallo on 12 Apr 2010 13:12
Thanks a lot. I'll try to do these changes.

Bye.

Il 12/04/2010 19:04, Wietse Venema ha scritto:
> Emanuele:
>
>> I know that NULL is there to indicate end of a string. But why if I do:
>>
>> send(SMTPSocket,session->reply,strlen(session->reply)); // session->reply
>> is where I wrote the response code that ends with \r\n\0
>>
>> it also sends '\0'?
>>
>> strlen() shouldn't count \0, but Postfix receives '\0'.
>>
> I suggest that you debug your application by looking at tcpdump
> output. You have already learned how to capture an SMTP session
> "on the wire".
>
> You appear to be struggling with a string conversion problem,
> namely, between the internal representation used in your C program,
> and the external representation used in the SMTP protocol.
>
> I think you're trying to avoid that conversion, and that would be
> a mistake.
>
> In SMTP, text lines end in<CR><LF>, and NULL characters are allowed
> only in those places where the protocol syntax says so (NULL was
> never allowed between<CR><LF> and the next server response).
>
> In C, the default string representation is a character buffer with
> an implicit length (indicated with the null-terminator). Postfix
> uses a different internal representation: a character buffer with
> an explicit length that is updated as data is added to the buffer.
> This representation was chosen for convenience and safety.
>
> Regardless of the internal string represenation, to convert from
> C to SMTP one appends<CR><LF> on output; and to convert from SMTP
> to C, one strips off the<CR><LF> on input.
>
> Wietse
>
>

First  |  Prev  | 
Pages: 1 2 3
Prev: Migrating from postfix to Exim
Next: building postfix 2.7 from source