Re: Queue directories on faster media?

[Ralf Hildebrandt]

* Ori Bani :
> Hello,
> 
> I'm curious to get feedback on the idea of mounting all the postfix
> queue directories on a faster media (SSD drive in this case).
> 
> In my case, I have virtual maildirs under /var/spool/postfix and those
> would be relocated to elsewhere (onto slower normal media) because the
> faster (SSD) media isn't in a RAID configuration (slower media is).

Why are you storing maildirs in the queue directory?
 
> Does that make any sense?  Is there adverse risk putting the queue
> directories on non-RAID fast media?  Am I right to think that that's
> where the most performance is to be gained?

Yep.

> I guess you could put some queue directories in tmpfs, but that seems
> even more risky, a little too risky.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Queue directories on faster media?

[Ori Bani]

On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt
 wrote:
> * Ori Bani :
>> Hello,
>>
>> I'm curious to get feedback on the idea of mounting all the postfix
>> queue directories on a faster media (SSD drive in this case).
>>
>> In my case, I have virtual maildirs under /var/spool/postfix and those
>> would be relocated to elsewhere (onto slower normal media) because the
>> faster (SSD) media isn't in a RAID configuration (slower media is).
>
> Why are you storing maildirs in the queue directory?

I think it is a legacy thing from a very old how-to.  Note it's for
virtual accounts, so no /home directories.  What's the more standard
place to put them if I may ask?

>> Does that make any sense?  Is there adverse risk putting the queue
>> directories on non-RAID fast media?  Am I right to think that that's
>> where the most performance is to be gained?
>
> Yep.

Thanks.  Would it be OK to put everything in /var/spool/postfix on
fast media or do only some directories benefit from the speed
increase?

Success DSNs From <> Come to Postmaster

[Sabahattin Gucukoglu]

Is it a bug or a feature that success DSNs requested for the null sender come 
to the postmaster?

I vote bug. :-)

Any workarounds to prevent this in the meantime?

Cheers,
Sabahattin

Re: Queue directories on faster media?

[Stan Hoeppner]

On 1/30/2012 1:47 AM, Ori Bani wrote:

> Does that make any sense?  Is there adverse risk putting the queue
> directories on non-RAID fast media?

SSDs, both MLC and SLC, do fail, just not the same failure modes as
SRDs.  Thus you need to use a mirrored pair for the Postfix spool, just
as you'd do with spinning rust discs.

I've owned a total of 1 SSD, an MLC consumer Corsair model.  It failed
after 3 months.  The replacement has lasted longer (knocks on wood).
Not used in a server role but a desktop.  Failed due to poor QC, not
write load.

-- 
Stan

Re: Success DSNs From <> Come to Postmaster

[Wietse Venema]

Sabahattin Gucukoglu:
> Is it a bug or a feature that success DSNs requested for the null sender come 
> to the postmaster?
> 
> I vote bug. :-)
> 
> Any workarounds to prevent this in the meantime?

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

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Outlook 2003 Client SASL Login Problem?

[James Seymour]

Hi All,

Just upgraded our mailserver.  Thought I had everything set the same as
I did with the old one.  Nonetheless, of all the people who *can't*
send email, it would have to be the President of the company.

I do have "broken_sasl_auth_clients = yes".  Postfix version is 2.7.0,
running on an Ubuntu 10.04.3 LTS.  Dovecot is version 1.2.9.

Other SASL parameters from "postconf -n" ...

smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

Relevant master.cf config

smtps inet  n   -   -   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o syslog_name=postfix/smtps

The only difference between the old master.cf and the new is the
addition of the smtpd_client_restrictions line and the syslog_name
line.

The Outlook 2007 client I used to test Outlook functionality with the
new server works fine.  The Outlook 2003 client acts like it's not
logging in.  I verified it *is* set to login to SMTPS using the same
login information as the POP3S login (which works fine).  I even
manually configured-in the user's logname and password separately, to
no avail.

Google searches thus far have not been helpful.

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Outlook 2003 Client SASL Login Problem?

[Reindl Harald]

Am 30.01.2012 14:47, schrieb James Seymour:
> Hi All,
> 
> Just upgraded our mailserver.  Thought I had everything set the same as
> I did with the old one.  Nonetheless, of all the people who *can't*
> send email, it would have to be the President of the company.
> 
> I do have "broken_sasl_auth_clients = yes".  Postfix version is 2.7.0,
> running on an Ubuntu 10.04.3 LTS.  Dovecot is version 1.2.9.
> 
> Other SASL parameters from "postconf -n" ...
> 
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> 
> Relevant master.cf config
> 
> smtps inet  n   -   -   -   -   smtpd
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>   -o syslog_name=postfix/smtps
> 
> The only difference between the old master.cf and the new is the
> addition of the smtpd_client_restrictions line and the syslog_name
> line.
> 
> The Outlook 2007 client I used to test Outlook functionality with the
> new server works fine.  The Outlook 2003 client acts like it's not
> logging in.  I verified it *is* set to login to SMTPS using the same
> login information as the POP3S login (which works fine).  I even
> manually configured-in the user's logname and password separately, to

at least show some parts of the logfile

but i guess it is a dovecot/outlook-problem
if you enable SPA in outlook 2003 you MUST support NTLM auth
outlook >= 2007 can also use CRAM-MD5

so consider TLS/SSL and do NOT activate SPA in Outlook



signature.asc
Description: OpenPGP digital signature

Re: Outlook 2003 Client SASL Login Problem?

[Noel Jones]

On 1/30/2012 7:47 AM, James Seymour wrote:
> Hi All,
> 
> Just upgraded our mailserver.  Thought I had everything set the same as
> I did with the old one.  Nonetheless, of all the people who *can't*
> send email, it would have to be the President of the company.
> 
> I do have "broken_sasl_auth_clients = yes".  Postfix version is 2.7.0,
> running on an Ubuntu 10.04.3 LTS.  Dovecot is version 1.2.9.
> 
> Other SASL parameters from "postconf -n" ...
> 
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> 
> Relevant master.cf config
> 
> smtps inet  n   -   -   -   -   smtpd
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>   -o syslog_name=postfix/smtps
> 
> The only difference between the old master.cf and the new is the
> addition of the smtpd_client_restrictions line and the syslog_name
> line.
> 
> The Outlook 2007 client I used to test Outlook functionality with the
> new server works fine.  The Outlook 2003 client acts like it's not
> logging in.  I verified it *is* set to login to SMTPS using the same
> login information as the POP3S login (which works fine).  I even
> manually configured-in the user's logname and password separately, to
> no avail.
> 
> Google searches thus far have not been helpful.
> 
> Thanks,
> Jim

Are others able to use SASL?  Are they using the smtps service?

Please show all logging when the client tries to send mail, from
connect to disconnect and everything in between.

Please show "postconf -n" output.


  -- Noel Jones

Re: Outlook 2003 Client SASL Login Problem?

[Wietse Venema]

James Seymour:
> Hi All,
> 
> Just upgraded our mailserver.  Thought I had everything set the same as
> I did with the old one.  Nonetheless, of all the people who *can't*
> send email, it would have to be the President of the company.

Have you compared the SMTP server EHLO replies (with openssl s_client)?

Wietse

Re: Outlook 2003 Client SASL Login Problem?

[James Seymour]

On Mon, 30 Jan 2012 14:51:51 +0100
Reindl Harald  wrote:

> 
[snip]
> 
> at least show some parts of the logfile

Very well.  Not much to see...

Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail
postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1
: Client host
rejected: Access denied; from=
to= proto=ESMTP helo= Jan 29
20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from
c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]

> 
> but i guess it is a dovecot/outlook-problem
> if you enable SPA in outlook 2003 ...
[snip]

It is not enabled.

On Mon, 30 Jan 2012 07:57:27 -0600
Noel Jones  wrote:

[snip]
> 
> Are others able to use SASL?  Are they using the smtps service?

Yes and yes.

> 
> Please show all logging when the client tries to send mail, from
> connect to disconnect and everything in between.

Above.

> 
> Please show "postconf -n" output.

As you wish...

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = pcre:/etc/postfix/body_checks
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = mail/inbox
inet_interfaces = all
mailbox_size_limit = 25600
masquerade_domains = 
message_size_limit = 2048
mydestination = 
myhostname = mail
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
recipient_delimiter = +
relayhost = 
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_sender,reject_unknown_sender_domain,check_client_access 
hash:/etc/postfix/client_checks,permit_sasl_authenticated,
reject_unauth_destination,reject
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_cert_file = /etc/ssl/certs/server.crt
smtpd_tls_key_file = /etc/ssl/private/myserver.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
soft_bounce = no

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Outlook 2003 Client SASL Login Problem?

[James Seymour]

On Mon, 30 Jan 2012 09:08:55 -0500 (EST)
Wietse Venema  wrote:

[snip]
> 
> Have you compared the SMTP server EHLO replies (with openssl
> s_client)?

No.  That'd be difficult, tho not impossible, to do at this point, as
the old server is up in storage.

But this is certainly an Outlook 2003 -specific problem.  Claws-Mail
works fine, Thunderbird works fine, and Outlook 2007 works fine.  All
were tested against both submission and smtps.

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Outlook 2003 Client SASL Login Problem?

[Reindl Harald]

Am 30.01.2012 15:16, schrieb James Seymour:
> On Mon, 30 Jan 2012 14:51:51 +0100
> Reindl Harald  wrote:
> 
>>
> [snip]
>>
>> at least show some parts of the logfile
> 
> Very well.  Not much to see...
> 
> Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail
> postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1
> : Client host
> rejected: Access denied; from=
> to= proto=ESMTP helo= Jan 29
> 20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]

enough to see what happens or not!
if there is no SASL attempt
if you get connect followed directly by NOQUEUE the was no attempt

verify this with " | grep -i sasl | grep 68.43.238.106" to your logfile

postfix will log a sasl login (also if it has failed):
Jan 30 15:14:13 mail postfix/smtpd[21979]: 941D791: 
client=chello084112016179.9.11.vie.surfer.at[84.112.16.179],
sasl_method=CRAM-MD5, sasl_username=*






signature.asc
Description: OpenPGP digital signature

RE: Indiscriminate maildir processing

[Eric Chandler]

>The above simple example catches *EVERYTHING* and is suitable to be
used in a lab or test setting.  This is consistent with the initial
request as I understand it.

>If the request was incomplete, it should be clarified.

Yes, I want to catch everything. The dev/qa environments use different
MTAs than production. The two environments contain approximately 1,500
linux/solaris hosts and, although they all run postfix, I don't have
control over their applications that utilize it. Basically, it's BECAUSE
they've had a bad history of flooding our corporate exchange servers
with garbage that I want to create a place to store all emails they
send, at-least long enough for those who want to see what they created
can read them, before they are summarily-deleted automatically. It's
partially a punishment to them for their lack of understanding of what
emails can do to other systems, and partially to protect Exchange from
filling up with garbage.

My hope is that I could create a separate maildir for each recipient,
no-matter if the recipient has a standard corporate email address, or
even r...@postfix.org for all intents and purposes. I could easily write
a cron to go down through all the maildirs and cull old stuff older than
say a week. People who want to see what the emails contain could then
imap in as whatever userid they want (another area for me to figure out
- passwordless-imapd) and see those emails.

Thanks,

Eric

Re: Outlook 2003 Client SASL Login Problem?

[Noel Jones]

On 1/30/2012 8:16 AM, James Seymour wrote:
> On Mon, 30 Jan 2012 14:51:51 +0100
> Reindl Harald  wrote:
> 
>>
> [snip]
>>
>> at least show some parts of the logfile
> 
> Very well.  Not much to see...
> 
> Jan 29 20:42:26 mail postfix/smtps/smtpd[7781]: connect from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106] Jan 29 20:42:27 mail
> postfix/smtps/smtpd[7781]: NOQUEUE: reject: RCPT from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]: 554 5.7.1
> : Client host
> rejected: Access denied; from=
> to= proto=ESMTP helo= Jan 29
> 20:42:32 mail postfix/smtps/smtpd[7781]: disconnect from
> c-68-43-238-106.hsd1.mi.comcast.net[68.43.238.106]
> 

If the client attempts SASL, postfix will log either success or
failure.  Looks as if the client didn't even try.

Maybe client didn't like any of the AUTH methods offered.  Now would
be a good time to connect to postfix/smtps with openssl s_client and
see what AUTH mechanisms are being offered.  I'm pretty sure Outlook
2003 needs either PLAIN or LOGIN (and no reason to not offer both).


>> Please show "postconf -n" output.
> 

Thanks, no glaring errors here.




  -- Noel Jones

Re: Indiscriminate maildir processing

[Noel Jones]

On 1/30/2012 9:10 AM, Eric Chandler wrote:
> My hope is that I could create a separate maildir for each recipient,
> no-matter if the recipient has a standard corporate email address, or

Creating wildcard users is more complicated.

You can easily wildcard virtual domains with
virtual_mailbox_domains = static:all
but wildcarding virtual users is trickier since you can't use $N
substitution in virtual_mailbox_maps.

I expect you could use a *sql map for the mailbox maps and structure
your query so it returns an answer for every user, but I can't help
with that.

> imap in as whatever userid they want (another area for me to figure out
> - passwordless-imapd) and see those emails.


dovecot master user feature, or a sql query in the auth backend that
uses the same password for everybody.



  -- Noel Jones

Re: Outlook 2003 Client SASL Login Problem?

[James Seymour]

On Mon, 30 Jan 2012 09:21:36 -0600
Noel Jones  wrote:

[snip]
> 
> If the client attempts SASL, postfix will log either success or
> failure.  Looks as if the client didn't even try.

Exactly.  And that should've been my clue that the mechanism(s) offered
weren't to the client's liking.

Wietse picked up on it, right off, tho.  But I kept screwing-around,
looking elsewhere, until you also suggested...

> 
> Maybe client didn't like any of the AUTH methods offered.  Now would
> be a good time to connect to postfix/smtps with openssl s_client and
> see what AUTH mechanisms are being offered.  I'm pretty sure Outlook
> 2003 needs either PLAIN or LOGIN (and no reason to not offer both).
[snip]

LOGIN was what it wanted.  PLAIN was all that was being offered.

Changed dovecot.com, restarted dovecot and postfix, and all's well.

Thanks for your help, everybody!

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: Queue directories on faster media?

[/dev/rob0]

On Mon, Jan 30, 2012 at 01:09:29AM -0800, Ori Bani wrote:
> On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt
>  wrote:
> > * Ori Bani :
> >> I'm curious to get feedback on the idea of mounting all the
> >> postfix queue directories on a faster media (SSD drive in
> >> this case).
> >>
> >> In my case, I have virtual maildirs under /var/spool/postfix
> >> and those would be relocated to elsewhere (onto slower normal
> >> media) because the faster (SSD) media isn't in a RAID
> >> configuration (slower media is).
> >
> > Why are you storing maildirs in the queue directory?
> 
> I think it is a legacy thing from a very old how-to.

Having recently written a Postfix howto, I reviewed quite a few 
others in the process. With few exceptions I found that they were 
written by people with a poor understanding of Postfix. This was 
especially true of the old, unmaintained howto documents.

> Note it's for virtual accounts, so no /home directories.

A virtual user should have a $HOME, but perhaps that is not what 
you're talking about. In my own system I happen to use
virtual_mailbox_base = /home
because that filesystem has the most room for storage.

> What's the more standard place to put them if I may ask?

There is no standard, as shown by the default postconf(5) value of 
$virtual_mailbox_base. However there is the official Postfix 
VIRTUAL_README.html#virtual_mailbox document, which uses this:
virtual_mailbox_base = /var/mail/vhosts

As hinted above, I suggest sticking with the official Postfix 
documentation. Look at third-party howtos for ideas, but you 
shouldn't rely on them for exact guidance. When their ideas don't 
mesh with what is in Postfix documentation, consider the entire 
document to be of dubious quality.

> >> Does that make any sense? Is there adverse risk putting the
> >> queue directories on non-RAID fast media? Am I right to think
> >> that that's where the most performance is to be gained?
> >
> > Yep.
> 
> Thanks.  Would it be OK to put everything in /var/spool/postfix
> on fast media or do only some directories benefit from the
> speed increase?

I wouldn't think it worth the trouble to try to separate actual 
queues from the few other files under /var/spool/postfix/. But then, 
I am not sure that there is an actual problem that this idea will 
solve. :)

We here tend to want to focus on real problems. If everything is 
working well, don't tinker. Postfix default settings generally are 
good; a competently-managed system's "postconf -n" should typically 
be very short.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

RE: Indiscriminate maildir processing

[Eric Chandler]

Ok, I think for me the easiest way will be to simply port it out to a
milter to do the job and simply discard the message.  I'm very good a
milter code, so that will probably allow me to do all sorts of special
stuff on top of what I would eventually get out of postfix configuration
magic, given the oddball task I'm trying to accomplish.  Thanks for
everyone's help.

Eric Chandler
Systems Architect


-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones
Sent: Monday, January 30, 2012 10:34 AM
To: postfix-users@postfix.org
Subject: Re: Indiscriminate maildir processing

On 1/30/2012 9:10 AM, Eric Chandler wrote:
> My hope is that I could create a separate maildir for each recipient, 
> no-matter if the recipient has a standard corporate email address, or

Creating wildcard users is more complicated.

You can easily wildcard virtual domains with virtual_mailbox_domains =
static:all but wildcarding virtual users is trickier since you can't use
$N substitution in virtual_mailbox_maps.

I expect you could use a *sql map for the mailbox maps and structure
your query so it returns an answer for every user, but I can't help with
that.

> imap in as whatever userid they want (another area for me to figure 
> out
> - passwordless-imapd) and see those emails.


dovecot master user feature, or a sql query in the auth backend that
uses the same password for everybody.



  -- Noel Jones

Re: Queue directories on faster media?

[Simon Brereton]

On 30 January 2012 12:49, /dev/rob0  wrote:
> On Mon, Jan 30, 2012 at 01:09:29AM -0800, Ori Bani wrote:
>> On Mon, Jan 30, 2012 at 12:42 AM, Ralf Hildebrandt
>>  wrote:
>> > * Ori Bani :
>> >> I'm curious to get feedback on the idea of mounting all the
>> >> postfix queue directories on a faster media (SSD drive in
>> >> this case).
>> >>
>> >> In my case, I have virtual maildirs under /var/spool/postfix
>> >> and those would be relocated to elsewhere (onto slower normal
>> >> media) because the faster (SSD) media isn't in a RAID
>> >> configuration (slower media is).
>> >
>> > Why are you storing maildirs in the queue directory?
>>
>> I think it is a legacy thing from a very old how-to.
>
> Having recently written a Postfix howto, I reviewed quite a few

URL please? :)

Simon

Re: Queue directories on faster media?

[Viktor Dukhovni]

On Sun, Jan 29, 2012 at 11:47:39PM -0800, Ori Bani wrote:

> I'm curious to get feedback on the idea of mounting all the postfix
> queue directories on a faster media (SSD drive in this case).

The answer depends on your real goals. Mounting the spool on an
SSD is only your real goal if you're are a compulsive tinkerer.
Otherwise, you're trying to solve some problem that's motivating
this question, so state that instead.

> In my case, I have virtual maildirs under /var/spool/postfix

This is a bad idea. The /var/spool/postfix directory is just for
the Postfix queue (messages in transit). Do not deliver mail there.
Ideally deliver mail into a separate file-system that does not
compete for space with the Postfix queue.

> Does that make any sense?  

Not without a reason to consider SSD. Do however avoid using
/var/spool/postfix for user maildirs, that's a mistake.

-- 
Viktor.

Re: Queue directories on faster media?

[Ori Bani]

On Mon, Jan 30, 2012 at 10:27 AM, Viktor Dukhovni
 wrote:
> On Sun, Jan 29, 2012 at 11:47:39PM -0800, Ori Bani wrote:
>
>> I'm curious to get feedback on the idea of mounting all the postfix
>> queue directories on a faster media (SSD drive in this case).
>
> The answer depends on your real goals. Mounting the spool on an
> SSD is only your real goal if you're are a compulsive tinkerer.

Haha.  :)

> Otherwise, you're trying to solve some problem that's motivating
> this question, so state that instead.

No, no problem.  Only attempting to future-proof things.  I anticipate
mail volume to grow in the future, and as I have access to SSD, I
thought maybe postfix would run faster using it under its queues.  Is
this not the case?

>> In my case, I have virtual maildirs under /var/spool/postfix
>
> This is a bad idea. The /var/spool/postfix directory is just for
> the Postfix queue (messages in transit). Do not deliver mail there.
> Ideally deliver mail into a separate file-system that does not
> compete for space with the Postfix queue.

Point taken, glad I accidentally bumped into this advice.

Re: Queue directories on faster media?

[Viktor Dukhovni]

On Mon, Jan 30, 2012 at 12:00:08PM -0800, Ori Bani wrote:

> > Otherwise, you're trying to solve some problem that's motivating
> > this question, so state that instead.
> 
> No, no problem.  Only attempting to future-proof things.  I anticipate
> mail volume to grow in the future, and as I have access to SSD, I
> thought maybe postfix would run faster using it under its queues.  Is
> this not the case?

Generally, there is no performance advantage, unless the disk is
a significant bottleneck for your workload. If you're receiving
mail, generally the bottleneck is content inspection.

If you're sending mail at under 100 msgs/sec, or virus-scanning
outbound mail, a modern server with a RAID controller with a BBU,
will be plenty fast. If you to get well north of ~300 msgs/sec,
then perhaps you need a faster disk, or more machines, whichever
is more cost effective.

For a sufficiently expensive SSD, another server may be a better
option, though cost of cooling, power and data-center space also
comes into the equation.

--
Viktor.

Re: Queue directories on faster media?

[Ralf Hildebrandt]

> > Why are you storing maildirs in the queue directory?
> 
> I think it is a legacy thing from a very old how-to.  Note it's for
> virtual accounts, so no /home directories.  What's the more standard
> place to put them if I may ask?

Anywhere else, like /var/spool/mail (just an idea)

> Thanks.  Would it be OK to put everything in /var/spool/postfix on
> fast media or do only some directories benefit from the speed
> increase?

I would put ONLY the WHOLE queue directory there.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Success DSNs From <> Come to Postmaster

[Ralf Hildebrandt]

* Sabahattin Gucukoglu :

> Is it a bug or a feature that success DSNs requested for the null sender come 
> to the postmaster?

Show logs for this please.
Show postconf -n output

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Behavior of postscreen_access_list = static:retry

[Mark Alan]

Hello,

Regarding the config option:
  postscreen_access_list = static:retry

And considering that:

 1) "Permanent white/blacklist for remote SMTP client
IP addresses. postscreen(8) searches this list immediately after a
remote SMTP client connects."

 2) static is a valid lookup table type

 3) the similar syntax of 'transport_maps = static:retry'

Shouldn't:
 postconf -e 'postscreen_access_list = static:retry' ; postfix reload

immediately make postscreen defer all incoming email?

Is there any other way to make the postscreen/postfix combination
temporarily defer all incoming emails with '450 4.3.2 Service
currently unavailable' (in order to give us some time to migrate
the postfix server to some other IP) ?

Thank you,

M.

Re: Behavior of postscreen_access_list = static:retry

[Viktor Dukhovni]

On Mon, Jan 30, 2012 at 09:03:39PM +, Mark Alan wrote:

> Regarding the config option:
>   postscreen_access_list = static:retry

Where is "retry" documented as a valid access list keyword?

>  3) the similar syntax of 'transport_maps = static:retry'

The transport table is not access(5) table, and "retry" is a
transport, not an access keyword.

> Shouldn't:
>  postconf -e 'postscreen_access_list = static:retry' ; postfix reload
> 
> immediately make postscreen defer all incoming email?

It should probably cause postscreen to log warnings about
misconfiguration.

> Is there any other way to make the postscreen/postfix combination
> temporarily defer all incoming emails with '450 4.3.2 Service
> currently unavailable' (in order to give us some time to migrate
> the postfix server to some other IP) ?

The documentation for the "postscreen_access_list" parameter.

-- 
Viktor.

Re: Behavior of postscreen_access_list = static:retry

[Mark Alan]

On Mon, 30 Jan 2012 21:09:21 +, Viktor Dukhovni
 wrote:

> > Is there any other way to make the postscreen/postfix combination
> > temporarily defer all incoming emails with '450 4.3.2 Service
> > currently unavailable' (in order to give us some time to migrate
> > the postfix server to some other IP) ?
> 
> The documentation for the "postscreen_access_list" parameter.

Would the following be an acceptable way to do it?
  postconf -e 'postscreen_access_list = reject'
  postconf -e 'soft_bounce = yes'


M.

Re: Behavior of postscreen_access_list = static:retry

[Viktor Dukhovni]

On Mon, Jan 30, 2012 at 09:26:42PM +, Mark Alan wrote:

> > > Is there any other way to make the postscreen/postfix combination
> > > temporarily defer all incoming emails with '450 4.3.2 Service
> > > currently unavailable' (in order to give us some time to migrate
> > > the postfix server to some other IP) ?

Just turn off the SMTP listener. This functionally identical to a
4.X.X reject and saves resources on both client and server.

> > The documentation for the "postscreen_access_list" parameter.
> 
> Would the following be an acceptable way to do it?
>   postconf -e 'postscreen_access_list = reject'
>   postconf -e 'soft_bounce = yes'

Only if this is documented. The soft_bounce parameter is listed on
the postscreen(8) manpage, this is perhaps a sufficient promise to
match user expectations and so I would expect it to work.

This said, it is far simpler to turn off SMTP service.

# postconf -e 'master_service_disable = inet'
# postfix reload

with appropriate adjustments if the target is a non-default instance.

-- 
Viktor.

Recipient verification with greylisting servers for bonehead clients

[Daniel L. Miller]

Kind of thinking out loud here - not sure anything can/should be done.

Recipient address verification means - to me - that the recipient 
address has been pre-qualified by our server.  So when a user presses 
"send" on their client, and the message disappears into the mysterious 
ether - I'm reasonably confident their message went SOMEWHERE.


Without recipient address verification - when the user presses "Send" - 
my server takes the message and tries to send it.  And until the user 
gets a delivery failed notice - they mistakenly believe the instant the 
message leaves their screen it has reached its destination.


Which leaves the sysop a choice - either have the users complain that 
their mail is broken (when the "recipient verification in progress" 
message appears - and it doesn't matter how many flipping times you tell 
them to READ the g*dd@mn thing - especially when you can see the 
spelling error right in front of them!) or have the users complain that 
their mail is broken because even though they pushed Send the recipient 
"never got the message".


I've opted for the first - but I'm wondering if the end-user experience 
can be improved at all - particularly for those who refuse to be 
educated, and unfortunately the world is full of those.  What about a 
blend of the two operations?  What if, on a non-verified address, and 
verify receives a defer error (which means we've actually reached a mail 
server - not necessarily the correct one, and the address can still be 
wrong, but our chances are pretty good now) to go ahead and accept the 
mail from the client - but immediately return a message that indicates 
verification is in progress.  And then repeat those status messages 
until successful delivery or it gives up.


It increases the chance for having garbage in the queue - as it doesn't 
allow the user to read (what's that mean?!) the message and self-correct 
their typos - but it could increase user efficiency.  Any thoughts?  Am 
I underthinking this as usual?


--
Daniel

Re: Success DSNs From <> Come to Postmaster

[Wietse Venema]

Ralf Hildebrandt:
> * Sabahattin Gucukoglu :
> 
> > Is it a bug or a feature that success DSNs requested for the null sender 
> > come to the postmaster?
> 

Here's what happens. First, mail to the null address goes to
MAILER-DAEMON by default:

empty_address_recipient (default: MAILER-DAEMON)
   The recipient of mail addressed to the null address. Postfix
   does not accept such addresses in SMTP commands, but they
   may still be created locally as the result of configuration
   or software error.

Second, it's common to have an alias MAILER-DAEMON -> postmaster,
so that explains why the mail for <> ends up there.

Postfix sends delivery notifications as mail from <>. When this
first-order notification fails, Postfix will attempt to deliver a
second-order notification to the 2bounce_notice_recipient (default:
postmaster) as a final attempt to avoid loss of mail.  

This handling of fail/delay notifications satisfies the RFC's
requirement of never responding to the <> sender address.

However, the code that handles NOTIFY=SUCCESS fails to satisfy that
RFC requirement. It was written several years earlier to implement
support for "sendmail -bv" and "sendmail -v", and was not updated
when it was put into service to also handle SUCCESS notifications.

I'll make the NOTIFY=SUCCESS handling consistent with fail/delay.

Wietse

Basic sending concurrency question

[Peter Scott]

Hello.  I'm very new to Postfix configuration; I switched from Sendmail 
because I want to send mail through the Amazon Simple Email Service and 
Postfix has concurrency options that were easier to understand.  
However, they're not doing what I want and the mail is going too slow.


Sending mail via Amazon happens via piping it to a program that makes an 
HTTP connection.  This takes about 0.5 seconds.  We have a high volume 
of mail that needs to be delivered at a rate of at least 10 messages per 
second, and our Amazon account supports up to 90/s.  But when I send 
mail with sendmail.postfix it appears synchronous, i.e., takes 0.5 s to 
return.  Amazon says that concurrency is the way to increase the rate: 
make multiple simultaneous connections.


I was hoping that Postfix would do this for me, i.e., that calling 
sendmail.postfix would return instantly, queueing the message up and 
executing as many parallel connections as it was configured for.  It 
doesn't; either I haven't configured it right or I'm wrong about how 
sending works.  I could of course background each call to 
sendmail.postfix but then I'd have to do my own concurrency management 
to throttle the number of simultaneous processes I had running that, and 
that seems to me to be exactly what Postfix should be doing for me.


Part of my main.cf:

default_transport = aws-email
default_destination_concurrency_limit = 1000
aws-email_destination_concurrency_limit = 1000
default_process_limit = 1000

Part of my master.cf:

aws-email  unix  -   n   n   -   0   pipe
  flags=R user=mail argv=/path/to/ses-send-email.pl [...] -f ${sender} 
${recipient}


I'm sending mail with:

/usr/lib/sendmail.postfix -t -f

Is it possible to send mail with a faster return than 0.5 seconds and 
have Postfix manage the sending queue for me with concurrency?  What am 
I missing, please?

Re: Basic sending concurrency question

[Peter Scott]

I wrote:

I could of course background each call to
sendmail.postfix but then I'd have to do my own concurrency management
to throttle the number of simultaneous processes I had running that, and
that seems to me to be exactly what Postfix should be doing for me.


I tried this approach, and it didn't help.  I was able to put 20 
messages in the outbound queue in 0.25 seconds, but it still took 10 
seconds to flush the queue, indicating no sending concurrency.

Mail stuck (Connection Timed-Out)

[Gonzo Fernandez]

Hi All,

My relay servers have mail being received but unable to send. When I type 
"mailq" I see: Delivery temporarily suspended….Connection timed out. I also 
noticed this line:

Tarpitting active for [1.2.3.4)

I restarted postfix, flushed mailq and still everything is stuck. Now the mail 
is building up and I don't know what else to do. I'm still continuing to work 
on it but I figure I might as well ask the postfix team members. Can anyone 
help me figure this thing out please? 

mailq:

Jan 30 13:53:27 mx-ca4-01 postfix/qmgr[26443]: BC535E8264: 
from=, size=805, nrcpt=1 (queue active)
Jan 30 13:53:55 mx-ca4-01 postfix/qmgr[26443]: BC535E8264: to=, 
relay=none, delay=357647, delays=357619/28/0/0, dsn=4.4.1, status=deferred 
(delivery temporarily suspended: connect to mail.com[1.2.3.4]: Connection timed 
out)


I set this line up in main.cf and it did help a little bit: 
smtpd_error_sleep_time = 0

Here's my postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
disable_vrfy_command = yes
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 1.2.3.0/24, 1.2.3.0/24, 1.2.3.0/24, 1.2.3.0/24, 1.2.3.0/24
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_error_sleep_time = 0
unknown_local_recipient_reject_code = 550

Gonzo Fernandez

Re: Mail stuck (Connection Timed-Out)

[Noel Jones]

On 1/30/2012 5:07 PM, Gonzo Fernandez wrote:
> Hi All,
> 
> My relay servers have mail being received but unable to send. When I
> type "mailq" I see: Delivery temporarily suspended….Connection timed
> out. I also noticed this line:
> 
> Tarpitting active for [1.2.3.4)
> 
> I restarted postfix, flushed mailq and still everything is stuck.
> Now the mail is building up and I don't know what else to do. I'm
> still continuing to work on it but I figure I might as well ask the
> postfix team members. Can anyone help me figure this thing out please? 
> 
> mailq:
> 
> Jan 30 13:53:27 mx-ca4-01 postfix/qmgr[26443]: BC535E8264:
> from=mailto:m...@example.com>>, size=805, nrcpt=1
> (queue active)
> Jan 30 13:53:55 mx-ca4-01 postfix/qmgr[26443]: BC535E8264:
> to=mailto:m...@example.com>>, relay=none, delay=357647,
> delays=357619/28/0/0, dsn=4.4.1, status=deferred (delivery
> temporarily suspended: connect to example.com
> [1.2.3.4]: Connection timed out)


(please post in plain-text only)
(please use example.com rather than real domain names.  thanks)


Looks as if the destination 1.2.3.4 doesn't like your server.
You'll need to check with them about why.

One possibility is that you've been flooding them with backscatter
and they've blacklisted you for that.  If that's the problem, the
solution is to not accept mail you can't deliver.

Or maybe you've got a spam-bot on your network that's spewing stuff
they don't like.

But that's just speculation... Only they know the reason.



  -- Noel Jones

Re: Behavior of postscreen_access_list = static:retry

[Mark Alan]

On Mon, 30 Jan 2012 21:50:52 +, Viktor Dukhovni
 wrote:

> On Mon, Jan 30, 2012 at 09:26:42PM +, Mark Alan wrote:
> 
> > > > Is there any other way to make the postscreen/postfix
> > > > combination temporarily defer all incoming emails with '450
> > > > 4.3.2 Service currently unavailable' (in order to give us some
> > > > time to migrate the postfix server to some other IP) ?
> 
> Just turn off the SMTP listener. This functionally identical to a
> 4.X.X reject and saves resources on both client and server.

Thank you Viktor,

In this particular setup I really need to have the server
answering:
"Don't worry, I am alive but right now I am not able to accept your
email", i.e., 450 Service currently unavailable

> > > The documentation for the "postscreen_access_list" parameter.
> > 
> > Would the following be an acceptable way to do it?
> >   postconf -e 'postscreen_access_list = reject'
> >   postconf -e 'soft_bounce = yes'
> 
> Only if this is documented. The soft_bounce parameter is listed on
> the postscreen(8) manpage, this is perhaps a sufficient promise to
> match user expectations and so I would expect it to work.

Sadly it does not.
Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets 
the email pass:

Jan 30 23:12:36 mx postfix/postscreen[11975]: CONNECT from
[74.125.82.181]:61868
 Jan 30 23:12:36 mx postfix/postscreen[11975]: BLACKLISTED
[74.125.82.181]:61868
Jan 30 23:12:42 mx postfix/tlsproxy[11978]: CONNECT from
[74.125.82.181]:61868
 Jan 30 23:12:42 mx postfix/tlsproxy[11978]: setting up TLS connection
from [74.125.82.181]:61868
Jan 30 23:12:42 mx postfix/tlsproxy[11978]: Anonymous TLS connection
established from [74.125.82.181]:61868: TLSv1 with cipher RC4-SHA
(128/128 bits)

> This said, it is far simpler to turn off SMTP service.
>   # postconf -e 'master_service_disable = inet'
>   # postfix reload

That is true. I too prefer to keep setups simpler (and near to the
default configuration).
But in this particular setup it does not help at making my server send, to 
every connection attempt, a 450 Service
currently unavailable .

Again, thank you Viktor for your time.

M.

Re: Behavior of postscreen_access_list = static:retry

[Wietse Venema]

Mark Alan:
> > > Would the following be an acceptable way to do it?
> > >   postconf -e 'postscreen_access_list = reject'
> > >   postconf -e 'soft_bounce = yes'
> > 
> > Only if this is documented. The soft_bounce parameter is listed on
> > the postscreen(8) manpage, this is perhaps a sufficient promise to
> > match user expectations and so I would expect it to work.
> 
> Sadly it does not.
> Although postscreen marks it as BLACKLISTED, then tlsproxy kicks in and lets 
> the email pass:
> 

Only because you failed to configure "postscreen_blacklist_action = drop".

Wietse

SASL authentication and Windows Live Mail

[James Day]

I'll keep this short for now in case it's a known problem but if more logs are 
required let me know.

I've configured postfix to allow SASL authenticated users (dovecot sasl) to 
relay.

I've tested this and confirmed it works from within Outlook 2007 and 2010. 
However trying the same account details from Windows Live Mail throws up a:

"554 Relay Access denied" error message.

Is this a known problem with the Windows Live Mail client or do I need to dig 
deeper?

Kind regards,

James Day

Re: Mail stuck (Connection Timed-Out)

[Gonzo Fernandez]

Thank you Noel. Our server sends out copies of email confirmations to our 
clients and if the client decides to make a large order they end up pushing our 
volume up and we end up getting blocked by their mail server. I seem to be 
getting connection timed out on a lot of the hosts. I even try to telnet to ip 
and port 25 but it keeps timing out. I used "grep" to search in 
/var/log/maillog and I got this. Any ideas?

[root@mx-server ~]# cat /var/log/maillog | grep B0847E8491

Jan 30 08:44:38 mx-server postfix/cleanup[24478]: B0847E8491: 
message-id=<20120130164438.B0847E8491@mxser...@example.com>
Jan 30 08:44:38 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 08:44:38 mx-server postfix/bounce[24473]: 2604BE84D6: sender 
non-delivery notification: B0847E8491
Jan 30 08:45:01 mx-server postfix/smtp[24278]: B0847E8491: 
to=, relay=none, delay=23, delays=0.03/0/23/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 09:08:09 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 09:08:32 mx-server postfix/smtp[24522]: B0847E8491: 
to=, relay=none, delay=1434, delays=1411/0/23/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 09:41:31 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 09:41:52 mx-server postfix/smtp[24793]: B0847E8491: 
to=, relay=none, delay=3434, delays=3412/0.1/21/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 10:48:09 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 10:48:15 mx-server postfix/smtp[25097]: B0847E8491: 
to=, relay=none, delay=7417, delays=7411/0.06/5.9/0, 
dsn=4.4.3, status=deferred (Host or domain name not found. Name service error 
for name=example.com type=A: Host not found, try again)
Jan 30 12:11:30 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 12:11:53 mx-server postfix/smtp[25539]: B0847E8491: 
to=, relay=none, delay=12435, delays=12411/0.05/23/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 13:22:45 mx-server postfix/qmgr[26236]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 13:23:12 mx-server postfix/smtp[26261]: B0847E8491: 
to=, relay=none, delay=16713, delays=16687/0.56/26/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 13:53:27 mx-server postfix/qmgr[26443]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 13:53:55 mx-server postfix/smtp[26593]: B0847E8491: 
to=, relay=none, delay=18556, delays=18529/6.5/21/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 15:14:54 mx-server postfix/qmgr[27600]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 15:15:21 mx-server postfix/smtp[27790]: B0847E8491: 
to=, relay=none, delay=23443, delays=23416/5.9/21/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
[root@mx-server ~]# telnet 1.2.3.4 25
Trying 1.2.3.4...
telnet: connect to address 1.2.3.4: Connection timed out
telnet: Unable to connect to remote host: Connection timed out

Gonzo Fernandez

On Jan 30, 2012, at 3:36 PM, Noel Jones wrote:

> On 1/30/2012 5:07 PM, Gonzo Fernandez wrote:
>> Hi All,
>> 
>> My relay servers have mail being received but unable to send. When I
>> type "mailq" I see: Delivery temporarily suspended….Connection timed
>> out. I also noticed this line:
>> 
>> Tarpitting active for [1.2.3.4)
>> 
>> I restarted postfix, flushed mailq and still everything is stuck.
>> Now the mail is building up and I don't know what else to do. I'm
>> still continuing to work on it but I figure I might as well ask the
>> postfix team members. Can anyone help me figure this thing out please? 
>> 
>> mailq:
>> 
>> Jan 30 13:53:27 mx-server postfix/qmgr[26443]: BC535E8264:
>> from=mailto:m...@example.com>>, size=805, nrcpt=1
>> (queue active)
>> Jan 30 13:53:55 mx-server postfix/qmgr[26443]: BC535E8264:
>> to=mailto:m...@example.com>>, relay=none, delay=357647,
>> delays=357619/28/0/0, dsn=4.4.1, status=deferred (delivery
>> temporarily suspended: connect to example.com
>> [1.2.3.4]: Connection timed out)
> 
> 
> (please post in plain-text only)
> (please use example.com rather than real domain names.  thanks)
> 
> 
> Looks as if the destination 1.2.3.4 doesn't like your server.
> You'll need to check with them about why.
> 
> One possibility is that you've been flooding them with backscatter
> and they've blacklisted you for that.  If that's the problem, the
> solution is to not accept mail you can't deliver.
> 
> Or maybe you've got a spam-bot on your network that's spewing stuff
> they don't like.
> 
> But that's just speculation... Only they know the reason.
> 
> 
> 
>  -- Noel Jones

Re: Mail stuck (Connection Timed-Out)

[Alfonso Alejandro Reyes Jimenez]

Hi it seems to be a layer 3 issue, according to the description I will check 
any firewall or router at the perimeters end.

Have you checked that? Have you tried tcpdump to check if those packets are 
leaving the box?

Thats just a thought, I hope it helps.

Regards.


Saludos 

Ing. Alfonso Alejandro Reyes Jimenez 
Coordinador de Seguridad - SASI 
E-mail: aare...@scitum.com.mx 
Telefono: 91507489 
Movil: (044) 55 85 81 04 62
 

De: Gonzo Fernandez [mailto:go...@usaepay.com] 
Enviado: Monday, January 30, 2012 06:46 PM
Para: postfix users  
Asunto: Re: Mail stuck (Connection Timed-Out) 
 

Thank you Noel. Our server sends out copies of email confirmations to our 
clients and if the client decides to make a large order they end up pushing our 
volume up and we end up getting blocked by their mail server. I seem to be 
getting connection timed out on a lot of the hosts. I even try to telnet to ip 
and port 25 but it keeps timing out. I used "grep" to search in 
/var/log/maillog and I got this. Any ideas?

[root@mx-server ~]# cat /var/log/maillog | grep B0847E8491

Jan 30 08:44:38 mx-server postfix/cleanup[24478]: B0847E8491: 
message-id=<20120130164438.B0847E8491@mxser...@example.com>
Jan 30 08:44:38 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 08:44:38 mx-server postfix/bounce[24473]: 2604BE84D6: sender 
non-delivery notification: B0847E8491
Jan 30 08:45:01 mx-server postfix/smtp[24278]: B0847E8491: 
to=, relay=none, delay=23, delays=0.03/0/23/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 09:08:09 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 09:08:32 mx-server postfix/smtp[24522]: B0847E8491: 
to=, relay=none, delay=1434, delays=1411/0/23/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 09:41:31 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 09:41:52 mx-server postfix/smtp[24793]: B0847E8491: 
to=, relay=none, delay=3434, delays=3412/0.1/21/0, dsn=4.4.1, 
status=deferred (connect to example.com[1.2.3.4]: Connection timed out)
Jan 30 10:48:09 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 10:48:15 mx-server postfix/smtp[25097]: B0847E8491: 
to=, relay=none, delay=7417, delays=7411/0.06/5.9/0, 
dsn=4.4.3, status=deferred (Host or domain name not found. Name service error 
for name=example.com type=A: Host not found, try again)
Jan 30 12:11:30 mx-server postfix/qmgr[16186]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 12:11:53 mx-server postfix/smtp[25539]: B0847E8491: 
to=, relay=none, delay=12435, delays=12411/0.05/23/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 13:22:45 mx-server postfix/qmgr[26236]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 13:23:12 mx-server postfix/smtp[26261]: B0847E8491: 
to=, relay=none, delay=16713, delays=16687/0.56/26/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 13:53:27 mx-server postfix/qmgr[26443]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 13:53:55 mx-server postfix/smtp[26593]: B0847E8491: 
to=, relay=none, delay=18556, delays=18529/6.5/21/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
Jan 30 15:14:54 mx-server postfix/qmgr[27600]: B0847E8491: from=<>, size=3456, 
nrcpt=1 (queue active)
Jan 30 15:15:21 mx-server postfix/smtp[27790]: B0847E8491: 
to=, relay=none, delay=23443, delays=23416/5.9/21/0, 
dsn=4.4.1, status=deferred (connect to example.com[1.2.3.4]: Connection timed 
out)
[root@mx-server ~]# telnet 1.2.3.4 25
Trying 1.2.3.4...
telnet: connect to address 1.2.3.4: Connection timed out
telnet: Unable to connect to remote host: Connection timed out

Gonzo Fernandez

On Jan 30, 2012, at 3:36 PM, Noel Jones wrote:


On 1/30/2012 5:07 PM, Gonzo Fernandez wrote:


Hi All,



My relay servers have mail being received but unable to send. 
When I


type "mailq" I see: Delivery temporarily suspended….Connection 
timed


out. I also noticed this line:



Tarpitting active for [1.2.3.4)



I restarted postfix, flushed mailq and still everything is 
stuck.


Now the mail is building up and I don't know what else to do. 
I'm


still continuing to work on it but I figure I might as well ask 
the


postfix team members. Can anyone help me figure this thing out 
please? 



mailq:



Jan 30 13:53:27 mx-server postfix/qmgr[26443]: BC535E8264:


  

Re: SASL authentication and Windows Live Mail

[Jim Seymour]

On Tue, 31 Jan 2012 00:30:33 +
James Day  wrote:

[snip]
> ... trying the same account details from Windows Live
> Mail throws up a:
> 
> "554 Relay Access denied" error message.
[snip]

IIRC, "Relay access denied" is a symptom of a non-SSL attempted
connection/login when "disable_plaintext_auth = yes" in dovecot.conf.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at .

Re: SASL authentication and Windows Live Mail

[Noel Jones]

On 1/30/2012 9:32 PM, Jim Seymour wrote:
> On Tue, 31 Jan 2012 00:30:33 +
> James Day  wrote:
> 
> [snip]
>> ... trying the same account details from Windows Live
>> Mail throws up a:
>>
>> "554 Relay Access denied" error message.
> [snip]
> 
> IIRC, "Relay access denied" is a symptom of a non-SSL attempted
> connection/login when "disable_plaintext_auth = yes" in dovecot.conf.

The error message means the mail was rejected by
reject_unauth_destination, and that means the client didn't
authenticate (or tried and failed).

If AUTH was tried and failed, it will be noted in the postfix and
dovecot logs.  If no failures are logged, AUTH wasn't attempted.

This may or may not have anything to do with SSL/TLS.  Another good
guess is that dovecot needs to offer LOGIN and/or PLAIN mechanisms.

But we're just guessing here.  We need more details of the
connection and configuration to give more concrete advice.

http://www.postfix.org/DEBUG_README.html#mail


  -- Noel Jones

Re: Mail stuck (Connection Timed-Out)

[Noel Jones]

On 1/30/2012 6:46 PM, Gonzo Fernandez wrote:
> Thank you Noel. Our server sends out copies of email confirmations
> to our clients and if the client decides to make a large order they
> end up pushing our volume up and we end up getting blocked by their
> mail server. I seem to be getting connection timed out on a lot of
> the hosts. I even try to telnet to ip and port 25 but it keeps
> timing out. I used "grep" to search in /var/log/maillog and I got
> this. Any ideas?


This isn't a postfix problem.  If you can't telnet to any client
port 25, then you have a connectivity problem; maybe your ISP is
blocking that port, or some firewall has been misconfigured.
Contact your networking team or your ISP.

If you can't telnet to this one destination port 25, they're
blocking you.  You'll need to contact them to get this resolved.


Good luck.



  -- Noel Jones

Re: Mail stuck (Connection Timed-Out)

[Noel Jones]

On 1/30/2012 10:30 PM, Noel Jones wrote:
> On 1/30/2012 6:46 PM, Gonzo Fernandez wrote:
>> Thank you Noel. Our server sends out copies of email confirmations
>> to our clients and if the client decides to make a large order they
>> end up pushing our volume up and we end up getting blocked by their
>> mail server. I seem to be getting connection timed out on a lot of
>> the hosts. I even try to telnet to ip and port 25 but it keeps
>> timing out. I used "grep" to search in /var/log/maillog and I got
>> this. Any ideas?
> 
> 
> This isn't a postfix problem.  If you can't telnet to any client
> port 25, then you have a connectivity problem; maybe your ISP is
> blocking that port, or some firewall has been misconfigured.
> Contact your networking team or your ISP.
> 
> If you can't telnet to this one destination port 25, they're
> blocking you.  You'll need to contact them to get this resolved.
> 
> 
> Good luck.
> 
> 
> 
>   -- Noel Jones


If the destination can't handle the load you're sending it, you can
slow postfix down.  Details here:
http://www.postfix.org/QSHAPE_README.html#active_congestion

Of course, this won't help until they stop blocking you.

  -- Noel Jones

Re: Mail stuck (Connection Timed-Out)

[Gonzo Fernandez]

I was reading about "Defferred queue full of dictionary attack bounces" which I 
think might be an issue here. 

So i performed a qshape analysis and I got this:

command: qshape deferred | head

 T  5 10 20 40 80 160 320 640 1280 1280+
 TOTAL 583  0  0  0  0  0   1   8  47   25   502
 adbaa.org 214  0  0  0  0  0   0   0   00   214
 onramp.bz 191  0  0  0  0  0   1   6  26   10   148
 unitedimagingpartners.com  62  0  0  0  0  0   0   0   7550
   mmvacations.com  26  0  0  0  0  0   0   0   1025
fishwindowcleaning.com  12  0  0  0  0  0   0   0   31 8
   warrensouth.com   5  0  0  0  0  0   0   0   10 4
  ecodiscoverypark.com   5  0  0  0  0  0   0   1   00 4
   pfg.com   4  0  0  0  0  0   0   0   12 1

Luckily the active and and incoming queues aren't showing any signs of 
backscatter. I'm going to be checking firewall tomorrow to see if there's an 
issue there. Thanks for your help.

Gonzo Fernandez

On Jan 30, 2012, at 9:09 PM, Noel Jones wrote:

> On 1/30/2012 10:30 PM, Noel Jones wrote:
>> On 1/30/2012 6:46 PM, Gonzo Fernandez wrote:
>>> Thank you Noel. Our server sends out copies of email confirmations
>>> to our clients and if the client decides to make a large order they
>>> end up pushing our volume up and we end up getting blocked by their
>>> mail server. I seem to be getting connection timed out on a lot of
>>> the hosts. I even try to telnet to ip and port 25 but it keeps
>>> timing out. I used "grep" to search in /var/log/maillog and I got
>>> this. Any ideas?
>> 
>> 
>> This isn't a postfix problem.  If you can't telnet to any client
>> port 25, then you have a connectivity problem; maybe your ISP is
>> blocking that port, or some firewall has been misconfigured.
>> Contact your networking team or your ISP.
>> 
>> If you can't telnet to this one destination port 25, they're
>> blocking you.  You'll need to contact them to get this resolved.
>> 
>> 
>> Good luck.
>> 
>> 
>> 
>>  -- Noel Jones
> 
> 
> If the destination can't handle the load you're sending it, you can
> slow postfix down.  Details here:
> http://www.postfix.org/QSHAPE_README.html#active_congestion
> 
> Of course, this won't help until they stop blocking you.
> 
>  -- Noel Jones

RE: SASL authentication and Windows Live Mail

[James Day]

Thanks for your input guys. As I suspected I need to dig a bit deeper. Here is 
the relevant portion of my mail log using Windows Live Mail to send:

[...snip]
Jan 31 07:27:51 vps03 postfix/smtpd[3923]: connect from unknown[IP_REMOVED]
Jan 31 07:27:51 vps03 postfix/smtpd[3923]: NOQUEUE: reject: RCPT from 
unknown[IP_REMOVED]: 554 5.7.1 : Relay access denied; 
from= to= proto=ESMTP 
helo=
Jan 31 07:27:51 vps03 postfix/smtpd[3923]: disconnect from unknown[IP_REMOVED]
Jan 31 07:27:54 vps03 dovecot: imap-login: Login: user=< 
dovecotuser@trusteddomain >, method=PLAIN, rip=IP_REMOVED, lip=IP_REMOVED, TLS
Jan 31 07:27:54 vps03 dovecot: IMAP(dovecotuser@trusteddomain): Disconnected: 
Logged out bytes=712/6487
[...snip]

It seems to me that authentication isn't attempted until after the attempt to 
send fails.

...HOLD THE PRESS

I added the LOGIN auth mechanism to my dovecot.conf and reloaded the service, 
the above was my first attempt to send this message again after doing so (which 
failed). Something must have taken some time to propagate because as I was 
typing this message the client connected again and sent successfully. Looks as 
though you were spot on Noel.

Here is the log snipped for the successful send:

Jan 31 07:35:47 vps03 postfix/smtpd[4049]: connect from unknown[IP_REMOVED]
Jan 31 07:35:47 vps03 postfix/smtpd[4049]: BC1A1152601B2: 
client=unknown[IP_REMOVED], sasl_method=LOGIN, sasl_username= 
dovecotuser@trusteddomain
Jan 31 07:35:48 vps03 postfix/cleanup[4052]: BC1A1152601B2: 
message-id=
Jan 31 07:35:48 vps03 postfix/qmgr[26598]: BC1A1152601B2: from=< 
dovecotuser@trusteddomain >, size=1261, nrcpt=1 (queue active)
Jan 31 07:35:48 vps03 postfix/smtpd[4049]: disconnect from unknown[IP_REMOVED]
Jan 31 07:35:48 vps03 dovecot: imap-login: Login: 
user=, method=PLAIN, rip= IP_REMOVED, lip= 
IP_REMOVED, TLS
Jan 31 07:35:48 vps03 postfix/smtp[4053]: BC1A1152601B2: 
to=, relay=remote_mx_address[IP_REMOVED]:25, delay=0.79, 
delays=0.27/0/0.14/0.37, dsn=2.6.0, status=sent (250 2.6.0 
 Queued mail for delivery)
Jan 31 07:35:48 vps03 postfix/qmgr[26598]: BC1A1152601B2: removed

The only question that remains for me is, what is the difference between PLAIN 
and LOGIN mechanisms? I understand from 
http://wiki.dovecot.org/Authentication/Mechanisms that they are both plain 
text. Unfortunately google searches for login authentication aren't 
particularly helpful.

Kind regards,

James Day

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Noel Jones
Sent: 31 January 2012 04:22
To: postfix-users@postfix.org
Subject: Re: SASL authentication and Windows Live Mail

On 1/30/2012 9:32 PM, Jim Seymour wrote:
> On Tue, 31 Jan 2012 00:30:33 +
> James Day  wrote:
> 
> [snip]
>> ... trying the same account details from Windows Live Mail throws up 
>> a:
>>
>> "554 Relay Access denied" error message.
> [snip]
> 
> IIRC, "Relay access denied" is a symptom of a non-SSL attempted 
> connection/login when "disable_plaintext_auth = yes" in dovecot.conf.

The error message means the mail was rejected by reject_unauth_destination, and 
that means the client didn't authenticate (or tried and failed).

If AUTH was tried and failed, it will be noted in the postfix and dovecot logs. 
 If no failures are logged, AUTH wasn't attempted.

This may or may not have anything to do with SSL/TLS.  Another good guess is 
that dovecot needs to offer LOGIN and/or PLAIN mechanisms.

But we're just guessing here.  We need more details of the connection and 
configuration to give more concrete advice.

http://www.postfix.org/DEBUG_README.html#mail


  -- Noel Jones