Re: Strange problem in SMTP communication

[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 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 
 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



That is not SMTP compliant.

Wietse
   

Re: Strange problem in SMTP communication

[mouss]

Emanuele Gallo a écrit :
> 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.

1- data sent over the network has nothing to do with C, java, or
whatever language. In particular, when you talk SMTP, you must obey SMTP
protocol specs.

2- Even in C, char* does not need to be NULL terminated.

if this isn't clear, try
$ man 2 write
$ man sendto
...

PS. "Unix Network Programming" by W. Richard Stevens is an excellent
reading.


> Moreover, as previously
> mentioned, my server works well with Mozilla Thunderbird. If
>  were the guilty, neither the first string ("220
> myMailServer.localhost SMTP service ready") would arrive.
> 
> [snip]

Re: Strange problem in SMTP communication

[Emanuele Gallo]

Thanks a lot. In fact I've tried to send string not NULL-terminated and 
now Postfix replies me correctly. I would never understand. I'll change 
all reply strings in my program (hoping I'm not compromise the 
functioning with other mail clients).


Bye.

Il 12/04/2010 12:40, mouss ha scritto:

Emanuele Gallo a écrit :
   

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.
 

1- data sent over the network has nothing to do with C, java, or
whatever language. In particular, when you talk SMTP, you must obey SMTP
protocol specs.

2- Even in C, char* does not need to be NULL terminated.

if this isn't clear, try
$ man 2 write
$ man sendto
...

PS. "Unix Network Programming" by W. Richard Stevens is an excellent
reading.


   

Moreover, as previously
mentioned, my server works well with Mozilla Thunderbird. If
  were the guilty, neither the first string ("220
myMailServer.localhost SMTP service ready") would arrive.

[snip]
 
   

Re: building Postfix 2.7 from source Help!

[john]

On 12/04/2010 2:20 AM, ram wrote:


On Sun, 2010-04-11 at 19:51 -0400, john wrote:

i am attempting to build Postfix from the source rpms, I think I have
worked out how to set the various parameters to get the options I want.
except I don't see how to make this a x86_64 install.
What am i missing?
JLA

 



On a redhat like  box this should work
rpmbuild --rebuild /path/postfix.xxx.src.rpm



Thanks, so nothing special to get a 64 bit (x86_64) version.
Now all I have to work out is how to get the options I want, There I 
think I am making progress, time will  tell.

Once again thanks
JLA

Re: Strange problem in SMTP communication

[Wietse Venema]

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 .

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

SMTP is not C. 

Wietse

Re: Patch: support BURL

[Mike Abbott]

>> +if (in_stream == NULL) {
>> +/* must fail the entire transaction */
>> +chat_reset(state, var_smtpd_hist_thrsh);
>> +mail_reset(state);
>> +rcpt_reset(state);
>> +return -1;
>> +}
> 
> Why no response to the client?

The function imap_open() responds to the client before it returns NULL.
in_stream = imap_open(state, url);

>> +case SMTP_ERR_EOF:
>> +smtpd_chat_reply(state, "554 4.6.6 EOF from IMAP server");
>> +vstream_longjmp(state->client, SMTP_ERR_QUIET);
>> +break;
> 
> Why is the DSN code 4.X.X when the SMTP reply code is 5XX? Is this a
> permanent or a transient error code? 

It is a transient failure.  The reasoning for these particular codes was as 
follows.  RFC 4468 section 3.2 states "If the URL fetch fails, the server will 
fail the entire transaction."  RFC 5321 section 4.2.2 uses code 554 for 
"Transaction failed."  And the table in RFC 5248 section 2.4 implies that a 
4.6.6 is valid with a 554.  If this interpretation of the RFCs is incorrect, 
please propose corrected response codes.


The remainder of your feedback speaks to style and to weaknesses in the 
implementation that I pointed out in the cover letter to the code contribution. 
 That cover letter also said:
Feel free to [...] restructure or rewrite the code as desired,
as long as you preserve our copyright.  We understand that our
implementation choices may differ from yours; if you see a better way to
achieve the same goal please do adopt the better way.

RE: amavis Delivery status notification(DSN) failing

[Sharma, Ashish]

Andreas,

Thanks for the suggestion, 

On comparison I found this http://code.google.com/p/subethasmtp/ to be more 
appropriate(lightweight and easy to use for a simple postfix content filter) 
than the heavyweight Apache James.

Ashish Sharma

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of lst_ho...@kwsoft.de
Sent: Friday, April 09, 2010 7:37 PM
To: postfix-users@postfix.org
Subject: RE: amavis Delivery status notification(DSN) failing

Zitat von "Sharma, Ashish" :

> Wietse,
>
> Thanks for your suggestion.
>
> Since I am new in this can you suggest some java based deployments  
> that I can use. I too looked for what you have suggested but maybe I  
> didn't looked hard enough.
>
> Thanks in advance
> Ashish Sharma


http://james.apache.org/

Regards

Andreas

Re: Patch: support BURL

[Mike Abbott]

> In the mean time, the authors may want to enforce strict sanity
> checks on IMAP server output such as the reply payload length, and
> also make sure that their vstream_limit code behaves when reads
> are alternated with writes (either refuse to allow read/write/read,
> or enforce the limit as promised).

OK

> One question I have is why would anyone send an email message that
> is 100% identical to a message that is already sitting in an IMAP
> store?

Because the message in the IMAP server is brand-new, having just been composed 
by the user.  For instance:
1.  As the user composes a new message, the MUA saves the new message in the 
IMAP "Drafts" mailbox, possibly by using CATENATE (RFC 4469) and URLAUTH (RFC 
4467) to compose it out of parts of other messages already on the IMAP server.
2.  The MUA connects to Postfix and uses a BURL command instead of a DATA 
command.
3.  Postfix connects to the IMAP server to retrieve the body of the message 
from the Drafts mailbox.
4.  After receiving a positive response from Postfix, the MUA moves the message 
from the Drafts mailbox to the Sent mailbox.

Notice that in this example, the body of the message is pushed out of the 
client only once (to the IMAP server).  Without BURL, it is pushed at least 
twice (once to Postfix and a second time to the Sent mailbox, and possibly also 
to the Drafts mailbox for auto-save during composition).  RFC 4550 section 2 
explains it better.  On bandwidth-constrained devices such an optimization can 
have a significant effect.

> Why is there a problem with sending mail to the SMTP server directly,
> instead of taking an indirect route via an IMAP server?

There is no such problem.  The problem is the double- or triple-transmission 
that is currently needed: once to SMTP, again to IMAP (for saving a copy in 
Sent, and auto-save to Drafts).

> explain why sending to an IMAP server is 
> faster than sending that same message to an SMTP server.

It isn't, except for CATENATE (RFC 4469) and URLAUTH (RFC 4467).  With these 
one can forward a huge attachment using minimal bandwidth.  Then once the new 
huge message is complete, fast server-to-server communication (i.e., BURL) can 
be used to send it.  The example in RFC 4550 section 2.4.1 shows how an 
arbitrarily-large attachment can be forwarded while using only a couple KB of 
bandwidth for mail headers, MIME headers, and plain-text comments.

The savings is in the reduction of bandwidth between the client and the server 
-- both servers, IMAP and SMTP.  The benefit is in being able to forward a 
multi-megabyte document from a low-network-bandwidth, high-network-latency 
device using only 2-3 TCP packets rather than thousands.

Re: Patch: support BURL

[Victor Duchovni]

On Mon, Apr 12, 2010 at 08:56:17AM -0500, Mike Abbott wrote:

> >> +  case SMTP_ERR_EOF:
> >> +  smtpd_chat_reply(state, "554 4.6.6 EOF from IMAP server");
> >> +  vstream_longjmp(state->client, SMTP_ERR_QUIET);
> >> +  break;
> > 
> > Why is the DSN code 4.X.X when the SMTP reply code is 5XX? Is this a
> > permanent or a transient error code? 
> 
> It is a transient failure.  The reasoning for these particular codes
> was as follows.  RFC 4468 section 3.2 states "If the URL fetch fails, the
> server will fail the entire transaction."  RFC 5321 section 4.2.2 uses
> code 554 for "Transaction failed."  And the table in RFC 5248 section
> 2.4 implies that a 4.6.6 is valid with a 554.  If this interpretation
> of the RFCs is incorrect, please propose corrected response codes.

This interpretation is incorrect, the 3-digit SMTP code, must match the
3-part DSN code. For transient errors use 454.

-- 
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.

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 10:24 AM, Mike Abbott wrote:
> Because the message in the IMAP server is brand-new, having just been
> composed by the user.  For instance:
> 1. As the user composes a new message, the MUA saves the new message
> in the IMAP "Drafts" mailbox, possibly by using CATENATE (RFC 4469)
> and URLAUTH (RFC 4467) to compose it out of parts of other messages
> already on the IMAP server.
> 2. The MUA connects to Postfix and uses a BURL command instead of a
> DATA command.
> 3. Postfix connects to the IMAP server to retrieve the body of the
> message from the Drafts mailbox.
> 4. After receiving a positive response from Postfix, the MUA moves
> the message from the Drafts mailbox to the Sent mailbox.

How would this work for messages that are never saved to the Drafts folder?

In fact, I rarely save it to the drafts folder before sending...

-- 

Best regards,

Charles

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 11:03 AM, Charles Marcus wrote:
> On 2010-04-12 10:24 AM, Mike Abbott wrote:
>> Because the message in the IMAP server is brand-new, having just been
>> composed by the user.  For instance:
>> 1. As the user composes a new message, the MUA saves the new message
>> in the IMAP "Drafts" mailbox, possibly by using CATENATE (RFC 4469)
>> and URLAUTH (RFC 4467) to compose it out of parts of other messages
>> already on the IMAP server.
>> 2. The MUA connects to Postfix and uses a BURL command instead of a
>> DATA command.
>> 3. Postfix connects to the IMAP server to retrieve the body of the
>> message from the Drafts mailbox.
>> 4. After receiving a positive response from Postfix, the MUA moves
>> the message from the Drafts mailbox to the Sent mailbox.

> How would this work for messages that are never saved to the Drafts folder?
> 
> In fact, I rarely save it to the drafts folder before sending...

I was actually hoping this could somehow result in satisfaction of the
past requests for a way to automatically save a copy of the message to
the Sent folder without having to transfer it twice over the wire (once
to send it and once to save it to the sent folder)...

-- 

Best regards,

Charles

Re: Patch: support BURL

[Mike Abbott]

> How would this work for messages that are never saved to the Drafts folder?

Then instead the message could be saved to the Sent folder instead, and the 
submission server could fetch it from there.  The MUA would have to remove it 
from the Sent folder if sending failed, of course.  Nothing magic about the 
Drafts folder.

Re: Patch: support BURL

[Victor Duchovni]

On Sat, Apr 10, 2010 at 09:19:50AM -0400, Wietse Venema wrote:

> So this is really about sending yourself mail via IMAP, instead of
> listing yourself in the Cc: address box.

Email Cc'd to the user does not necessarily arrive in the Sent folder
(it does for Gmail users, but Gmail's "folders" have annoying quirks
when used with IMAP).

Also, IMAP offers bandwidth efficient cut/paste message composition
mechanisms for suitably inter-operable low-bandwidth devices. The
client does not need to move all the message data back and forth.

> That saves no bandwidth - instead it reverses a single MTA->IMAP
> mail flow into IMAP->MTA, at the cost of another protocol.

The end-to-end story is bit more complex, because the user may be
responding to a large message, by e.g. forwarding a large attachment, ...
so the data is already on the IMAP server.

> There are smarter ways to do this:  teach the IMAP server how talk
> authenticated SMTP (it can proxy the user's credentials, just like
> the MTA can proxy them with BURL). Then, the IMAP server can manage
> the entire message composition process instead of relying on BURL
> kludges.

Marshall Rose did something like this in the late 80's with the pop server
in MH toolkit. That POP server supported a message submission command,
so that POP clients did not need a separate SMTP server.

I too would have expected a new IMAP extension that would allow the IMAP
client to ask the IMAP server to post the message. I don't know why this
route was not taken.

-- 
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.

Re: Patch: support BURL

[Mike Abbott]

> This interpretation is incorrect, the 3-digit SMTP code, must match the
> 3-part DSN code. For transient errors use 454.

Thank you.

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 11:16 AM, Mike Abbott wrote:
>> How would this work for messages that are never saved to the Drafts
>> folder?
> 
> Then instead the message could be saved to the Sent folder instead, and
> the submission server could fetch it from there.  The MUA would have to
> remove it from the Sent folder if sending failed, of course.  Nothing
> magic about the Drafts folder.

There is no IMAP client that I'm aware of that can 'save' a message to
to the Sent folder.

What makes the most sense to me is for the IMAP server to have a
'submission service' that can be used by the client *instead* of
defining/using an smtp server directly - then the IMAP server could take
care of both sending the message and saving the copy to the Sent folder.

-- 

Best regards,

Charles

Re: Patch: support BURL

[Victor Duchovni]

On Mon, Apr 12, 2010 at 11:50:02AM -0400, Charles Marcus wrote:

> There is no IMAP client that I'm aware of that can 'save' a message to
> to the Sent folder.

They all do it, that's how messages end up in the Sent folder, you
are confused.

-- 
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.

Re: Patch: support BURL

[Steve]

 Original-Nachricht 
> Datum: Mon, 12 Apr 2010 11:53:10 -0400
> Von: Victor Duchovni 
> An: postfix-users@postfix.org
> Betreff: Re: Patch: support BURL

> On Mon, Apr 12, 2010 at 11:50:02AM -0400, Charles Marcus wrote:
> 
> > There is no IMAP client that I'm aware of that can 'save' a message to
> > to the Sent folder.
> 
> They all do it, that's how messages end up in the Sent folder, you
> are confused.
> 
AFAIK Outlook often saves the messages in a local Sent folder if you use 
Outlook as a pure IMAP client. On the IMAP server nothing gets saved.

But you are right. All the other clients that I know save the message on the 
server or at least are able to save the message on the server. I never managed 
to do that with Outlook without fancy macros/rules.


> -- 
>   Viktor.
> 
// Steve
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Re: Strange problem in SMTP communication

[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'.

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:
Apr 12 13:53:23 manugal-desktop postfix/smtp[2535]: <
myMailServer.localhost[192.168.1.11]:25: nugal-d-??&L?250 MAIL
FROM: 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 
 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  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

   

That is not SMTP compliant.

   Wietse

Re: Patch: support BURL

[Simon Waters]

On Monday 12 April 2010 16:53:10 Victor Duchovni wrote:
> On Mon, Apr 12, 2010 at 11:50:02AM -0400, Charles Marcus wrote:
> > There is no IMAP client that I'm aware of that can 'save' a message to
> > to the Sent folder.
>
> They all do it, that's how messages end up in the Sent folder, you
> are confused.

Although Thunderbird seems to find ever more ingenious reasons for why it 
can't do it for this specific message at this specific time, as a bonus 
giving you a chance to mistakenly send the message twice. 

Some days I think starting again from scratch with software would be a good 
idea, then I remember how quickly I can code

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 11:53 AM, Victor Duchovni wrote:
> On Mon, Apr 12, 2010 at 11:50:02AM -0400, Charles Marcus wrote:
> 
>> There is no IMAP client that I'm aware of that can 'save' a message to
>> to the Sent folder.
> 
> They all do it, that's how messages end up in the Sent folder, you
> are confused.

No, I simply didn't word my comment well... ;)

The Saving to Sent happens *after* the message is sent via the defined
outbound (usually smtp) server.

Mike had said (and what I was responding to): "Then instead the message
could be saved to the Sent folder instead, and the submission server
could fetch it from there.". This would mean it hadn't been sent yet,
but had been saved to the sent folder *before* sending - or there would
be no reason to 'fetch' it.

I guess Mike was referring to the concept of the Outbox, which Outlook
(and maybe other?) clients use.

-- 

Best regards,

Charles

Re: Strange problem in SMTP communication

[Victor Duchovni]

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.

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 11:56 AM, Steve wrote:
> But you are right. All the other clients that I know save the message
> on the server or at least are able to save the message on the server.
> I never managed to do that with Outlook without fancy macros/rules.

Outlook 2007 finally allows you to Save to a Sent folder directly on the
IMAP server, and has many other IMAP fixes. It still sucks as an IMAP
client (worst is it uses Word to render HTML email rather than IE), it
just sucks less than it used to.

-- 

Best regards,

Charles

Re: Patch: support BURL

[Victor Duchovni]

On Mon, Apr 12, 2010 at 12:09:40PM -0400, Charles Marcus wrote:

> On 2010-04-12 11:53 AM, Victor Duchovni wrote:
> > On Mon, Apr 12, 2010 at 11:50:02AM -0400, Charles Marcus wrote:
> > 
> >> There is no IMAP client that I'm aware of that can 'save' a message to
> >> to the Sent folder.
> > 
> > They all do it, that's how messages end up in the Sent folder, you
> > are confused.
> 
> No, I simply didn't word my comment well... ;)
> 
> The Saving to Sent happens *after* the message is sent via the defined
> outbound (usually smtp) server.

There also no mainstream IMAP MUAs that support BURL. The BURL clients
are free to use a different strategy...

-- 
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.

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 12:03 PM, Simon Waters wrote:
> Some days I think starting again from scratch with software would be a good 
> idea, then I remember how quickly I can code

Timo (dovecot author) has expressed interest in maybe someday coding an
IMAP client from scratch... one can only hope... ;)

-- 

Best regards,

Charles

All my email are 5 minutes delayed

[Alexis Ducastel]

Hello,

I've postfix width dkim-filter installed. Each mail sent from sendmail , or
coming from internet before to be forwarded are delayed of 5 min.
Not 4'30, not 5'10 ... but exactly 5 min ! according to received headers, it
seems like postfix keep it 5 min after dkim doing signature.

I searched in postconf |grep everything that contains 300 seconds (5min) but
nothing relevant in my opinion.

In facts, this postfix is only used for aliases , coupled with a MySQL.

Does anybody knows where is the problem please ?

Thanks a lot.

Alexis Ducastel
=
Here is my complete main.cf if it could help :

smtpd_banner =  ESMTP (Debian/GNU)
biff = no
disable_vrfy_command = yes
smtpd_helo_required = yes
mydestination = localhost, localhost.localdomain
relayhost =
mynetworks =
inet_interfaces = all
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
alias_maps = hash:/etc/aliases
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_aliases.cf
,mysql:/etc/postfix/mysql-virtual_aliases_mailbox.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /var/spool/vmail/
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
smtpd_sasl_auth_enable = yes
smtpd_tls_security_level = may
smtpd_tls_key_file = $config_directory/ssl/smtpd.pem
smtpd_tls_cert_file = $config_directory/ssl/smtpd.pem
smtpd_tls_auth_only = yes
smtp_tls_security_level = may
smtp_tls_key_file = $config_directory/ssl/smtpd.pem
smtp_tls_cert_file = $config_directory/ssl/smtpd.pem
smtp_tls_note_starttls_offer = yes
smtp_tls_enforce_peername = no
smtp_tls_auth_only = yes
content_filter = dkim:[127.0.0.1]:10027
bounce_queue_lifetime = 2h
maximal_queue_lifetime = 10h
minimal_backoff_time = 11m
queue_run_delay = 10m
header_checks = pcre:/etc/postfix/header_checks

Re: All my email are 5 minutes delayed

[Charles Marcus]

On 2010-04-12 12:13 PM, Alexis Ducastel wrote:
> Does anybody knows where is the problem please ? 

Per the welcome message you received when you joined the list:

TO REPORT A PROBLEM see:
http://www.postfix.org/DEBUG_README.html#mail

At a minimum, postfix version, output of postconf -n and unedited
NON-verbose logs exhibiting the problem should be provided...

-- 

Best regards,

Charles

Re: Patch: support BURL

[Timo Sirainen]

On Mon, 2010-04-12 at 11:17 -0400, Victor Duchovni wrote:

> I too would have expected a new IMAP extension that would allow the IMAP
> client to ask the IMAP server to post the message. I don't know why this
> route was not taken.

Lemonade group discussed this in their "push vs pull" arguments. I
didn't follow Lemonade back then, so I can't give any reasons why pull
was chosen. This was anyway a conscious design decision made by the
majority of people in the group.

A quick google search found a draft for the push method:
http://tools.ietf.org/html/draft-gellens-lemonade-push-00

My personal opinion is that:

1) BURL seems somewhat similar to how email clients already behave. They
already save message to IMAP server and send it to SMTP server. BURL
keeps this behavior, it just replaces DATA command with BURL (plus of
course requires the client to first register the IMAP URL).

2) Embedding SMTP commands among IMAP traffic seems a bit ugly too. For
just MAIL FROM and RCPT TO it's probably not too horrible, but what
about (future) SMTP extensions, should they be somehow also supported?

Anyway, I don't think there is much choice anymore. Either implement
BURL that has at least a chance of becoming popular (and with Apple now
implementing it, especially if their future clients will support it,
there is some chance) or try to implement your own non-standard way that
will work only in some specific random installations.


signature.asc
Description: This is a digitally signed message part

Re: Strange problem in SMTP communication

[Wietse Venema]

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 , and NULL characters are allowed
only in those places where the protocol syntax says so (NULL was
never allowed between  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  on output; and to convert from SMTP
to C, one strips off the  on input.

Wietse

Re: Patch: support BURL

[Timo Sirainen]

On Mon, 2010-04-12 at 12:13 -0400, Charles Marcus wrote:
> On 2010-04-12 12:03 PM, Simon Waters wrote:
> > Some days I think starting again from scratch with software would be a good 
> > idea, then I remember how quickly I can code
> 
> Timo (dovecot author) has expressed interest in maybe someday coding an
> IMAP client from scratch... one can only hope... ;)

Not my client and not really even usable yet, but it started with the
right ideas: http://trojita.flaska.net/

I could see myself continuing it instead of starting from scratch..



signature.asc
Description: This is a digitally signed message part

Re: Strange problem in SMTP communication

[Emanuele Gallo]

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, and NULL characters are allowed
only in those places where the protocol syntax says so (NULL was
never allowed between  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  on output; and to convert from SMTP
to C, one strips off the  on input.

Wietse

   

Migrating large virtual domains Re: Migrating from postfix to Exim

[The Doctor]

On Sun, Apr 11, 2010 at 09:52:12AM -0300, Reinaldo de Carvalho wrote:
> On Sun, Apr 11, 2010 at 9:44 AM, The Doctor  wrote:
> > Hello, I am trying to migrate first my outgoing mail server  from
> > postfix 2.7.0 to exim 4.71 .
> >
> 
> ?
> 
> > I got most of it except that when I send mail locally it is ending up in
> > postfix's maildrop queue and not in exim.
> >
> 
> Replace /usr/sbin/sendmail to binary provided by exim.



Actually all I did was to mv Postfix's sendmail over and then link
/path/to/sendmail to /path/to/exim

Great stuff.  Maybe I will right the Postfix to Exim migration articles : -)


> --
> Reinaldo de Carvalho
> http://korreio.sf.net
> http://python-cyrus.sf.net
>
> "Don't try to adapt the software to the way you work, but rather
> yourself to the way the software works" (myself)


Next I have a rather large virtual e-mail to migrate

IF I could parse after the postfix's main.cf virtual_alias_domains = one
 space at the time,
I could then set up in /path/to/virtual a directory with each unique name
and then from its virtual file transfer over the rest
that would be grand.

any tools to do this?

and then there is majordomo, but that is spoken for nicely.  

-- 
Member - Liberal International  This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God, Queen and country! Never Satan President Republic! Beware AntiChrist 
rising! 
http://twitter.com/rootnl2k http://www.facebook.com/dyadallee
UK Time for a Common Sense change vote Liberal Democrat / Alliance 

Sending bounce notifications to postmaster

[Stephen Carville]

I need user non-delivery notifications to be CCed to postmaster.  At
least the headers need to be sent.   Right I have the double bounces
being sent by adding "2bounce" to notify_classes.   I tried adding
"bounce" to notify_classes but that seemed to send an email for every
time postfix rejected a message.  Considering over 25,000 messages get
rejected a day that's not too useful to me.

How do I get non-delivery notifications -- at least the headers --
sent to postmaster too?  Without thousands of transaction snippets
flooding the inbox?

mail_version = 2.3.3

$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
alternate_config_directories = /etc/postfix-mars
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
delay_warning_time = 1h
disable_vrfy_command = yes
home_mailbox = Maildir/
html_directory = no
inet_interfaces = localhost, 172.21.6.9
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 26214400
minimal_backoff_time = 300s
mydestination = $myhostname, localhost.$mydomain, localhost cadmzmx01.lereta.com
mydomain = lereta.com
myhostname = mx01.lereta.com
mynetworks = cidr:/etc/postfix/mynetworks
newaliases_path = /usr/bin/newaliases.postfix
notify_classes = resource, software, 2bounce
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical_map
relay_domains = closetheloan.com
dpsi-corp.com
it.lereta.com
lereta.com
lereta.net
lereta.org
source.totalflood.com
taxandflood.com
taxandflood.net
taxandflood.org
totalflood.com
totalflood.net
totalflood.org
relay_recipient_maps = hash:/etc/postfix/relay_recipients
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy_map
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = check_recipient_access
  pcre:/etc/postfix/drop_list
  permit_mynetworks
  reject_unauth_destination
  check_client_access cidr:/etc/postfix/accept_by_ip
  reject_invalid_helo_hostname
  reject_non_fqdn_helo_hostname
  reject_unknown_sender_domain
  check_helo_access pcre:/etc/postfix/helo_check
  reject_unauth_pipelining
  check_sender_access hash:/etc/postfix/accept_by_domain
  reject_rbl_client zen.spamhaus.org
  check_client_access cidr:/etc/postfix/reject_by_ip
  check_client_access hash:/etc/postfix/reject_by_client
  check_sender_access hash:/etc/postfix/reject_by_domain
  check_recipient_access hash:/etc/postfix/filtered_domains
  permit
smtpd_reject_unlisted_recipient = yes
smtpd_tls_CAfile = /etc/pki/tls/certs/gd_bundle.crt
smtpd_tls_cert_file = /etc/pki/tls/certs/wildcard.lereta.com.crt
smtpd_tls_key_file = /etc/pki/tls/private/wildcard.lereta.com.key
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = TLSv1,SSLv3
smtpd_tls_security_level = may
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550

-- 
Stephen Carville

Re: All my email are 5 minutes delayed

[mouss]

Alexis Ducastel a écrit :
> Hello,
> 
> I've postfix width dkim-filter installed. Each mail sent from sendmail ,
> or coming from internet before to be forwarded are delayed of 5 min.
> Not 4'30, not 5'10 ... but exactly 5 min ! according to received
> headers, it seems like postfix keep it 5 min after dkim doing signature.
> 
> I searched in postconf |grep everything that contains 300 seconds (5min)
> but nothing relevant in my opinion.
> 
> In facts, this postfix is only used for aliases , coupled with a MySQL.
> 
> Does anybody knows where is the problem please ? 
> 
> Thanks a lot.
> 
> Alexis Ducastel
> =
> Here is my complete main.cf  if it could help : 

Please show
- output of 'postconf -n', not main.cf.
- contents of master.cf.
- headers that show the 5 min delay
and if possible,
- relevant logs

feel free to hide private infos, but do so coherently.


> [snip] 

Re: Sending bounce notifications to postmaster

[Wietse Venema]

Stephen Carville:
> I need user non-delivery notifications to be CCed to postmaster.  At
> least the headers need to be sent.   Right I have the double bounces
> being sent by adding "2bounce" to notify_classes.   I tried adding
> "bounce" to notify_classes but that seemed to send an email for every
> time postfix rejected a message.  Considering over 25,000 messages get
> rejected a day that's not too useful to me.
> 
> How do I get non-delivery notifications -- at least the headers --
> sent to postmaster too?  Without thousands of transaction snippets
> flooding the inbox?

Assuming that you aren't sending these to your primary inbox, you
could use a simple pipe-to-command filter that drops "transcript
of session follows" notices if you don't want to see bounce reports
for inbound mail.

When I built notify_classes, it did not seem necessary to have a
different bounce option for different bounce types. Now, everyone
would have their favorite way of selecting them (inbound, remote,
local, different settings for different protocols, and more).

Wietse

Re: Patch: support BURL

[Charles Marcus]

On 2010-04-12 1:05 PM, Timo Sirainen wrote:
> Not my client and not really even usable yet, but it started with the
> right ideas: http://trojita.flaska.net/
> 
> I could see myself continuing it instead of starting from scratch..

Like I said, one can only hope... but I'm conflicted... too bad you
can't clone yourself, because there are still some things I'm really
looking forward to in dovecot, like single instance storage...

-- 

Best regards,

Charles

Re: Sending bounce notifications to postmaster

[Stephen Carville]

On Mon, Apr 12, 2010 at 12:30 PM, Wietse Venema  wrote:

> Assuming that you aren't sending these to your primary inbox, you
> could use a simple pipe-to-command filter that drops "transcript
> of session follows" notices if you don't want to see bounce reports
> for inbound mail.

Thank you.  FTTB, I'm redirecting them to my inbox so I can devise a
proper filter.

-- 
Stephen Carville

Postfix compile on OS X 10.6

[Jim Wright]

I'm setting up a new server completely from scratch on Snow Leopard,  
Mac OS X 10.6.3, trying to compile Postfix 2.7.  During make, I get  
this:


In file included from dns_lookup.c:152:
dns.h:23:29: error: nameser8_compat.h: No such file or directory
make: *** [dns_lookup.o] Error 1
make: *** [update] Error 1


I haven't seen this come up on the list yet, so I wanted to report  
this here.  A google search found a suggested fix, in /src/util/ 
sys_defs.h, the following line should be commented out:


#define RESOLVE_H_NEEDS_NAMESER8_COMPAT_H

With this line commented out, I'm able to get a good build.  My  
question is, should I be worried about screwing something up having  
this line commented out? I'm sure it's there for a reason.  (grin)


Thanks.

Cyrus-IMAPD, Postfix, LDAP, spamc and aliases

[take]

Hello!

I'm building an fresh multidomain environment with Debian Lenny. I've
installed and configured postfix, spamc and cyrus-imapd and things are
running almost smoothly.

I can send email everywhere just fine via SMTPS, including my own host.
Since I'm on a testing stage I haven't tried to actually use that as an MX
for any host, so for now I'm stuck at local delivery for incoming mail.

Currently I have only one user, let's call him Jack Doe, and user account
is stored to LDAP. I've manually created the account and folders for cyrus
and I can login and use the service just fine via IMAP. Now when I try to
send mail to jack@myhost.foo it's delivered just fine via local
SMTP(S) and things work as they should.

The problem now is that Jack has fw aliases, let's say j...@myhost.foo and
sa...@myhost.foo. These addresses doesn't work and I'm not sure if this is
an postfix or an cyrus -problem. Postfix recognizes the alias and tries to
deliver it via LMTP, just the same way than it does with 'actual' address.
However since there's no mailbox for 'j...@myhost.foo' cyrus LMTP fails:
cyrus/lmtpunix[12084]: verify_user(myhost.foo!user.jack) failed: Mailbox
does not exist
cyrus/lmtpunix[12084]: telling master 1

Now, based on what I understand, postfix should expand aliases (from the
LDAP) and deliver the mail with 'actual' address, instead of aliased one.
I have these on my conf:
alias_maps = ldap:/etc/postfix/ldap-alias.cf
virtual_alias_maps = ldap:/etc/postfix/ldap-alias.cf

And, again as far as I can understand, aliases itself seem to work. It's
the transport which doesn't work as it should. On master.cf I have this:
cyrus unix - n n - - pipe flags= user=cyrus argv=/usr/sbin/cyrdeliver -r
${sender} -m ${extension} ${recipient}

I've tried to search solution via google and pretty much every other way I
can imagine, but couldn't find any solution. The closest thing I found was
that some other have had this same problem, but most of the solutions were
"Works for me", which isn't really helpful on my case.

Hopefully someone can help me out here, thanks in advance.

-- 
Take

TLS Exception for Remote Sender

[Franck MAHE]

Hi,

My postfix is configured to accept TLS communication in opportunistic mode.

It works fine but I've some trouble with one remote SMTP server (the result is 
my account is desactivated as they are not able to send me emails - TLS Error).

How to force some remote smtp server not to use TLS? I found the way for me to 
use the clear communication to send emails to specific domains, but I'm not 
able to find a solution for my issue. Any clue?

Thanks


Franck

==
M: +33 6 6042 7249
E: m...@civis.net
==

Re: TLS Exception for Remote Sender

[Victor Duchovni]

On Tue, Apr 13, 2010 at 06:38:06AM +, Franck MAHE wrote:

> How to force some remote smtp server not to use TLS? I found the way
> for me to use the clear communication to send emails to specific domains,
> but I'm not able to find a solution for my issue. Any clue?


http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keyword_address_maps

main.cf:
smtp_discard_ehlo_keyword_address_maps = 
cidr:${config_directory}/ehlo_maps.cidr

ehlo_maps.cidr
192.0.2.1   STARTTLS

If their sender IPs are not stable or predictable enough, it is their
problem to fix, the Postfix TLS implementation is robust.

If you want to understand why the problem is happening, you need to
capture a full SMTP session (complete packet capture not just headers)
and use wireshark or similar to analyze the SSL handshake. Or upload
the binary packet PCAP file (filter out just one complete TCP session from
SYN to FIN) somewhere and post the URL.

-- 
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.