postfix filter and CR LF.CR LF
Hello everyone, I'm writing this message to ask for advice on a filter i'm writing. The thing is that I've got a server running postfix in which i already have a postfix filter written in Perl. When i have to reinject the message into postfix, i do it with the SMTP class from Perl, which doesn't give me any problem at all. However, i have to write a new one in C/C++ and I'm getting some trouble with the dot indicating the end-of-message. The problem is that when i send the message back from the filter written in C/C++ anyone can perform a spam injection by sending messages with this content: . MAIL FROM: unremit...@mydomain.com RCPT TO: vic...@otherdomain.com DATA spam spam spam . and vic...@otherdomain.com will get a message from unremit...@mydomain.com containing spam spam spam I've tried with different implementations in C and also C++. Some people have developed SMTP classes for C++ which I've tried, but none can't stop this spam injection from happening. So.. my first question would be... how does postfix itself handle this? Or... what can i do in my filter to tell postfix that doesn't have to take CR LF.CR LF as the end of the message? Has anyone found a solution for this while using postfix filters? Thanks in advance for your help.
Re: Spam attacks
W dniu 2009-03-05 06:30, Mihira Fernando pisze: Have you ever tried sending an e-greeting to someone via 123greeting.com or some other similar site ? You're definitely right - I didn't use that one before. Look what I get in logs: Mar 5 09:41:50 lola postfix/smtpd[20278]: warning: 72.233.20.39: address not listed for hostname www.123greetings.com So they are surely doing something nasty... Anyways: Mar 5 09:41:52 lola postgrey[22558]: action=greylist, reason=new, client_name=unknown, client_address=72.233.20.54, sender=eca...@123greetings.com, recipient=pa...@lesniakowie.com So, I have really no idea why are you all advocating that some services use MY EMAIL ADDRESS as ENVELOPE SENDER. It's something what should never be done. And I really know no site which does something that bad. End of story. Discussion went far away from postfix, and some of you are trying to put in my mouth words I never said. It's my last post in this subject. Pawel Lesniak
Re: postfix filter and CR LF.CR LF
However, i have to write a new one in C/C++ and I'm getting some trouble with the dot indicating the end-of-message. The problem is that when i send the message back from the filter written in C/C++ anyone can perform a spam injection by sending messages with this content: . MAIL FROM: unremit...@mydomain.com RCPT TO: vic...@otherdomain.com DATA spam spam spam . You are probably forgetting to convert the single dot (.) to dot-dot (..) See RFC 2821 section 4.5.2 Transparency Martijn Brinkers -- Djigzo open source email encryption www.djigzo.com
Re: postfix filter and CR LF.CR LF
En/na martijn.list ha escrit: However, i have to write a new one in C/C++ and I'm getting some trouble with the dot indicating the end-of-message. The problem is that when i send the message back from the filter written in C/C++ anyone can perform a spam injection by sending messages with this content: . MAIL FROM: unremit...@mydomain.com RCPT TO: vic...@otherdomain.com DATA spam spam spam . You are probably forgetting to convert the single dot (.) to dot-dot (..) See RFC 2821 section 4.5.2 Transparency Martijn Brinkers Hi, thanks for your suggestion, I'll give it a try. However, I think that I've already tried this. As far as I can remember, the problem by modifying the content of the message was that when a user used some kind of signature, the checksum wouldn't match and users complain about the body being altered. Does that make sense to you? Or may be it's only that my implementation was buggy. Thanks.
Re: postfix filter and CR LF.CR LF
On Thu, March 5, 2009 10:13 am, Jordi Moles Blanco said: En/na martijn.list ha escrit: You are probably forgetting to convert the single dot (.) to dot-dot (..) See RFC 2821 section 4.5.2 Transparency thanks for your suggestion, I'll give it a try. However, I think that I've already tried this. As far as I can remember, the problem by modifying the content of the message was that when a user used some kind of signature, the checksum wouldn't match and users complain about the body being altered. Does that make sense to you? Or may be it's only that my implementation was buggy. The extra dot is removed by the SMTP server so that the message remains the same after transmission. -- Magnus Bäck mag...@dsek.lth.se
Re: postfix filter and CR LF.CR LF [solved]
En/na Magnus Bäck ha escrit: On Thu, March 5, 2009 10:13 am, Jordi Moles Blanco said: En/na martijn.list ha escrit: You are probably forgetting to convert the single dot (.) to dot-dot (..) See RFC 2821 section 4.5.2 Transparency thanks for your suggestion, I'll give it a try. However, I think that I've already tried this. As far as I can remember, the problem by modifying the content of the message was that when a user used some kind of signature, the checksum wouldn't match and users complain about the body being altered. Does that make sense to you? Or may be it's only that my implementation was buggy. The extra dot is removed by the SMTP server so that the message remains the same after transmission. Hi, thanks for the info. Now the filter seems to work properly. I guess it was my fault the first time I tried this. I didn't keep that piece of code cause it wasn't working anyway... but it was defenetly buggy. Thanks for your help.
Re: Postfix + Dovecot SASL authentication.
Robert A. Ober escribió: On 3/4/2009 10:05 AM, Miguel Da Silva - Centro de Matemática wrote: Victor Duchovni escribió: On Wed, Mar 04, 2009 at 09:35:38AM -0200, Miguel Da Silva - Centro de Matem?tica wrote: The user was not relaying: mail was sent to a domain you are responsible for, so this was not blocked by reject_unauth_destination. Well... I don't think so, maybe I am not understandig reject_unauth_destinations correctly. You are the one asking the question, so it would be wise to take time to research and test the (correct) answer you were given. * Postfix is the final destination: the resolved RCPT TO domain matches $mydestination, $inet_interfaces, $proxy_interfaces, $virtual_alias_domains, or $virtual_mailbox_domains, and contains no sender-specified routing (u...@elsewhere@domain). But, reading the second one I would say every local user sending mail to another local user will get it done through the server. Any client (regardless of envelope sender address) passes this restriction when sending to a local destination address. It's done... now I could say there are no problem. I misunderstood the documentation, so I checked them one more time and did some tests. Everything is working as it should. Thank you. Since I am trying to get basically the same thing to work, where did your sasl come from? I came in late to the discussion. What OS are you running? Thanks, Robert Well, it came from dovecot.org :) Maybe I misunderstood your question, please let me know. I'm running Postfix 2.3.x and Dovecot 1.0. My problem was a confusing configuration. I mean, settings things up in non very wise way. The local SMTP is public and receive mail to/from local users to/from people everywhere. Now, the configuration says: if you're part of $mynetwork your mail goes with no authentication; if you are not, then you must authenticate to send mail to anyone and if you do not authenticate, then you can send mail just to local users. Is it clear? Greetings. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy
Re: PATCH: Possible reasons for qmgr loading the system?
Wietse Venema wrote: You might want to repeat your precise Postfix version at this point, and which queue manager version is configured in your master.cf. Current Postfix versions have (qmgr=new, oqmgr=old) in master.cf. Older Postfix versions have (nqmgr=new, qmgr=old) instead. The programs are the same except for the job selection algorithm. r...@egeo:~# postconf mail_version mail_version = 2.5.1 r...@egeo:~# grep -i qmgr /etc/postfix/master.cf qmgr fifo n - n 300 1 qmgr #qmgr fifo n - - 300 1 oqmgr If you are using the new queue manager, it is worthwhile to see if the problem persists when you switch to the old queue manager. It seems I'm using the new one... OK, leave the above settings and see if this helps (Postfix 2.5 or later). I have not been able to reproduce the problem, but there was some bogosity with the handling of _destination_rate_delay. diff --exclude=man --exclude=html --exclude=README_FILES --exclude=.indent.pro --exclude=Makefile.in -cr src/qmgr/qmgr_entry.c- src/qmgr/qmgr_entry.c Well, I'm using postfix's ubuntu package, so it's not compiled from source code because I need all my ~=100 Linux machines to be easily updatable (apt-get update apt-get upgrade). In this case, I'm going to recompile .deb source package including your patch to see if that solves the problem ... Please, allow me a couple of days to recompile / install it (it's a production system, I need to find a working window with customers). I'll inform you in this list if the problem happens again or if the patch seemed to fix the problem. Do you want any kind of aditional change / logging / config to make the problem more easy to happen? (I mean, setting rate_ values higher or lower so that the problem reproduces again faster, because it passed 5 days between the last 2 times qmgr ate the CPU...). Thanks. -- Santiago Romero
Re: PATCH: Possible reasons for qmgr loading the system?
Santiago Romero: (I mean, setting rate_ values higher or lower so that the problem reproduces again faster, because it passed 5 days between the last 2 times qmgr ate the CPU...). Just run the same test. Thanks, Wietse
Postfix tarball uninstall
Hi, I had installed postfix from the tarball, but made some mistakes. So to be sure everything is correct I want to reinstall Postfix (probably from a package), so I first need to uninstall it. But there is no make uninstall/remove or some removal program, is there any way to uninstall it properly? greetings, Paul
Re: rewriting sender address
2009/3/5 ghe g...@slsware.com: I need to change email sent by a user from one domain (a.com) so that clicking Reply will reply to him at b.com. (a.com isn't always reliable, and I admin b.com, among other reasons.) Google got me to postfix.org's documentation on generic maps. I'm running 2.5, so tried that, to rewrite the destination address on its way out, but couldn't get it to work: This is a little unclear. I interpret that to mean mail sent from your server, from u...@a.com, should appear to come from u...@b.com, so that the return-path will be at b.com - is this correct? You then said you want to rewrite the destination address on its way out, but that'd be inconsistent. main.cf: smtp_generic_maps = hash:/etc/postfix/generic /etc/postfix/generic: ghe2...@gmail.com g...@slsware.com g...@qw.net ...@slsware.com generic_maps are for rewriting local addresses on outgoing mail, as documented: http://www.postfix.org/ADDRESS_REWRITING_README.html#generic I sent mail to myself at gmail, expecting it to come here That sounds like you want to rewrite the recipient address, which is non-local.I believe canonical_maps will do this for you, but I don't know what the scope is (ie. I expect it to affect mail which isn't local-to-local, but I honestly don't know). Someone else can shed more light on this. So I tried to rewrite the sender address on its way in. The canonical-sender map worked when I telnet'ed and did SMTP by hand, without supplying a From: header. But when he sent me mail, the Return-Path header was rewritten but From: was not, so clicking Reply was sending to a.com. Is there a way to get postfix to change From: or to maybe copy Return-Path to a Reply-To? The canonical and generic maps will affect the envelope address/es and From/To headers, unless I'm mistaken. The documentation doesn't suggest to me that it will parse and modify any other headers.
Re: restricting who can be sent to.
2009/3/5 Carver Banks carver.ba...@trustvesta.com: I tried the following: smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/allowed_recipients reject but it seems that allows me to restrict the user who is sending not the destination address, what I am trying to accomplish is to have many users of this system be able to only email a few addresses, not even each other. I understand if that is not possible with postfix, just trying to figure out if that is the case... Please re-read the example given, it was check_recipient_access, not check_sender_access as you've shown in your attempt
Re: OT: Diagnose blocked mail (Summary)
2009/3/5 Ray r...@stilltech.net: Server is live and fully functional. it deals with thousands of messages per day and has for over a year. One user can't receive messages from one contact. That contact doesn't even show up in the logs as spam or lost connection or anything. Can you clarify? I assume the recipient can receive mail from other senders just fine? Can you find out if another sender at the same domain can get mail to your user? 1) have a message sent to another account on same server Good idea. 2) smtpd_delay_reject = yes is set, so try to figure out sending ip address and search for it in maillog. This is the default, but you'll still see records of the connecting IP address even if it's set to 'no'. Figuring out the sending IP address may or may not be difficult depending on the level of co-operation from the sender's side. 3) get administrator of sending server to check his logs This will be the most productive; force them to *prove* that mail is leaving their servers, and ideally show that it's getting to yours. While you want to be helpful, you don't want to waste time. I wouldn't bother doing much more than grepping your logs without some confirmation the mail is approaching your systems. Also ask the sending user to send through a copy of whatever error messages they're getting back, it should be a bounce email. 4) pcap during a communication attempt I'll do number 4 if It comes down to it, but frankly I've never done anything with packet capture and it's a little intimidating. Chances are you'll find the problem well before you need to do this. On linux, right? tcpdump or wireshark/tshark is your friend :) Something like `tcpdump -n -i eth0 host rem.ote.ip.address and tcp port smtp
Re: Postfix tarball uninstall
Paul: Hi, I had installed postfix from the tarball, but made some mistakes. So to be sure everything is correct I want to reinstall Postfix (probably from a package), so I first need to uninstall it. But there is no make uninstall/remove or some removal program, is there any way to uninstall it properly? The answer depends on whose tarball you have installed. Wietse
Re: rewriting sender address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barney Desmond wrote: This is a little unclear. I interpret that to mean mail sent from your server, from u...@a.com, should appear to come from u...@b.com, so that the return-path will be at b.com - is this correct? You then said you want to rewrite the destination address on its way out, but that'd be inconsistent. Not quite. I want the recipient's Reply button to send to u...@b.com when replying to mail received from u...@a.com. I don't really care how it's done. Rewriting the source address as the mail is received would do, as would rewriting the destination address as the reply is sent. generic_maps are for rewriting local addresses on outgoing mail, as documented: http://www.postfix.org/ADDRESS_REWRITING_README.html#generic I read that and evidently misunderstood it. I got the outgoing mail part, but I thought it was for rewriting remote addresses. I sent mail to myself at gmail, expecting it to come here That sounds like you want to rewrite the recipient address Exactly. The canonical and generic maps will affect the envelope address/es and From/To headers That's what I thought too. But canonical-sender seems to do just Return-Path. Unless I've done something wrong. The documentation doesn't suggest to me that it will parse and modify any other headers. Doesn't to me either and thanks for looking. I was hoping someone could tell me I'm wrong... - -- Glenn English g...@slsware.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmv3jMACgkQ04yQfZbbTLZZbQCfWpACPH7QOHYSKKqh77GhoKgl assAoJqIKhH7FRnYCnr+DZJDM0xHN9Iu =nmLH -END PGP SIGNATURE-
Re: Accept undeliverable mails and send NDR
ram: One of my clients sends mail using a custom application which *cannot* recognize a smtpd error message .. like user-not-found, or invalid-domain etc In other words, they have a home-grown partial implementation of the SMTP protocol. They can't be bothered to do it right and they just want the eror messages to go away. Now they want our postfix server to accept all mails without checks and send NDR's for undeliverable mails. And of course they will throw away the NDRs. What you're asking is not supported. You can only turn off some checks in Postfix. In main.cf, specify strict_rfc821_envelopes=no, smtpd_reject_unlisted_recipient = no, don't use reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unlisted_sender, reject_unlisted_recipient, etc. Do not use these settings on a server that receives mail from the Internet. However, if their home-grown software sends invalid SMTP syntax then Postfix will reject the command, and there is no way that Postfix will be configurable to accept such stuff. Wietse
Re: Postfix tarball uninstall
On Thu, Mar 05, 2009 at 12:21:15PM +0100, Paul wrote:
I had installed postfix from the tarball, but made some mistakes. So to be
sure everything is correct I want to reinstall Postfix (probably from a
package), so I first need to uninstall it. But there is no make
uninstall/remove or some removal program, is there any way to uninstall it
properly?
The postfix-files file found in $config_directory, or in the most
recent versions of Postfix in $daemon_directory, contains a list of all
the files that are installed when Postfix is instaled from source.
cd to the directory that contains the postfix-files file and in
a POSIX shell (ksh, bash, or sh on most systems) run:
eval $(postconf command_directory daemon_directory html_directory \
mailq_path manpage_directory newaliases_path readme_directory \
sendmail_path | sed -e 's/ = /=/; s,^,export ,')
perl -F: -lane '
next if ($F[1] eq d || $F[5] =~ /o/); # directory or obsolete
next unless $F[0] =~ m{^\$(\w+)}; # comment
next unless defined($path = $ENV{$1}); # keep
$F[0] =~ s/\$(\w+)/$path/; # expand;
next unless (-l $F[0] || -f _); # link or file
printf %s\n, $F[0];
' postfix-files
this will output the list of files to remove.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users
If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.
Questions regarding Backup MX and Postfix's Queue.
Hi guys, I have a couple of quick questions: 1) How long does a message sit in the postfix queue for before it attempts a redeliver (a deffered message sat in the deffered queue)? 2) If you have a mailserver (postfix, dovecot, virtual users/domains mysql) and you have a back-up MX record set if the main mailserver goes down (reboot) and a mail gets sent to a domain hosted on the server, it gets no response from the main mailserver so reverts to the backup. It delivers the mail to the backup and then defers it because it cannot be sent to the main mailserver, it then sits in the deferred queue until the main mailserver is back and gets delivered. wonderfull... the question is, if the server is down due to a reboot for whatever reason so say 5 - 10 minute downtime. The original message will be sent, goto the backup mx, it will get deferred until mailserver is backup then delivered... BUT I tested this with hotmail, and what I get is, hotmail defers the message as well as sending it to the backup mx, so that when the backup mx delivers the mail which goes through fine, hotmail are retrying as well, and you end up with two of the same message? How do you overcome this? Kind Regards, Dusty.
Re: Questions regarding Backup MX and Postfix's Queue.
du...@linuxgeek.org.uk: I have a couple of quick questions: 1) How long does a message sit in the postfix queue for before it attempts a redeliver (a deffered message sat in the deffered queue)? http:/www.postfix.org/postconf.5.html#queue_run_delay http:/www.postfix.org/postconf.5.html#maximal_backoff_time http:/www.postfix.org/postconf.5.html#minimal_backoff_time http:/www.postfix.org/postconf.5.html#maximal_queue_lifetime with hotmail, and what I get is, hotmail defers the message as well as sending it to the backup mx, so that when the backup mx delivers the mail which goes through fine, hotmail are retrying as well, and you end up with two of the same message? How do you overcome this? If hotmail sends the same message to the backup and to the primary MX, then there is nothing that Postfix can do about it. Wietse
Re: Accept undeliverable mails and send NDR
ram wrote: One of my clients sends mail using a custom application which *cannot* recognize a smtpd error message .. like user-not-found, or invalid-domain etc Now they want our postfix server to accept all mails without checks and send NDR's for undeliverable mails. Even if you can make this work, it's still a bad idea, since the outbound SMTP server will be blacklisted for sending to too many invalid addresses. Because it ignores bounces, the mailing list will never be updated to remove invalid recipients. Terry
Re: PATCH: Possible reasons for qmgr loading the system?
On Thu, Mar 05, 2009 at 12:20:06PM +0100, Santiago Romero wrote: Well, I'm using postfix's ubuntu package, so it's not compiled from source code because I need all my ~=100 Linux machines to be easily updatable (apt-get update apt-get upgrade). In this case, I'm going to recompile .deb source package including your patch to see if that solves the problem ... Please, allow me a couple of days to recompile / install it (it's a production system, I need to find a working window with customers). I'll inform you in this list if the problem happens again or if the patch seemed to fix the problem. Do you want any kind of aditional change / logging / config to make the problem more easy to happen? Please wait for an updated patch, we believe we have identified the cause and reproduced the symptoms (in that order). I have a candidate patch, but I expect Wietse will send an updated more polished version in the not too distant future. The issue found applies only to rate-limited transports, if you are not using such transports, you don't need the patch. The patch ensures that work done at the completion of a delivery with a normal transport is correctly split between before suspend and after resume. The original 2.5.x code is correct for oqmgr, but not for qmgr (aka nqmgr), which requires additional internal state adjustments when destinations are blocked and unblocked. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: PATCH: Possible reasons for qmgr loading the system?
Please wait for an updated patch, we believe we have identified the cause and reproduced the symptoms (in that order). I have a candidate patch, but I expect Wietse will send an updated more polished version in the not too distant future. Ok, I'll wait for it. I'm going to roll back to ubuntu packages (I already applied the patch and was testing it). The original 2.5.x code is correct for oqmgr, but not for qmgr (aka nqmgr), which requires additional internal state adjustments when destinations are blocked and unblocked I've changed to oqmgr in master.cf for the machine that uses that special slow transport. Would I notice any difference in postfix behaviour because of using oqmgr instead of qmgr (less performance or something like that)? Thanks. -- Santiago Romero
RE: restricting who can be sent to.
Thanks! That worked, next time I will try and read better ;-) Carver Banks -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Barney Desmond Sent: Thursday, March 05, 2009 4:11 AM To: postfix users list Subject: Re: restricting who can be sent to. 2009/3/5 Carver Banks carver.ba...@trustvesta.com: I tried the following: smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/allowed_recipients reject but it seems that allows me to restrict the user who is sending not the destination address, what I am trying to accomplish is to have many users of this system be able to only email a few addresses, not even each other. I understand if that is not possible with postfix, just trying to figure out if that is the case... Please re-read the example given, it was check_recipient_access, not check_sender_access as you've shown in your attempt
RE: restricting who can be sent to.
Or so I thought..., that did restrict all mail to the internal recipients as well. I need anyone in mydomain.com to be able to email anyone in mydomain.local, but I need users on mydomain.local to only be allowed to email a few people in mydomain.com, and none of the other members of mydoman.local. I think postfix may not be able to accomplish what I desire, if I am wrong please correct me. Carver -Original Message- From: Carver Banks Sent: Thursday, March 05, 2009 7:38 AM To: 'Barney Desmond'; postfix users list Subject: RE: restricting who can be sent to. Thanks! That worked, next time I will try and read better ;-) Carver Banks -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Barney Desmond Sent: Thursday, March 05, 2009 4:11 AM To: postfix users list Subject: Re: restricting who can be sent to. 2009/3/5 Carver Banks carver.ba...@trustvesta.com: I tried the following: smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/allowed_recipients reject but it seems that allows me to restrict the user who is sending not the destination address, what I am trying to accomplish is to have many users of this system be able to only email a few addresses, not even each other. I understand if that is not possible with postfix, just trying to figure out if that is the case... Please re-read the example given, it was check_recipient_access, not check_sender_access as you've shown in your attempt
Re: PATCH: Possible reasons for qmgr loading the system?
On Thu, Mar 05, 2009 at 04:21:01PM +0100, Santiago Romero wrote: Please wait for an updated patch, we believe we have identified the cause and reproduced the symptoms (in that order). I have a candidate patch, but I expect Wietse will send an updated more polished version in the not too distant future. Ok, I'll wait for it. I'm going to roll back to ubuntu packages (I already applied the patch and was testing it). The original 2.5.x code is correct for oqmgr, but not for qmgr (aka nqmgr), which requires additional internal state adjustments when destinations are blocked and unblocked I've changed to oqmgr in master.cf for the machine that uses that special slow transport. Would I notice any difference in postfix behaviour because of using oqmgr instead of qmgr (less performance or something like that)? With oqmgr, list messages with a lot (multiple thousands to perhaps hundreds of thousands) of recipients can dominate the queue, and delay small messages. Also if you don't define relay_domains correctly, on a high-volume border gateway outbound smtp traffic can starve inbound smtp traffic when both use the same transport, especially if outbound traffic exhibits high latency. - Avoid mixing (very large) list mail with regular traffic in the same queue with oqmgr - Avoid delivering inbound/outbound traffic via the same transport. - Avoid outbound congestion caused by lack of recipient validation. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: rewriting sender address
On Mar 5, 2009, at 7:14, ghe g...@slsware.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barney Desmond wrote: This is a little unclear. I interpret that to mean mail sent from your server, from u...@a.com, should appear to come from u...@b.com, so that the return-path will be at b.com - is this correct? You then said you want to rewrite the destination address on its way out, but that'd be inconsistent. Not quite. I want the recipient's Reply button to send to u...@b.com when replying to mail received from u...@a.com. But a.com is not you, so how do you intend to control that? What you want is for user to add a reply-to header to their outbound mail.. I suppose there must be a way to create a filter to add that header (formail?)
Re: Questions regarding Backup MX and Postfix's Queue.
On Mar 5, 2009, at 7:33, du...@linuxgeek.org.uk wrote: Hi guys, I have a couple of quick questions: 1) How long does a message sit in the postfix queue for before it attempts a redeliver (a deffered message sat in the deffered queue)? 2) If you have a mailserver (postfix, dovecot, virtual users/domains mysql) and you have a back-up MX record set if the main mailserver goes down (reboot) and a mail gets sent to a domain hosted on the server, it gets no response from the main mailserver so reverts to the backup. It delivers the mail to the backup and then defers it Your backup MX is deferring the message? As far as the sender is concerned, once the message is accepted by your server, it should be considered delivered, no? because it cannot be sent to the main mailserver, it then sits in the deferred queue until the main mailserver is back and gets delivered. wonderfull... the question is, if the server is down due to a reboot for whatever reason so say 5 - 10 minute downtime. The original message will be sent, goto the backup mx, it will get deferred until mailserver is backup then delivered... BUT I tested this with hotmail, and what I get is, hotmail defers the message as well as sending it to the backup mx, so that when the backup mx delivers the mail which goes through fine, hotmail are retrying as well, and you end up with two of the same message? How do you overcome this? Um, hosts.deny hotmail? ;)
Re: Accept undeliverable mails and send NDR
On Mar 5, 2009, at 7:50, Terry Carmen te...@cnysupport.com wrote: ram wrote: One of my clients sends mail using a custom application which *cannot* recognize a smtpd error message .. like user-not-found, or invalid-domain etc Now they want our postfix server to accept all mails without checks and send NDR's for undeliverable mails. Even if you can make this work, it's still a bad idea, since the outbound SMTP server will be blacklisted for sending to too many invalid addresses. Because it ignores bounces, the mailing list will never be updated to remove invalid recipients. Spammers don't care. I mean, come on, a custom SMTP that ignores errors? SPAMMER ALERT.
Re: Postfix tarball uninstall
On Thu, 5 Mar 2009 09:03:13 -0500 (EST), Wietse Venema wrote: The answer depends on whose tarball you have installed. Wietse I've installed the source tarball from postfix.org
Re: Postfix tarball uninstall
On Thu, 5 Mar 2009 09:30:30 -0500, Victor Duchovni wrote:
The postfix-files file found in $config_directory, or in the most
recent versions of Postfix in $daemon_directory, contains a list of all
the files that are installed when Postfix is instaled from source.
cd to the directory that contains the postfix-files file and in
a POSIX shell (ksh, bash, or sh on most systems) run:
eval $(postconf command_directory daemon_directory html_directory \
mailq_path manpage_directory newaliases_path readme_directory \
sendmail_path | sed -e 's/ = /=/; s,^,export ,')
perl -F: -lane '
next if ($F[1] eq d || $F[5] =~ /o/); # directory or obsolete
next unless $F[0] =~ m{^\$(\w+)}; # comment
next unless defined($path = $ENV{$1}); # keep
$F[0] =~ s/\$(\w+)/$path/; # expand;
next unless (-l $F[0] || -f _); # link or file
printf %s\n, $F[0];
' postfix-files
this will output the list of files to remove.
That will only list the files which are installed, but it also configures
FreeBSD to use it as it's MTA, that will not be uninstalled by just
removing to files I guess.
Re: Local mail listener
Daniel L. Miller wrote: Magnus Bäck wrote: On Thursday, March 05, 2009 at 00:25 CET, Daniel L. Miller dmil...@amfes.com wrote: What I have/had now was the following: master.cf: 192.168.0.11:smtp inet n - - - - smtpd -o relayhost=[192.168.0.10]:225 192.168.0.11:125 inet n - - - - smtpd -o relayhost= The intent was to have local clients connect to 192.168.0.11:25. Postfix should then relay it to 192.168.0.10:225. That relay will then process and return it to 192.168.0.11:125 - which would then send it to the destination. Right now, the above config functions in that it receives a message from a client and delivers it to the destination - but it never hits my filter. No, because smtpd(8) doesn't pay attention to the relayhost parameter and doesn't pass it on to the rest of Postfix. Postfix is modular, and the relayhost is not a per-message property. You're on the right track, just use content_filter instead. See FILTER_README. I'm closing in on it - now for some fine-tuning. Now, a test master.cf contains: 192.168.0.11:smtp inet n - - - - smtpd -o smtpd_proxy_filter=inet:192.168.0.11:325 192.168.0.11:325 inet n - - - - smtpd -o smtpd_proxy_filter= This actually works - I can see in the log the relay between the processes and then the handoff to the remote server. Mar 4 23:22:54 mailserver postfix/smtpd[21006]: connect from unknown[192.168.0.90] Mar 4 23:22:54 mailserver postfix/smtpd[21010]: connect from smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:22:54 mailserver postfix/smtpd[21006]: NOQUEUE: client=unknown[192.168.0.90] Mar 4 23:22:54 mailserver postfix/smtpd[21010]: F20D476031: client=smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:22:55 mailserver postfix/cleanup[21011]: F20D476031: message-id=49af7dc3.10...@amfes.com Mar 4 23:22:55 mailserver postfix/qmgr[21005]: F20D476031: from=dmil...@amfes.com, size=835, nrcpt=1 (queue active) Mar 4 23:22:55 mailserver postfix/smtpd[21010]: disconnect from smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:22:55 mailserver postfix/smtpd[21006]: disconnect from unknown[192.168.0.90] Mar 4 23:22:55 mailserver postfix/smtp[21012]: F20D476031: to=fireexp...@hotmail.com, relay=mx3.hotmail.com[65.55.37.120]:25, delay=0.42, delays=0.1/0.01/0.18/0.13, dsn=2.0.0, status=sent (250 49af7dc3.10...@amfes.com Queued mail for delivery) Mar 4 23:22:55 mailserver postfix/qmgr[21005]: F20D476031: removed Now - to see what's broken. When the smtpd_proxy_filter line is pointed to the real proxy, and the proxy is pointed to return to the :325 port, my log shows: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: connect from unknown[192.168.0.90] Mar 4 23:21:33 mailserver postfix/smtpd[20970]: connect from smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:21:33 mailserver postfix/smtpd[20964]: NOQUEUE: client=unknown[192.168.0.90] Mar 4 23:21:33 mailserver postfix/smtpd[20970]: A812D76031: client=smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: non-SMTP command from unknown[192.168.0.90]: Message-ID: 49af7d71.70...@amfes.com Mar 4 23:21:33 mailserver postfix/smtpd[20964]: disconnect from unknown[192.168.0.90] Mar 4 23:21:33 mailserver postfix/smtpd[20970]: lost connection after DATA (0 bytes) from smtp-local.amfeslan.local[192.168.0.11] Mar 4 23:21:33 mailserver postfix/smtpd[20970]: disconnect from smtp-local.amfeslan.local[192.168.0.11] Does this indicate a Postfix problem? Or is my proxy filter mangling something? Looks as if the proxy filter has gotten out of sync with postfix. I would suggest starting using it as a content_filter. Once you get that working, you can see if it works with smtpd_proxy_filter. I find it handy to use -o syslog_name=postfix-something in master.cf to differentiate services; makes reading the logs easier. -- Noel Jones
Re: Postfix tarball uninstall
On Thu, Mar 05, 2009 at 05:37:00PM +0100, Paul wrote:
On Thu, 5 Mar 2009 09:30:30 -0500, Victor Duchovni wrote:
The postfix-files file found in $config_directory, or in the most
recent versions of Postfix in $daemon_directory, contains a list of all
the files that are installed when Postfix is instaled from source.
cd to the directory that contains the postfix-files file and in
a POSIX shell (ksh, bash, or sh on most systems) run:
eval $(postconf command_directory daemon_directory html_directory \
mailq_path manpage_directory newaliases_path readme_directory \
sendmail_path | sed -e 's/ = /=/; s,^,export ,')
perl -F: -lane '
next if ($F[1] eq d || $F[5] =~ /o/); # directory or obsolete
next unless $F[0] =~ m{^\$(\w+)}; # comment
next unless defined($path = $ENV{$1}); # keep
$F[0] =~ s/\$(\w+)/$path/; # expand;
next unless (-l $F[0] || -f _); # link or file
printf %s\n, $F[0];
' postfix-files
this will output the list of files to remove.
That will only list the files which are installed, but it also configures
FreeBSD to use it as it's MTA, that will not be uninstalled by just
removing to files I guess.
The Postfix tarball from postfix.org does not do any such thing. Which
it did you have in mind?
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users
If my response solves your problem, the best way to thank me is to not
send an it worked, thanks follow-up. If you must respond, please put
It worked, thanks in the Subject so I can delete these quickly.
Re: rewriting sender address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 LuKreme wrote: But a.com is not you, so how do you intend to control that? By rewriting on my servers. What you want is for user to add a reply-to header to their outbound mail.. I suppose there must be a way to create a filter to add that header (formail?) I was hoping to do this without yet another email program, but I'll look into it. Thanks. - -- Glenn English g...@slsware.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmwBzMACgkQ04yQfZbbTLaouwCfXF8DBPDDGwhb+0BnDGCQjdD4 TWsAnRbtLYNpCre9R75C8LVJnTw+PL7q =ihb3 -END PGP SIGNATURE-
Re: Blocking a domain and user
Jim McIver wrote: Here's a snippet from maillog, but not sure if it's what your looking for: Thanks, this is very helpful. Mar 4 15:10:13 mail postfix/smtpd[56190]: warning: Illegal address syntax from unknown[113.9.198.198] in MAIL co mmand: bikedev...@yahoo.co.jp The above client is listed in multiple RBLs, including zen.spamhaus.org, bl.spamcop.net, cbl.abuseat.org, b.barracudacentral.org, and dnsbl.sorbs.net. Mar 4 15:10:15 mail postfix/smtpd[56172]: warning: 81.25.227.150: address not listed for hostname mail.medterm.o d.ua Mar 4 15:10:15 mail postfix/smtpd[56172]: connect from unknown[81.25.227.150] This client is also listed in multiple RBLs. Mar 4 15:10:15 mail postfix/smtpd[56190]: NOQUEUE: reject_warning: RCPT from unknown[113.9.198.198]: 450 Client host rejected: cannot find your hostname, [113.9.198.198]; from=bikedev...@yahoo.co.jp to=odrawh...@dnews.com proto=SMTP helo=yahoo.co.jp Clearly a forged HELO name. Grounds for rejecting any mail from this client. Mar 4 15:10:15 mail postfix/smtpd[56190]: E35C331: client=unknown[113.9.198.198] Mar 4 15:10:18 mail postfix/cleanup[56217]: E35C331: message-id=20090304231015.e35c...@mail.lmtribune.com Mar 4 15:10:18 mail postfix/qmgr[56169]: E35C331: from=bikedev...@yahoo.co.jp, size=966, nrcpt=1 (queue active ) Mar 4 15:10:18 mail postfix/smtp[56178]: E35C331: to=odrawh...@dnews.com, relay=127.0.0.1[127.0.0.1], delay=3, status=bounced (host 127.0.0.1[127.0.0.1] said: 557 Invalid routing request - domain in BLACK LIST. (in reply to MAIL FROM command)) What?? Some idiot content_filter at 127.0.0.1 is rejecting the mail after you've already accepted it. Don't do that. Reject mail when first comes from the internet. Once mail has been accepted, a content filter must not reject the message. Mar 4 15:10:18 mail postfix/cleanup[56175]: 5ABF260: message-id=20090304231018.5abf...@mail.lmtribune.com Mar 4 15:10:18 mail postfix/qmgr[56169]: 5ABF260: from=, size=2926, nrcpt=1 (queue active) Mar 4 15:10:18 mail postfix/qmgr[56169]: E35C331: removed Mar 4 15:10:19 mail postfix/smtpd[56190]: disconnect from unknown[113.9.198.198] Mar 4 15:10:20 mail postfix/smtp[56178]: 5ABF260: to=bikedev...@yahoo.co.jp, relay=mx1.mail.yahoo.co.jp[124.83 .171.181], delay=2, status=bounced (host mx1.mail.yahoo.co.jp[124.83.171.181] said: 553 VS10-RT Possible forgery or deactivated due to abuse (#5.1.1) bikedev...@yahoo.co.jp (in reply to RCPT TO command)) Yahoo didn't send this mail, and they don't want your backscatter bounce. Eventually they (and others) will blacklist you for backscatter - ie. returning mail they never sent. You must fix your content_filter to not reject mail. Choices may include tag+deliver, quarantine, or discard, depending on what your software supports. It may offer the choice of reject or bounce, don't do that. You can also greatly reduce the load on the content filter by using one or two good RBLs to reject mail before it ever gets to the content_filter. zen.spamhaus.org is safe and very effective. -- Noel Jones
Re: Postfix tarball uninstall
Paul wrote: That will only list the files which are installed, but it also configures FreeBSD to use it as it's MTA, that will not be uninstalled by just removing to files I guess. That should be easy to deal with. These settings are changed in a file called mailer.conf. Here's the documentation from FreeBSD on the topic: http://www.freebsd.org/doc/en/books/handbook/mail-changingmta.html
Re: OT: Diagnose blocked mail (Summary)
Ray wrote: 2) smtpd_delay_reject = yes is set, so try to figure out sending ip address and search for it in maillog. Er, I meant the opposite. If smtpd_delay_reject=yes is set, then the mail logs should have recorded everything from the sender's domain to the intended recipient at some point. The premise is that Postfix will delay rejecting the message until it has logged some useful information. So if that's set, you probably don't have to hit up the sender for his or her outgoing IP addresses--the domain would have appeared in the logs.
Re: Postfix tarball uninstall
The Postfix tarball from postfix.org does not do any such thing. Which it did you have in mind? It putted itself in some weird manner in my startup. That should be easy to deal with. These settings are changed in a file called mailer.conf. I already changed that, but still it gotten booten up from my system I've set all sendmail startup scripts to no, so it doesn't start anything, completely no sendmail isn't an option too
Re: PATCH: Possible reasons for qmgr loading the system?
Santiago Romero: Please wait for an updated patch, we believe we have identified the cause and reproduced the symptoms (in that order). I have a candidate patch, but I expect Wietse will send an updated more polished version in the not too distant future. Ok, I'll wait for it. I'm going to roll back to ubuntu packages (I already applied the patch and was testing it). It will be later today. I don't have much time so I want to have it really right the first time. Code that is right takes more work than code that works. Wietse
Re: root delivery for monitoring services
Cameron Camp wrote: I have monitoring applications on boxes on the same subnet as a box I want to use for mailing list notification using Postfix/mailman to notify several users. An example is some box throwing an snmp trap, where a notification would try to send to notification_l...@example.com so several people would know. Right now that e-mail would be seen to e coming from r...@the_monitor_node_box_name, which won't deliver. What are best practices for this? I would only ever have about 15 boxes reporting. Sorry if this has been already covered. Each box that has mail services should at least have an alias that maps root to a deliverable address. So typically in your /etc/aliases file, you'd have a line like: root: ad...@domain.com Then use that admin address for your snmp processes. -- Daniel I did that, and now I get a message from the mailserver: ad...@domain.com (expanded from r...@localhost): host mail.domain.com[1.2.3.4] said: 504 5.5.2 nob...@localhost: Sender address rejected: need fully-qualified address (in reply to RCPT TO command) how would I fix that? --- thx, Cam
Re: Postfix tarball uninstall
On Thu, Mar 05, 2009 at 06:58:35PM +0100, Paul wrote: The Postfix tarball from postfix.org does not do any such thing. Which it did you have in mind? It putted itself in some weird manner in my startup. That should be easy to deal with. These settings are changed in a file called mailer.conf. I already changed that, but still it gotten booten up from my system I've set all sendmail startup scripts to no, so it doesn't start anything, completely no sendmail isn't an option too Well you de-installed Postfix, the rest is up to you. Install a new MTA of your choice, perhaps another version of Postfix, perhaps something else. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: outbound email destination based on sender's domain
Hi again, Question, even though this proxy is supposed to simply forward the remote traffic based on the sender_relay file, is it supposed to do DNS lookups on the destination domain? Having some issues with DNS resolution - server is sending DNS queries but no reply comes back. Firewall rules permit such traffic so stumped on that but does this box have to do DNS? Thanks... On Mon, Mar 2, 2009 at 10:00 PM, Iad Scoot iad.sc...@gmail.com wrote: Hey, Thanks again for the reply - it seems to be routing the traffic correctly (at least as far as the maillog shows) but I'm having an ISA/Exchange timeout issue on the receiving end of the traffic path. I can see the traffic leave the sending mail server, pass through the ISA server for the source network, be received and processed on the proxy (over the correct subnet), and then be routed to the receiving network on the correct subnet (for the receiving network). However, the connection is timing out and the receiving ISA server reports an Attempted Connection Failure on the traffic that arrives at the receiving ISA server. The proxy reports that the server dropped connection before sending the initial SMTP greeting. Again, guessing that it's an ISA issue or a problem with the Exchange server talking to this particular Postfix server but at least the concept appears sound so hopefully I'll get it figured out tomorrow. Thanks again - will post more when successful (I hope)... On Mon, Mar 2, 2009 at 5:12 PM, Barney Desmond barneydesm...@gmail.comwrote: 2009/3/3 Iad Scoot iad.sc...@gmail.com: Still working on this - something that I didn't mention (sorry, should have) was that the Postfix gateway is multi-homed and that the other edge Postfix systems (and the internal mail servers) are each on different subnets. Example: a.com: internal mail server 192.168.200.1, edge proxy 192.168.201.1 b.com: internal mail server 192.168.210.1, edge proxy 192.168.211.1 c.com: internal mail server 192.168.220.1, edge proxy 192.168.221.1 ...and so on. The gateway system has a NIC for each pair of systems and the traffic is forwarded through a router from the internal server to the gateway and then either back to one of the other internal servers or out to the edge proxy that matches the sender's domain from the internal mail server. How does this new info affect the previous solution that you provided? Assuming your setup is generally sane, this shouldn't cause you any grief. You *can* bind the postfix smtp client to a given src address, but that's only useful when you're single-homed and want to use one particular address of many (for policy/firewall/whatever reasons). This doesn't apply to you, so that's fine. Another thing people sometimes want is (the currently non-existent) sender-dependent src-address. This is usually because they're trying to optimise their mass-mailings of questionable legitimacy. This also doesn't apply to you, which is fine. Left to its own devices, Postfix will let the network stack figure out how to get the packets to the destination properly. As long as your routing is all working, the details you've provided won't change anything (as far as I know).
Blocking email from own domain on From: header
OK.. How about this one: I have had good luck blocking SPAM email which has a MAIL FROM: address in my own domain, by blocking all email from my domain in an access map on 'smtpd_sender_restrictions', and then listing 'permit_mynetworks' and 'permit_sasl_authenticated' first. I call this 'domain restriction' because it allows you to restrict email that purports to be from your domain, but was not sent via an authorized source - a host on your network, or a user which logged in via SMTP AUTH. Now Im seeing SPAM that has a 'From:' header address at my own domain, but the MAIL FROM: is different. It gets in the perimeter, and then my anti-spam software whitelists it, because my domain is on the whitelist! Does anyone know of a similar trick to somehow block all email with a From: address from a particular domain, but let through anything that comes from your own network, or email that was sent via SMTP AUTH? I use header_checks, but dont know a way to do this.
Re: PATCH: Possible reasons for qmgr loading the system?
On Thu, 5 Mar 2009 13:03:11 -0500 (EST) wie...@porcupine.org (Wietse Venema) wrote: It will be later today. I don't have much time so I want to have it really right the first time. Code that is right takes more work than code that works. Reminds me of a plaque I have in my office. There is never enough time to do it right; however, there is always enough time to do it over. anonymous -- Gerard postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html BYTE editors are people who separate the wheat from the chaff, and then carefully print the chaff. signature.asc Description: PGP signature
Re: rewriting sender address SOLVED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 LuKreme wrote: What you want is for user to add a reply-to header to their outbound mail.. I suppose there must be a way to create a filter to add that header (formail?) procmail recognizes the sender, pipes to formail, and formail adds Reply-To: header. Very useful technique for mailing list replies, too. Thanks, all. - -- Glenn English g...@slsware.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmwIN4ACgkQ04yQfZbbTLam4wCdGFS9EnYdJWBLRHtQgkRSUOU9 vyQAmwa5SFAq+31eSG6V0fAegGzovqQQ =bZxO -END PGP SIGNATURE-
Re: Blocking a domain and user
Noel Jones wrote: Jim McIver wrote: Here's a snippet from maillog, but not sure if it's what your looking for: Thanks, this is very helpful. Mar 4 15:10:13 mail postfix/smtpd[56190]: warning: Illegal address syntax from unknown[113.9.198.198] in MAIL co mmand: bikedev...@yahoo.co.jp The above client is listed in multiple RBLs, including zen.spamhaus.org, bl.spamcop.net, cbl.abuseat.org, b.barracudacentral.org, and dnsbl.sorbs.net. Mar 4 15:10:15 mail postfix/smtpd[56172]: warning: 81.25.227.150: address not listed for hostname mail.medterm.o d.ua Mar 4 15:10:15 mail postfix/smtpd[56172]: connect from unknown[81.25.227.150] This client is also listed in multiple RBLs. Mar 4 15:10:15 mail postfix/smtpd[56190]: NOQUEUE: reject_warning: RCPT from unknown[113.9.198.198]: 450 Client host rejected: cannot find your hostname, [113.9.198.198]; from=bikedev...@yahoo.co.jp to=odrawh...@dnews.com proto=SMTP helo=yahoo.co.jp Clearly a forged HELO name. Grounds for rejecting any mail from this client. Mar 4 15:10:15 mail postfix/smtpd[56190]: E35C331: client=unknown[113.9.198.198] Mar 4 15:10:18 mail postfix/cleanup[56217]: E35C331: message-id=20090304231015.e35c...@mail.lmtribune.com Mar 4 15:10:18 mail postfix/qmgr[56169]: E35C331: from=bikedev...@yahoo.co.jp, size=966, nrcpt=1 (queue active ) Mar 4 15:10:18 mail postfix/smtp[56178]: E35C331: to=odrawh...@dnews.com, relay=127.0.0.1[127.0.0.1], delay=3, status=bounced (host 127.0.0.1[127.0.0.1] said: 557 Invalid routing request - domain in BLACK LIST. (in reply to MAIL FROM command)) What?? Some idiot content_filter at 127.0.0.1 is rejecting the mail after you've already accepted it. Don't do that. Reject mail when first comes from the internet. Once mail has been accepted, a content filter must not reject the message. Mar 4 15:10:18 mail postfix/cleanup[56175]: 5ABF260: message-id=20090304231018.5abf...@mail.lmtribune.com Mar 4 15:10:18 mail postfix/qmgr[56169]: 5ABF260: from=, size=2926, nrcpt=1 (queue active) Mar 4 15:10:18 mail postfix/qmgr[56169]: E35C331: removed Mar 4 15:10:19 mail postfix/smtpd[56190]: disconnect from unknown[113.9.198.198] Mar 4 15:10:20 mail postfix/smtp[56178]: 5ABF260: to=bikedev...@yahoo.co.jp, relay=mx1.mail.yahoo.co.jp[124.83 .171.181], delay=2, status=bounced (host mx1.mail.yahoo.co.jp[124.83.171.181] said: 553 VS10-RT Possible forgery or deactivated due to abuse (#5.1.1) bikedev...@yahoo.co.jp (in reply to RCPT TO command)) Yahoo didn't send this mail, and they don't want your backscatter bounce. Eventually they (and others) will blacklist you for backscatter - ie. returning mail they never sent. You must fix your content_filter to not reject mail. Choices may include tag+deliver, quarantine, or discard, depending on what your software supports. It may offer the choice of reject or bounce, don't do that. You can also greatly reduce the load on the content filter by using one or two good RBLs to reject mail before it ever gets to the content_filter. zen.spamhaus.org is safe and very effective. -- Noel Jones I am using vexira for virus/content filtering and it has an area to put in blacklisted domains. I'll check if I can change to quarantine. ie [mailfrom-blacklist] *.ro *.nz *yourtopbrands.com *server.rwbtec.com *.co.jp etc... Would I be ahead to remove the domains from vexira and put them in the access_client file, or is there a better place in postfix to list domains I want to block? access_client listing: co.jp REJECT atripema.comREJECT atropema.comREJECT co.nz REJECT co.uk REJECT com.au REJECT snippet from main.cf: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_invalid_hostname warn_if_reject reject_unknown_hostname reject_unauth_pipelining reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain warn_if_reject reject_unknown_client reject_non_fqdn_hostname check_client_access hash:/usr/local/etc/postfix/access_client check_helo_access hash:/usr/local/etc/postfix/helo_access check_sender_access hash:/usr/local/etc/postfix/sender_access check_recipient_access hash:/usr/local/etc/postfix/recipient_access -Jim McIver
Re: root delivery for monitoring services
On 5-Mar-2009, at 11:03, Cameron Camp wrote: ad...@domain.com (expanded from r...@localhost): host mail.domain.com[1.2.3.4] said: 504 5.5.2 nob...@localhost: Sender address rejected: need fully-qualified address (in reply to RCPT TO command) Is domain.com your attempt to obfuscate the real domain? If so, use example.com or example.org or domain.tld instead of using someone else's domain. ESPECIALLY when the problem is related to the domain name! -- Strange things are afoot at the Circle K
Re: Blocking a domain and user
Jim McIver wrote: I am using vexira for virus/content filtering and it has an area to put in blacklisted domains. I'll check if I can change to quarantine. ie [mailfrom-blacklist] *.ro *.nz *yourtopbrands.com *server.rwbtec.com *.co.jp etc... If you can't change it to quarantine or tag+deliver, you might check if it can be used as an smtpd_proxy_filter. If it's intended to be used as a proxy it will probably work just fine as a postfix smtpd_proxy_filter. Would I be ahead to remove the domains from vexira and put them in the access_client file, or is there a better place in postfix to list domains I want to block? Yes, postfix will use far less resources rejecting the mail than passing it to vexira for analysis. Your vexira domain blacklist appears to be a sender domain, not a client domain, so these would go in your sender_access map. Or maybe it's all three, client, sender, helo access maps. Note the syntax difference with postfix; use example.com not *.example.com. access_client listing: co.jp REJECT atripema.comREJECT atropema.comREJECT co.nz REJECT co.uk REJECT com.au REJECT snippet from main.cf: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_invalid_hostname warn_if_reject reject_unknown_hostname reject_unauth_pipelining reject_unauth_pipelining doesn't do much good here as pipelining of recipients is allowed. Move this to smtpd_data_restrictions. reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain Since you've already rejected unauth destinations, there should be no non-fqdn recipients, and the only time there will be unknown domains will be yours if your DNS hiccups. Best to remove these two. warn_if_reject reject_unknown_client reject_non_fqdn_hostname check_client_access hash:/usr/local/etc/postfix/access_client check_helo_access hash:/usr/local/etc/postfix/helo_access check_sender_access hash:/usr/local/etc/postfix/sender_access check_recipient_access hash:/usr/local/etc/postfix/recipient_access Here is a good place to add reject_rbl_client zen.spamhaus.org and maybe some other RBLs. Season to taste. -Jim McIver -- Noel Jones
Re: Postfix + Dovecot SASL authentication.
On Mar 5, 2009, at 4:58, Miguel Da Silva - Centro de Matemática mdasi...@cmat.edu.u y wrote: Well, it came from dovecot.org :) Maybe I misunderstood your question, please let me know. I'm running Postfix 2.3.x and Dovecot 1.0. My problem was a confusing configuration. I mean, settings things up in non very wise way. The local SMTP is public and receive mail to/from local users to/from people everywhere. Now, the configuration says: if you're part of $mynetwork your mail goes with no authentication; if you are not, then you must authenticate to send mail to anyone and if you do not authenticate, then you can send mail just to local users. Is it clear? It could be worded better. My problem turned out to be following a doc that led me to believe I needed Cyrus-sasl. Indeed Dovecot is fine without it. Still curios if you are on Linux or what? Take care, Robert:-)
Re: Questions regarding Backup MX and Postfix's Queue.
Wietse Venema wrote: du...@linuxgeek.org.uk: I have a couple of quick questions: 1) How long does a message sit in the postfix queue for before it attempts a redeliver (a deffered message sat in the deffered queue)? http:/www.postfix.org/postconf.5.html#queue_run_delay http:/www.postfix.org/postconf.5.html#maximal_backoff_time http:/www.postfix.org/postconf.5.html#minimal_backoff_time http:/www.postfix.org/postconf.5.html#maximal_queue_lifetime with hotmail, and what I get is, hotmail defers the message as well as sending it to the backup mx, so that when the backup mx delivers the mail which goes through fine, hotmail are retrying as well, and you end up with two of the same message? How do you overcome this? If hotmail sends the same message to the backup and to the primary MX, then there is nothing that Postfix can do about it. Wietse Thank you Wietse. Dusty.
Re: Local mail listener
Noel Jones wrote: Looks as if the proxy filter has gotten out of sync with postfix. I would suggest starting using it as a content_filter. Once you get that working, you can see if it works with smtpd_proxy_filter. I find it handy to use -o syslog_name=postfix-something in master.cf to differentiate services; makes reading the logs easier. content_filter gives me the same results (I could be wrong, probably am, but I think content_filter is actually implemented as shorthand for a relay operation). I never saw that syslog_name parameter before - thanks. That makes logs so much clearer. I'm going back and forth checking configs. I'm using close to a vanilla Postfix config. I have no changes to any of the default restrictions. I've setup this mail server with two NIC's, both on the same subnet. Now that (I think) I've fixed my routing issues, traffic seems to work properly (unless you think a faulty routing table is causing my current problem). ASSP listens on 192.168.0.10, and Postfix on 192.168.0.11. mynetworks includes 192.168.0.0/24. Is there any other Postfix setting I need to check/change - or at this point does the fault lie in my ASSP config? -- Daniel
Re: Postfix + Dovecot SASL authentication.
Robert Ober escribió: On Mar 5, 2009, at 4:58, Miguel Da Silva - Centro de Matemática mdasi...@cmat.edu.uy wrote: Well, it came from dovecot.org :) Maybe I misunderstood your question, please let me know. I'm running Postfix 2.3.x and Dovecot 1.0. My problem was a confusing configuration. I mean, settings things up in non very wise way. The local SMTP is public and receive mail to/from local users to/from people everywhere. Now, the configuration says: if you're part of $mynetwork your mail goes with no authentication; if you are not, then you must authenticate to send mail to anyone and if you do not authenticate, then you can send mail just to local users. Is it clear? It could be worded better. My problem turned out to be following a doc that led me to believe I needed Cyrus-sasl. Indeed Dovecot is fine without it. Still curios if you are on Linux or what? Take care, Robert:-) Yes I am. GNU/Linux Debian Lenny. -- Miguel Da Silva Administrador Junior de Sistemas Unix Centro de Matemática - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la República - http://www.rau.edu.uy
Re: restricting who can be sent to.
2009/3/6 Carver Banks carver.ba...@trustvesta.com: Or so I thought..., that did restrict all mail to the internal recipients as well. I need anyone in mydomain.com to be able to email anyone in mydomain.local, but I need users on mydomain.local to only be allowed to email a few people in mydomain.com, and none of the other members of mydoman.local. I think postfix may not be able to accomplish what I desire, if I am wrong please correct me. I'm not *certain* this will work as expected desired, but you could try putting a check_sender_access table before the check_recipient_access table. You can then OK the mydomain.com domain in check_sender_access, then do the check_recipient_access as previously described. The catch is that the sender can make up whatever they want for the sender address, so you really must not use this in a public-facing system, for the reasons described in http://www.postfix.org/RESTRICTION_CLASS_README.html
Re: PATCH: Possible reasons for qmgr loading the system?
Wietse Venema:
Santiago Romero:
Please wait for an updated patch, we believe we have identified the
cause and reproduced the symptoms (in that order). I have a candidate
patch, but I expect Wietse will send an updated more polished version
in the not too distant future.
Ok, I'll wait for it. I'm going to roll back to ubuntu packages (I
already applied the patch and was testing it).
It will be later today. I don't have much time so I want to have
it really right the first time. Code that is right takes more work
than code that works.
To apply this patch, cd into the Postfix-2.5.* top-level source
directory and execute:
$ patch thismessage
We were able to reproduce the scheduler looping problem, and it
does not recur with the patched version.
Wietse
diff -cr /var/tmp/postfix-2.5.6/src/oqmgr/qmgr_transport.c
src/oqmgr/qmgr_transport.c
*** /var/tmp/postfix-2.5.6/src/oqmgr/qmgr_transport.c Sun Dec 2 13:13:26 2007
--- src/oqmgr/qmgr_transport.c Thu Mar 5 16:06:43 2009
***
*** 286,291
--- 286,293
continue;
need = xport-pending + 1;
for (queue = xport-queue_list.next; queue; queue = queue-peers.next) {
+ if (QMGR_QUEUE_READY(queue) == 0)
+ continue;
if ((need -= MIN5af51743e4eef(queue-window - queue-busy_refcount,
queue-todo_refcount)) = 0) {
QMGR_LIST_ROTATE(qmgr_transport_list, xport);
diff -cr /var/tmp/postfix-2.5.6/src/qmgr/qmgr.h src/qmgr/qmgr.h
*** /var/tmp/postfix-2.5.6/src/qmgr/qmgr.h Sat Dec 8 11:01:59 2007
--- src/qmgr/qmgr.h Thu Mar 5 16:36:32 2009
***
*** 436,441
--- 436,442
extern QMGR_ENTRY *qmgr_job_entry_select(QMGR_TRANSPORT *);
extern QMGR_PEER *qmgr_peer_select(QMGR_JOB *);
+ extern void qmgr_job_blocker_update(QMGR_QUEUE *);
extern QMGR_JOB *qmgr_job_obtain(QMGR_MESSAGE *, QMGR_TRANSPORT *);
extern void qmgr_job_free(QMGR_JOB *);
diff -cr /var/tmp/postfix-2.5.6/src/qmgr/qmgr_entry.c src/qmgr/qmgr_entry.c
*** /var/tmp/postfix-2.5.6/src/qmgr/qmgr_entry.cFri Dec 14 17:47:21 2007
--- src/qmgr/qmgr_entry.c Thu Mar 5 16:29:46 2009
***
*** 299,327
}
/*
! * If the queue was blocking some of the jobs on the job list, check if
! * the concurrency limit has lifted. If there are still some pending
! * deliveries, give it a try and unmark all transport blockers at once.
! * The qmgr_job_entry_select() will do the rest. In either case make sure
! * the queue is not marked as a blocker anymore, with extra handling of
! * queues which were declared dead.
*
! * Note that changing the blocker status also affects the candidate cache.
! * Most of the cases would be automatically recognized by the current job
! * change, but we play safe and reset the cache explicitly below.
! *
! * Keeping the transport blocker tag odd is an easy way to make sure the
tag
! * never matches jobs that are not explicitly marked as blockers.
*/
! if (queue-blocker_tag == transport-blocker_tag) {
! if (queue-window queue-busy_refcount queue-todo.next != 0) {
! transport-blocker_tag += 2;
! transport-job_current = transport-job_list.next;
! transport-candidate_cache_current = 0;
! }
! if (queue-window queue-busy_refcount || QMGR_QUEUE_THROTTLED(queue))
! queue-blocker_tag = 0;
}
/*
* When there are no more entries for this peer, discard the peer
--- 299,323
}
/*
! * We implement a rate-limited queue by emulating a slow delivery
! * channel. We insert the artificial delays with qmgr_queue_suspend().
*
! * When a queue is suspended, we must postpone any job scheduling
decisions
! * until the queue is resumed. Otherwise, we make those decisions now.
! * The job scheduling decisions are made by qmgr_job_blocker_update().
*/
! if (which == QMGR_QUEUE_BUSY transport-rate_delay 0) {
! if (queue-window 1)
! msg_panic(%s: queue %s/%s: window %d 1 on rate-limited service,
! myname, transport-name, queue-name, queue-window);
! if (QMGR_QUEUE_THROTTLED(queue))/* XXX */
! qmgr_queue_unthrottle(queue);
! if (QMGR_QUEUE_READY(queue))
! qmgr_queue_suspend(queue, transport-rate_delay);
}
+ if (!QMGR_QUEUE_SUSPENDED(queue)
+queue-blocker_tag == transport-blocker_tag)
+ qmgr_job_blocker_update(queue);
/*
* When there are no more entries for this peer, discard the peer
***
*** 336,354
*/
if (which == QMGR_QUEUE_BUSY)
queue-last_done = event_time();
-
- /*
- * Suspend a rate-limited queue, so that mail trickles out.
- */
- if (which == QMGR_QUEUE_BUSY
Re: Local mail listener
Daniel L. Miller wrote: Noel Jones wrote: Looks as if the proxy filter has gotten out of sync with postfix. I would suggest starting using it as a content_filter. Once you get that working, you can see if it works with smtpd_proxy_filter. I find it handy to use -o syslog_name=postfix-something in master.cf to differentiate services; makes reading the logs easier. content_filter gives me the same results (I could be wrong, probably am, but I think content_filter is actually implemented as shorthand for a relay operation). I never saw that syslog_name parameter before - thanks. That makes logs so much clearer. I'm going back and forth checking configs. I'm using close to a vanilla Postfix config. I have no changes to any of the default restrictions. I've setup this mail server with two NIC's, both on the same subnet. Now that (I think) I've fixed my routing issues, traffic seems to work properly (unless you think a faulty routing table is causing my current problem). ASSP listens on 192.168.0.10, and Postfix on 192.168.0.11. mynetworks includes 192.168.0.0/24. Is there any other Postfix setting I need to check/change - or at this point does the fault lie in my ASSP config? The content_filter accepts and queues the mail, then relays the message to the content_filter. This is a little simpler than the smtpd_proxy_filter which makes simultaneous connections to the originating client and the filter. The postfix content_filter feature is widely used and considered quite robust. I'll bet the ASSP folks say the same thing... A TCP capture of the incoming session should give more insight where things go wrong. Multiple NICs on the same subnet is asking for trouble. Any way you can disable one to see if that helps? -- Noel Jones
Re: Blocking a domain and user
Noel Jones wrote: Jim McIver wrote: I am using vexira for virus/content filtering and it has an area to put in blacklisted domains. I'll check if I can change to quarantine. ie [mailfrom-blacklist] *.ro *.nz *yourtopbrands.com *server.rwbtec.com *.co.jp etc... If you can't change it to quarantine or tag+deliver, you might check if it can be used as an smtpd_proxy_filter. If it's intended to be used as a proxy it will probably work just fine as a postfix smtpd_proxy_filter. Would I be ahead to remove the domains from vexira and put them in the access_client file, or is there a better place in postfix to list domains I want to block? Yes, postfix will use far less resources rejecting the mail than passing it to vexira for analysis. Your vexira domain blacklist appears to be a sender domain, not a client domain, so these would go in your sender_access map. Or maybe it's all three, client, sender, helo access maps. Note the syntax difference with postfix; use example.com not *.example.com. access_client listing: co.jp REJECT atripema.comREJECT atropema.comREJECT co.nz REJECT co.uk REJECT com.au REJECT snippet from main.cf: smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_invalid_hostname warn_if_reject reject_unknown_hostname reject_unauth_pipelining reject_unauth_pipelining doesn't do much good here as pipelining of recipients is allowed. Move this to smtpd_data_restrictions. reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain Since you've already rejected unauth destinations, there should be no non-fqdn recipients, and the only time there will be unknown domains will be yours if your DNS hiccups. Best to remove these two. warn_if_reject reject_unknown_client reject_non_fqdn_hostname check_client_access hash:/usr/local/etc/postfix/access_client check_helo_access hash:/usr/local/etc/postfix/helo_access check_sender_access hash:/usr/local/etc/postfix/sender_access check_recipient_access hash:/usr/local/etc/postfix/recipient_access Here is a good place to add reject_rbl_client zen.spamhaus.org and maybe some other RBLs. Season to taste. -Jim McIver -- Noel Jones So in postfix to block: *.ru *.ro *.bg I would just put: ru ro bg thx, -jm
Re: Local mail listener
Noel Jones wrote: Daniel L. Miller wrote: Noel Jones wrote: Looks as if the proxy filter has gotten out of sync with postfix. I would suggest starting using it as a content_filter. Once you get that working, you can see if it works with smtpd_proxy_filter. I find it handy to use -o syslog_name=postfix-something in master.cf to differentiate services; makes reading the logs easier. content_filter gives me the same results (I could be wrong, probably am, but I think content_filter is actually implemented as shorthand for a relay operation). I never saw that syslog_name parameter before - thanks. That makes logs so much clearer. I'm going back and forth checking configs. I'm using close to a vanilla Postfix config. I have no changes to any of the default restrictions. I've setup this mail server with two NIC's, both on the same subnet. Now that (I think) I've fixed my routing issues, traffic seems to work properly (unless you think a faulty routing table is causing my current problem). ASSP listens on 192.168.0.10, and Postfix on 192.168.0.11. mynetworks includes 192.168.0.0/24. Is there any other Postfix setting I need to check/change - or at this point does the fault lie in my ASSP config? The content_filter accepts and queues the mail, then relays the message to the content_filter. This is a little simpler than the smtpd_proxy_filter which makes simultaneous connections to the originating client and the filter. The postfix content_filter feature is widely used and considered quite robust. I'll bet the ASSP folks say the same thing... A TCP capture of the incoming session should give more insight where things go wrong. Multiple NICs on the same subnet is asking for trouble. Any way you can disable one to see if that helps? -- Noel Jones I can switch to that - I thought it would simplify my setup. The alternative (which I've used on other servers) is to use interface aliases to support multiple IP's. Since I'm setting up a virtual server I thought I'd take advantage of cheap hardware and just throw in a card. I wanted separate IP's so one would get published for local clients' use of port 25, and the other would be used for inbound internet traffic. Since I'm going to be using port forwarding from my router/firewall anyway - I guess it doesn't matter if the ASSP listener isn't port 25 - so I'll change it to just be one IP (plus localhost, if necessary) with different ports. But it doesn't feel like that's the problem right now. In theory...I think...ASSP is supposed to be a near transparent proxy. It may add headers...but SHOULDN'T change the smtp stream. So, if I have ASSP configured to listen on a given port, and relay back to a Postfix listener, in theory there should be no difference (to a client) between connecting to the ASSP relay listener vs connecting to the Postfix listener. At this time - that is not the case. Connecting to the Postfix listener directly works perfectly. Trying the ASSP listener fails. A telnet to the ASSP listener gives me Postfix responses, so I know at least part of the relay operation is working (I set -o myhostname to something different for that listener just to verify). Short break - I wanted to change smtpd_banner - but Postfix didn't seem real happy with changing that in a master.cf line. So from telnet, I could HELO, MAIL FROM, and RCPT TO - and things seemed ok. It was after those steps that communication breaks down. -- Daniel
Re: Local mail listener
Daniel L. Miller a écrit : [snip] Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok This is the thing to look at. did the proxy send 5xx 250 2.1.5 Ok? Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: non-SMTP command from unknown[192.168.0.90]: Message-ID: 49af7d71.70...@amfes.com I guess you did a manual test. if so, don't send headers if your DATA DATA command was rejected, but client sent headers. if you did a manual test, don't send headers if DATA is rejected. [snip]
Re: Spam attacks
Paweł Leśniak a écrit : W dniu 2009-03-05 06:30, Mihira Fernando pisze: Have you ever tried sending an e-greeting to someone via 123greeting.com or some other similar site ? You're definitely right - I didn't use that one before. Look what I get in logs: Mar 5 09:41:50 lola postfix/smtpd[20278]: warning: 72.233.20.39: address not listed for hostname www.123greetings.com So they are surely doing something nasty... Anyways: Mar 5 09:41:52 lola postgrey[22558]: action=greylist, reason=new, client_name=unknown, client_address=72.233.20.54, sender=eca...@123greetings.com, recipient=pa...@lesniakowie.com So, I have really no idea why are you all advocating that some services use MY EMAIL ADDRESS as ENVELOPE SENDER. I don't know if such services till do that, but they used to. it is however probable that major ones have stopped this, because they have been made aware of the problem that it causes. and also because of SPF, even if it is not widely used. It's something what should never be done. there are two different things: - because of spam, such practice is not a good idea - but if there were never any spam, it would be ok the discussion continued because you stated that this behaviour should never happen. but many people don't like adding unnecessary constraints to protocols. so even if we don't like the practice under discussion, we don't like it because of the spam problem, not because it should never happen. In particular, we may add exceptions to accept some such mail, and in any case, we don't blacklist the servers that use this practice. because they may be doing something we don't like much, but they are not misconfigured in a strict sense. [snip]
Re: That Relay Access Denied Thing (Solved, no, Really!)
LuKreme a écrit : On 4-Mar-2009, at 15:18, Robert A. Ober wrote: Thanks to Brian and others for hanging in there with me! I think you owe everyone on this thread (which I was not part of, so no self-interest) a beer. :) I wasn't either, but I want a Franziskaner ;-p for OP: sasl is a standard. and currently postfix supports two implementations: - cyrus sasl - dovecot sasl if you use dovecot, then dovecot sasl is the right choice with one limitation: it only works for smtpd (when you authenticate to postfix) and not in smtp (when postfix needs to authenticate to another server)
Conditionally change FROM
Dear, I want/need to change the FROM part of the e-mails if they are forwarded to the (sub-)domains (sub.)xxx.tld Where in the documentation should I look for a solution? Thanks, Yves
Re: Messages Are Refused
Carlos Williams a écrit : Thanks for that info. Can someone also comment on this? I asked a friend via email and this was his response to the same issue: ** I used nslookup to verify the address your queue is showing, and it does correspond to je.jfcom.mil. But a request for the mail-exchangers for jfcom.mil does not indicate that this host should be receiving mail. $ host -t mx je.jfcom.mil je.jfcom.mil has no MX record so mail should go the A record address: $ host -t A je.jfcom.mil je.jfcom.mil has address 140.32.76.138 which is what your postfix tried. The mail-exchangers for that domain are: smtp01.jfcom.mil smtp02.jfcom.mil no, these are the MX for jfcom.mil. should mail for joe.com go to .com MX servers if I decide not to setup an MX for joe.com? So this problem resolves into a new one: how did your Postfix come up with the name je.jfcom.mil to send messages to? Did the user explicitly specify that host as a target? probably so. the recipient is specified by whomever sent the message, be it a user or a program. a common case is when you reply to a mail where the From: header used a private domain. Or did Postfix get bad info from its DNS lookup of MX records? No. Or did something else happen to misdirect these messages? Only a good look at the mail headers for the offending messages will tell you that. not really. When a message finally expires and is sent back to its originator (or to the postmaster), you will need to examine the headers to see at what stage of forwarding a host made the choice to use the wrong mail exchanger. Then further work will be needed to figure out why. ** My question is how did he find smtp01.jfcom.mil? And more important, why then is my Postfix server trying to send to a different smtp address?
Re: Local mail listener
OK - here's what I see now using telnet. First, connecting directly to the ASSP listener via telnet: r...@mailserver:/etc/postfix# telnet 192.168.0.10 225 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. 220 Postfix-ASSP.amfeslan.local ESMTP Postfix (Ubuntu) helo abc.com 250 Postfix-ASSP.amfeslan.local mail from:dmil...@amfes.com 250 2.1.0 Ok rcpt to:fireexp...@hotmail.com 250 2.1.5 Ok data 354 End data with CRLF.CRLF This looks - and works - fine. Now try the same thing connecting to the Postfix listener that proxies to ASSP: r...@mailserver:/etc/postfix# telnet 192.168.0.11 25 Trying 192.168.0.11... Connected to 192.168.0.11. Escape character is '^]'. 220 mailserver.amfeslan.local ESMTP Postfix (Ubuntu) helo abc.com 250 mailserver.amfeslan.local mail from:dmil...@amfes.com 250 2.1.0 Ok rcpt to:fireexp...@hotmail.com 250 2.1.5 Ok data 250 2.1.5 Ok subject:subject test 221 2.7.0 Error: I can break rules, too. Goodbye. Connection closed by foreign host. Am I looking at a mis-configured Postfix? Or is ASSP interfering with the smtp communication? -- Daniel
Re: Local mail listener
Daniel L. Miller wrote: OK - here's what I see now using telnet. First, connecting directly to the ASSP listener via telnet: r...@mailserver:/etc/postfix# telnet 192.168.0.10 225 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. 220 Postfix-ASSP.amfeslan.local ESMTP Postfix (Ubuntu) helo abc.com 250 Postfix-ASSP.amfeslan.local mail from:dmil...@amfes.com 250 2.1.0 Ok rcpt to:fireexp...@hotmail.com 250 2.1.5 Ok data 354 End data with CRLF.CRLF This looks - and works - fine. Now try the same thing connecting to the Postfix listener that proxies to ASSP: r...@mailserver:/etc/postfix# telnet 192.168.0.11 25 Trying 192.168.0.11... Connected to 192.168.0.11. Escape character is '^]'. 220 mailserver.amfeslan.local ESMTP Postfix (Ubuntu) helo abc.com 250 mailserver.amfeslan.local mail from:dmil...@amfes.com 250 2.1.0 Ok rcpt to:fireexp...@hotmail.com 250 2.1.5 Ok data 250 2.1.5 Ok subject:subject test 221 2.7.0 Error: I can break rules, too. Goodbye. Connection closed by foreign host. Am I looking at a mis-configured Postfix? Or is ASSP interfering with the smtp communication? For clarification, when I say ASSP listener, I mean I'm connecting to ASSP, which is supposed to be a transparent proxy back to Postfix. I do not have a Postfix process listening at 192.168.0.10:225. However, the Postfix listener at 192.168.0.11:25 is a Postfix process, which is supposed to relay to 192.168.0.10:225. -- Daniel
Re: Question about how Postfix sends the EHLO/HELO
Noel Jones a écrit : [snip] Looking at the headers of the message you sent to the list: Received: from neskowin.linfield.edu (neskowin.linfield.edu [192.147.171.21]) by russian-caravan.cloud9.net (Postfix) with SMTP id 55D0AFD9F3 for postfix-users@postfix.org; Wed, 4 Mar 2009 14:33:37 -0500 (EST) Received: from neskowin.linfield.edu (localhost.localdomain [127.0.0.1]) by linfield.edu (Postfix) with SMTP id 596B158120 for postfix-users@postfix.org; Wed, 4 Mar 2009 11:33:36 -0800 (PST) Received: from exchangedb.wfo.linfield.edu (exchangedb.wfo.linfield.edu [10.170.131.27]) by neskowin.linfield.edu (Postfix) with ESMTP id 410365811C for postfix-users@postfix.org; Wed, 4 Mar 2009 11:33:36 -0800 (PST) Received: from 10.219.255.241 ([10.219.255.241]) by exchangedb.wfo.linfield.edu ([10.170.131.27]) via Exchange Front-End Server exchange.linfield.edu ([10.170.131.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Mar 2009 19:33:36 + the only numeric HELO I see is from the originating client. but if that's the explanation, then it's a bug, because that one was submitted with HTTP-DAV, so there's no HELO at all. IMHO SpamAssassin should not be applying this test to all headers, only the topmost trusted header. hmm. I am more interested with detecting borked hops before the last one (which would be rejected by postfix). I don't remember if I asked this here or on SA list (I think it was on SA list), but which (not oudated) clients still helo with a naked IP? time to nake'em, no? Next wild guess is that the recipient server has misconfigured SA. most probably, it's in stock SA. there was some recent discussion about this. I think the helo checks in SA need a review... You can fix this with a header_checks rule to either REWRITE the offending header to X-Received:... or just IGNORE (remove) it. -- Noel Jones
Re: Blocking email from own domain on From: header
Thomas Ledbetter a écrit : OK.. How about this one: I have had good luck blocking SPAM email which has a MAIL FROM: address in my own domain, by blocking all email from my domain in an access map on 'smtpd_sender_restrictions', and then listing 'permit_mynetworks' and 'permit_sasl_authenticated' first. I call this 'domain restriction' because it allows you to restrict email that purports to be from your domain, but was not sent via an authorized source - a host on your network, or a user which logged in via SMTP AUTH. Now Im seeing SPAM that has a 'From:' header address at my own domain, but the MAIL FROM: is different. do you realize that this is exactly the case when you receive your post via this list? It gets in the perimeter, and then my anti-spam software whitelists it, because my domain is on the whitelist! fix your anti-spam whitelist. do not whitelisted based on sender or headers. if you need that, check the origin (received header), spf, or dkim. all these are possible in spamassassin. Does anyone know of a similar trick to somehow block all email with a From: address from a particular domain, but let through anything that comes from your own network, or email that was sent via SMTP AUTH? then you wouldn't receive your posts from the mailing list server. I use header_checks, but dont know a way to do this.
Re: Local mail listener
Daniel L. Miller: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Your proxy replies with 250 2.1.5 Ok to the DATA command. 250 Is an incorrect reply. It should be 354 for success, 5xx or 4xx for failure. And because 250 is not a valid DATA reply, Postfix does not go into the DATA phase. Postfix then forwards the 250 2.1.5 Ok to your SMTP client. When you talk directly to Postfix, this is why you see 250 2.1.5 Ok in response to DATA. This is clearly bogus, and I'll fix Postfix so it will send some appropriate reply instead. But I won't be posting patches for that. Unfortunately, your SMTP client does not recognize 250 as an invalid response, and it sends the message headers while Postfix expects an SMTP command. Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: non-SMTP command from unknown[192.168.0.90]: Message-ID: 49af7d71.70...@amfes.com Therefore, Postfix hangs up because it thinks the client is a spammer. Wietse
Do not include first 'Received' header when received via 465/587?
Hi, I have a client that I have set up the submission port and 465 (for submission over raw SSL). They use many different internet connections, and a few of them (Panera Bread in particular) have their IP on blacklists. Because the IP gets included in the first Received header from Postfix, some sites are catching the mail as spam (apparently some sites scan all 'Received' headers for DNSBL's? Sigh.) I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. I'm not finding a clean way of doing this; hoping someone has been down this road before so I don't have to reinvent the wheel. ;) Appreciate any advice - thanks much! -Nate
Re: Do not include first 'Received' header when received via 465/587?
Nate Carlson: Hi, I have a client that I have set up the submission port and 465 (for submission over raw SSL). They use many different internet connections, and a few of them (Panera Bread in particular) have their IP on blacklists. Because the IP gets included in the first Received header from Postfix, some sites are catching the mail as spam (apparently some sites scan all 'Received' headers for DNSBL's? Sigh.) I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. I'm not finding a clean way of doing this; hoping someone has been down this road before so I don't have to reinvent the wheel. ;) Appreciate any advice - thanks much! $ man header_checks | less +/IGNORE $ man header_checks | less +/REPLACE Wietse
Re: Do not include first 'Received' header when received via 465/587?
On Thu, 5 Mar 2009, Wietse Venema wrote: I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. $ man header_checks | less +/IGNORE $ man header_checks | less +/REPLACE Thanks.. I've got that, but I'm not finding a way to only match mail that comes in via Submission, and not via regular SMTP. Is there a way to tell Postfix to only apply the header_checks to certain mail processes? I suppose I could do something like 'no_header_body_checks' on the main SMTP process, but it'd be nice to be able to do some checks there in the future too. -Nate
Re: Local mail listener
Wietse Venema wrote: Daniel L. Miller: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Your proxy replies with 250 2.1.5 Ok to the DATA command. 250 Is an incorrect reply. It should be 354 for success, 5xx or 4xx for failure. And because 250 is not a valid DATA reply, Postfix does not go into the DATA phase. Postfix then forwards the 250 2.1.5 Ok to your SMTP client. When you talk directly to Postfix, this is why you see 250 2.1.5 Ok in response to DATA. This is clearly bogus, and I'll fix Postfix so it will send some appropriate reply instead. But I won't be posting patches for that. Wow. Last thing I expected was to hear I found a bug in Postfix 2.5. I'm also pursuing this on the ASSP list - but something else bothers me. To my (extremely limited) knowledge - ASSP should just be passing on responses it receives from the servers it is proxying. That first 250 2.1.5 Ok is theoretically coming from Postfix, not ASSP - please see my other email that had a telnet transcript. Why is it that if I direct telnet to ASSP - which then proxies responses from Postfix - it works fine? But if I telnet to Postfix first, which then uses content_filter or smtpd_proxy_filter to connect to the same ASSP port I telnet'ed to previously - I have this DATA problem? This feels like I need to adjust something in Postfix for the relay to work properly. -- Daniel
Re: Do not include first 'Received' header when received via 465/587?
Nate Carlson wrote: On Thu, 5 Mar 2009, Wietse Venema wrote: I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. $ man header_checks | less +/IGNORE $ man header_checks | less +/REPLACE Thanks.. I've got that, but I'm not finding a way to only match mail that comes in via Submission, and not via regular SMTP. Is there a way to tell Postfix to only apply the header_checks to certain mail processes? I suppose I could do something like 'no_header_body_checks' on the main SMTP process, but it'd be nice to be able to do some checks there in the future too. You can make the change in master.cf. Find the submission line, and add the parameter. For example: submission inet n - - - - smtpd -o header_checks=hash:/etc/postfix/maps/submission_header_checks -- Daniel
Re: Local mail listener
Daniel L. Miller: [ Charset ISO-8859-1 unsupported, converting... ] Wietse Venema wrote: Daniel L. Miller: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Your proxy replies with 250 2.1.5 Ok to the DATA command. 250 Is an incorrect reply. It should be 354 for success, 5xx or 4xx for failure. And because 250 is not a valid DATA reply, Postfix does not go into the DATA phase. Postfix then forwards the 250 2.1.5 Ok to your SMTP client. When you talk directly to Postfix, this is why you see 250 2.1.5 Ok in response to DATA. This is clearly bogus, and I'll fix Postfix so it will send some appropriate reply instead. But I won't be posting patches for that. Wow. Last thing I expected was to hear I found a bug in Postfix 2.5. THIS IS NOT A POSTFIX BUG. POSTFIX IS ONLY THE MESSENGER. The proxy filter replies with SMTP reply code 2.1.5 to the SMTP DATA command. That is the problem. My fix only makes sure that this bogus reply from the proxy filter would not confuse naive SMTP client software, so that it will stop sending message-id etc. headers after it receives a 2.1.5 reply. You can log the conversation between SMTP client, Postfix and the proxy filter by adding one -v option on the smtpd command line in master.cf, or by using debug_peer_list and debug_peer_level in main.cf. Wietse
Re: Do not include first 'Received' header when received via 465/587?
On Thu, Mar 05, 2009 at 05:35:11PM -0800, Daniel L. Miller wrote: I suppose I could do something like 'no_header_body_checks' on the main SMTP process, but it'd be nice to be able to do some checks there in the future too. You can make the change in master.cf. Find the submission line, and add the parameter. For example: submission inet n - - - - smtpd -o header_checks=hash:/etc/postfix/maps/submission_header_checks No, this is useless, smtpd does not implement header_checks. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Do not include first 'Received' header when received via 465/587?
Daniel L. Miller wrote: Nate Carlson wrote: On Thu, 5 Mar 2009, Wietse Venema wrote: I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. $ man header_checks | less +/IGNORE $ man header_checks | less +/REPLACE Thanks.. I've got that, but I'm not finding a way to only match mail that comes in via Submission, and not via regular SMTP. Is there a way to tell Postfix to only apply the header_checks to certain mail processes? I suppose I could do something like 'no_header_body_checks' on the main SMTP process, but it'd be nice to be able to do some checks there in the future too. You can make the change in master.cf. Find the submission line, and add the parameter. For example: submission inet n - - - - smtpd -o header_checks=hash:/etc/postfix/maps/submission_header_checks You're on the right track, but your example won't work - header_checks are a property of the cleanup process, not smtpd. And while it's legal to use hash: maps for header_checks, it's not very useful. The solution is to define an alternate cleanup service for submission, and then define alternate header_checks for that cleanup submission ... smtpd -o cleanup_service_name=cleanup_submission cleanup_submission ... cleanup -o header_checks=pcre:/path/to/header_checks
Re: Do not include first 'Received' header when received via 465/587?
Noel Jones wrote: Daniel L. Miller wrote: Nate Carlson wrote: On Thu, 5 Mar 2009, Wietse Venema wrote: I've found tricks to remove or edit Received headers for specific IP's via 'header_checks'; however, what I'd like to be able to do is either remove the header altogether or modify the IP to one of the IP's that we own for all authenticated users that submit mail via 465/587. $ man header_checks | less +/IGNORE $ man header_checks | less +/REPLACE Thanks.. I've got that, but I'm not finding a way to only match mail that comes in via Submission, and not via regular SMTP. Is there a way to tell Postfix to only apply the header_checks to certain mail processes? I suppose I could do something like 'no_header_body_checks' on the main SMTP process, but it'd be nice to be able to do some checks there in the future too. You can make the change in master.cf. Find the submission line, and add the parameter. For example: submission inet n - - - - smtpd -o header_checks=hash:/etc/postfix/maps/submission_header_checks You're on the right track, but your example won't work - header_checks are a property of the cleanup process, not smtpd. And while it's legal to use hash: maps for header_checks, it's not very useful. The solution is to define an alternate cleanup service for submission, and then define alternate header_checks for that cleanup submission ... smtpd -o cleanup_service_name=cleanup_submission cleanup_submission ... cleanup -o header_checks=pcre:/path/to/header_checks Oh, and recent postfix marks authenticated headers; note the ESTMPSA. S = StartTLS, A = Authenticated Received: from [192.168.5.108] (adsl-19-247-14.bna.bellsouth.net [68.19.247.14]) by mgate2.vbhcs.org (Postfix) with ESMTPSA id BAF4A797A6A; Thu, 5 Mar 2009 20:09:39 -0600 (CST) a regexp something like /^(Received: .* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 should do the trick. -- Noel Jones
Re: Conditionally change FROM
On Fri, Mar 06, 2009 at 12:32:53AM +0100, Yves Kreis wrote: Dear, I want/need to change the FROM part of the e-mails if they are forwarded to the (sub-)domains (sub.)xxx.tld Where in the documentation should I look for a solution? generic(5) transport(5) master(5) -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Local mail listener
Wietse Venema wrote: Daniel L. Miller: [ Charset ISO-8859-1 unsupported, converting... ] Wietse Venema wrote: Daniel L. Miller: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Your proxy replies with 250 2.1.5 Ok to the DATA command. 250 Is an incorrect reply. It should be 354 for success, 5xx or 4xx for failure. And because 250 is not a valid DATA reply, Postfix does not go into the DATA phase. Postfix then forwards the 250 2.1.5 Ok to your SMTP client. When you talk directly to Postfix, this is why you see 250 2.1.5 Ok in response to DATA. This is clearly bogus, and I'll fix Postfix so it will send some appropriate reply instead. But I won't be posting patches for that. Wow. Last thing I expected was to hear I found a bug in Postfix 2.5. THIS IS NOT A POSTFIX BUG. POSTFIX IS ONLY THE MESSENGER. Okay, okay!! I take it back! I misunderstood! It's not Postfix bug! The proxy filter replies with SMTP reply code 2.1.5 to the SMTP DATA command. That is the problem. My fix only makes sure that this bogus reply from the proxy filter would not confuse naive SMTP client software, so that it will stop sending message-id etc. headers after it receives a 2.1.5 reply. You can log the conversation between SMTP client, Postfix and the proxy filter by adding one -v option on the smtpd command line in master.cf, or by using debug_peer_list and debug_peer_level in main.cf. Wietse I tried the -v option (wow - lot of stuff goes on behind the scenes, doesn't it?!). What I still don't understand (I'm dense, I know, but please bear with me) is why there is a difference between connecting through Postfix to ASSP (and back to Postfix) and connecting to ASSP directly (and back to Postfix). Somehow, someway, there is a difference between telnet - or my mail client (Thunderbird) - connecting directly to ASSP, vs. connecting to Postfix and the Postfix smtp process connects to ASSP. Just to be 100% sure we're communicating, I'll try a picture: Client --- 192.168.0.10:225 (ASSP) --- 192.168.0.11:325 (Postfix smtpd) --- internet vs Client --- 192.168.0.11:25 (Postfix smtpd with proxy parameter) --- 192.168.0.10:225 (ASSP) --- 192.168.0.11:325 (Postfix smtpd) --- internet Since I'm not adjusting the ASSP settings between connections - I don't see where this is an ASSP configuration problem. Is there anything about one of the _filter parameters that would change the communication? Do I need to change something in a transport? -- Daniel
Re: Local mail listener
Daniel L. Miller wrote: Wietse Venema wrote: Daniel L. Miller: [ Charset ISO-8859-1 unsupported, converting... ] Wietse Venema wrote: Daniel L. Miller: Mar 4 23:21:33 mailserver postfix/smtpd[20964]: warning: proxy inet:192.168.0.10:225 rejected DATA: 250 2.1.5 Ok Your proxy replies with 250 2.1.5 Ok to the DATA command. 250 Is an incorrect reply. It should be 354 for success, 5xx or 4xx for failure. And because 250 is not a valid DATA reply, Postfix does not go into the DATA phase. Postfix then forwards the 250 2.1.5 Ok to your SMTP client. When you talk directly to Postfix, this is why you see 250 2.1.5 Ok in response to DATA. This is clearly bogus, and I'll fix Postfix so it will send some appropriate reply instead. But I won't be posting patches for that. Wow. Last thing I expected was to hear I found a bug in Postfix 2.5. THIS IS NOT A POSTFIX BUG. POSTFIX IS ONLY THE MESSENGER. Okay, okay!! I take it back! I misunderstood! It's not Postfix bug! The proxy filter replies with SMTP reply code 2.1.5 to the SMTP DATA command. That is the problem. My fix only makes sure that this bogus reply from the proxy filter would not confuse naive SMTP client software, so that it will stop sending message-id etc. headers after it receives a 2.1.5 reply. You can log the conversation between SMTP client, Postfix and the proxy filter by adding one -v option on the smtpd command line in master.cf, or by using debug_peer_list and debug_peer_level in main.cf. Wietse I tried the -v option (wow - lot of stuff goes on behind the scenes, doesn't it?!). What I still don't understand (I'm dense, I know, but please bear with me) is why there is a difference between connecting through Postfix to ASSP (and back to Postfix) and connecting to ASSP directly (and back to Postfix). Somehow, someway, there is a difference between telnet - or my mail client (Thunderbird) - connecting directly to ASSP, vs. connecting to Postfix and the Postfix smtp process connects to ASSP. Just to be 100% sure we're communicating, I'll try a picture: Client --- 192.168.0.10:225 (ASSP) --- 192.168.0.11:325 (Postfix smtpd) --- internet vs Client --- 192.168.0.11:25 (Postfix smtpd with proxy parameter) --- 192.168.0.10:225 (ASSP) --- 192.168.0.11:325 (Postfix smtpd) --- internet Since I'm not adjusting the ASSP settings between connections - I don't see where this is an ASSP configuration problem. Is there anything about one of the _filter parameters that would change the communication? Do I need to change something in a transport? Here's the other weird thing. If, after I enter the DATA command and get that bogus 2.1.5, if I enter a second DATA command - it works. smtpd -v log excerpt - with the first DATA: Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: warning: proxy inet:192.168.0.10:225 rejected data: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: 250 2.1.5 Ok then... Mar 5 18:54:07 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:07 mailserver local/smtpd[25237]: inet:192.168.0.10:225: data Mar 5 18:54:07 mailserver assp/smtpd[25240]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:07 mailserver assp/smtpd[25240]: smtp-local.amfeslan.local[192.168.0.11]: 354 End data with CRLF.CRLF Mar 5 18:54:07 mailserver local/smtpd[25237]: inet:192.168.0.10:225: 354 End data with CRLF.CRLF Mar 5 18:54:07 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: 354 End data with CRLF.CRLF Mar 5 18:54:18 mailserver local/smtpd[25237]: inet:192.168.0.10:225: . -- Daniel
Re: Do not include first 'Received' header when received via 465/587?
On 5-Mar-2009, at 19:15, Noel Jones wrote: Oh, and recent postfix marks authenticated headers; note the ESTMPSA. S = StartTLS, A = Authenticated Received: from [192.168.5.108] (adsl-19-247-14.bna.bellsouth.net [68.19.247.14]) by mgate2.vbhcs.org (Postfix) with ESMTPSA id BAF4A797A6A; Thu, 5 Mar 2009 20:09:39 -0600 (CST) That is very cool, I didn't know that. Of course in my case we're not using TLS, so the header has ESMTPA, but still, quite useful. a regexp something like /^(Received: .* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 should do the trick. I really like that, there's all sorts of possibilities here. Would it be bad to strip out the IPs (usually local/private) from these headers? /^(Received: from )\[\d\d?\d?\.d\d?\d?\.d\d?\d?\.d\d?\d?\](.* myhostname \(Postfix\) with ESMTPS?A .)$/ REPLACE X-$1[internal LAN]$2 /^(Received: from [^\[].* myhostname \(Postfix\) with ESTMPS?A .*)$/ REPLACE X-$1 ?? I'm thinking that cleanup is called for all messages, which is why you would only want this on a submission port and not just on the regular cleanup service. Although the Received: from [ip.ip.ip.ip] form never shows up on external mail since bare-ip mailservers are banned anyway. -- Athene we all have our moments when we lose it Slyspy the key is though, to conceal the evidence before the police arrive
Re: Local mail listener
Daniel L. Miller: You can log the conversation between SMTP client, Postfix and the proxy filter by adding one -v option on the smtpd command line in master.cf, or by using debug_peer_list and debug_peer_level in main.cf. I tried the -v option (wow - lot of stuff goes on behind the scenes, doesn't it?!). What I still don't understand (I'm dense, I know, but You don't have to solve the mystery. Iall you need to do is to give mor experienced people a chance tpo look at the evidence. Wietse
Re: Local mail listener
Daniel L. Miller wrote: Here's the other weird thing. If, after I enter the DATA command and get that bogus 2.1.5, if I enter a second DATA command - it works. smtpd -v log excerpt - with the first DATA: Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: warning: proxy inet:192.168.0.10:225 rejected data: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: 250 2.1.5 Ok then... Mar 5 18:54:07 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:07 mailserver local/smtpd[25237]: inet:192.168.0.10:225: data Mar 5 18:54:07 mailserver assp/smtpd[25240]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:07 mailserver assp/smtpd[25240]: smtp-local.amfeslan.local[192.168.0.11]: 354 End data with CRLF.CRLF Mar 5 18:54:07 mailserver local/smtpd[25237]: inet:192.168.0.10:225: 354 End data with CRLF.CRLF Mar 5 18:54:07 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: 354 End data with CRLF.CRLF Mar 5 18:54:18 mailserver local/smtpd[25237]: inet:192.168.0.10:225: . On a whim, I tried something else. I tried telnet'ing to the two listeners - but used the EHLO command to see what was reported. I do get different responses. Does this mean anything significant? I notice that the one that works has added NOOP to the list (probably irrelevant) - but does not support pipelining. Does this affect what I'm trying to do? r...@mailserver:/opt/assp# telnet 192.168.0.11 25 Trying 192.168.0.11... Connected to 192.168.0.11. Escape character is '^]'. 220 mailserver.amfeslan.local ESMTP Postfix (Ubuntu) ehlo daniel.amfeslan.local 250-mailserver.amfeslan.local 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit 221 2.0.0 Bye Connection closed by foreign host. r...@mailserver:/opt/assp# telnet 192.168.0.10 225 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. 220 Postfix-ASSP.amfeslan.local ESMTP for ASSP ehlo daniel.amfeslan.local 250-Postfix-ASSP.amfeslan.local 250-SIZE 1024 250-VRFY 250-ETRN 250 NOOP 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN quit 221 2.0.0 Bye 421 ASSP.nospam closing transmission channel Connection closed by foreign host. -- Daniel
Re: Local mail listener
Daniel L. Miller: Here's the other weird thing. If, after I enter the DATA command and get that bogus 2.1.5, if I enter a second DATA command - it works. It does not matter. What matters is that the PROXY filter gives the wrong reply to the first DATA command. Wietse smtpd -v log excerpt - with the first DATA: Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: data Mar 5 18:54:01 mailserver local/smtpd[25237]: inet:192.168.0.10:225: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: warning: proxy inet:192.168.0.10:225 rejected data: 250 2.1.5 Ok Mar 5 18:54:01 mailserver local/smtpd[25237]: smtp-local.amfeslan.local[192.168.0.11]: 250 2.1.5 Ok
Re: Local mail listener
Daniel L. Miller: On a whim, I tried something else. I tried telnet'ing to the two listeners - but used the EHLO command to see what was reported. I do get different responses. Does this mean anything significant? I notice The only thing that matters is that the proxy replies with 2xx to the DATA command, which is not allowed by the SMTP protocol. Wietse
Re: Local mail listener
Wietse Venema wrote: Daniel L. Miller: You can log the conversation between SMTP client, Postfix and the proxy filter by adding one -v option on the smtpd command line in master.cf, or by using debug_peer_list and debug_peer_level in main.cf. I tried the -v option (wow - lot of stuff goes on behind the scenes, doesn't it?!). What I still don't understand (I'm dense, I know, but You don't have to solve the mystery. Iall you need to do is to give mor experienced people a chance tpo look at the evidence. Ouch! Ok - what evidence would you like me to provide to solve this? A complete log listing with smtpd -v? -- Daniel
Re: Local mail listener
Wietse Venema wrote: Daniel L. Miller: On a whim, I tried something else. I tried telnet'ing to the two listeners - but used the EHLO command to see what was reported. I do get different responses. Does this mean anything significant? I notice The only thing that matters is that the proxy replies with 2xx to the DATA command, which is not allowed by the SMTP protocol. But (supposedly) that reply should not be getting generated by ASSP - but is being passed on from Postfix. Or is that totally wrong - and I need to focus on a possible ASSP bug? -- Daniel
