Re: Is it possible to stop a localhost system account being used in relay attempts?
> On 23 May 2015, at 10:03, Robert Chalmers wrote: > And what is happening looks like this > > zeus:log robert$ telnet 192.168.0.15 25 > Trying 192.168.0.15... > Connected to zeus. > Escape character is '^]'. > 220 zeus.localhost ESMTP Postfix > helo inmailwetrust.com > 250 zeus.localhost > mail from: _www@zeus.localhost > 250 2.1.0 Ok > rcpt to: moff_yespas_1...@inmailwetrust.com > 250 2.1.5 Ok If you connect locally (it looks like you are) then permit_mynetworks will allow relay. Did you try connecting in from another machine? Also are you sure this the same SMTP dialogue the spam used? > Now, that last response should be > 554 : Relay access denied > How do I stop people using my server like this? > > Can anyone suggest a solution please. > > The qmg message looks like this > > May 23 07:20:21 zeus.localhost postfix/qmgr[166]: 0AC18AE7532: > from=<_www@zeus.localhost>, size=1600, nrcpt=1 (queue active) > > and one of the attempted messages looks like this. > > > May 23 00:10:24 zeus.localhost postfix/smtp[10813]: ACF7FAE8961: > to=, > relay=inmailwetrust.com[208.88.226.239]:25, delay=79990, > delays=79987/1.8/0.99/0.13, dsn=4.0.0, status=deferred (host > inmailwetrust.com[208.88.226.239] said: 451 Temporary local problem - please > try later (in reply to RCPT TO command)) This looks like a locally submitted mail. Possibly the _www user sent it? Thus permit_mynetworks would allow it. Could a service under the _www user have been manipulated into sending the email? Just a thought. Jason
Re: Two domains names under the same IP: how to handle this issue ?
Hello! > On 5 Apr 2014, at 11:32, Germain wrote: > > How may I define two reverse, one for each domain, pointing to my single IP > ? Is it legal ? Is it possible ? > > Maybe I'm totally wrong... We just set one record, or none. You just get problems with more than one as I think most of time only one is assumed, or an arbitrary limit is placed. So stuff gets rejected randomly :/ So yeh don't do it. > On 5 Apr 2014, at 11:26, "li...@rhsoft.net" wrote: > > frankly, it makes me angry if people > * don't quote what they are replying to > * don't read informations someone provides them I agree and please don't take this the wrong way. I'm not trying to hit back or anything and I feel it can be constructive for all. It would be nice if you could: * when quoting, include name/address/date of *who* is quoted to help quickly find original message and also know who is quoted * sign off a name or set a from name It might just be me and I apologise if it is but for me at least it makes the mailing list experience a whole lot better. Regards, Jason
Re: SRS bounces not working in postfix
On 4 Feb 2014, at 18.51, Michael McCallister wrote: > > Thanks again Jason. Everything works now. I stumbled across the space in > the secrets file problem last night and that got hashes validating - but > thanks for that insight too. I am running your updated release now and it is > working as expected. > > Hopefully setting up dkim and j-chkmail go smoother than srs did :-) > No problem! Can you describe the issue with the space you encountered? Or steps to reproduce? I'll throw a fix over to Fruneau before I start working more on srs-milter.
Re: SRS bounces not working in postfix
Hi Michael, This looks like one of my patches broke the TCP table when using "-I"... :-) It should be 500 not 400 it seems. Fruneau will be pleased ^^ I've pushed a fix to my own fork which I'll pull to Fruneau soon - its identical to Fruneau's except for this 400->500 fix. My fork is at: https://github.com/driskell/pfixtools However, I don't think this is your issue - since it should still work without "-I" > Thanks again Jason - I get this using your specified telnet test: > > 500 Hash invalid in SRS address. This is the reason the decoding isn't happening when you were without "-I", so you can return to NOT using "-I" (or use my fork) Check your secrets file doesn't have blank lines or spaces anywhere in it? And is purely just a couple or so lines with a set of random characters in? (max of 1024 a line) I wonder if there are problems happening with the secrets so it can encode but not decode. Maybe even try telnet to 10001 with: gett...@example.com Then with the result telnet to 10002 and decode it. Regards, Jason On 4 Feb 2014, at 00.21, Michael McCallister wrote: > > > So I have been playing around with it more now in light of this new > information - here is what I have found: > > * It works and delivers mail when the "-I" switch is NOT present (this > has been my usage in all examples). However, when I try to decode > in this mode I get "500 Hash invalid in SRS address." when testing > in telnet - which could explain why bounces are not working. Telnet > encode tests on port 10001 work fine. > * When the "-I" switch IS present, it does not deliver mail. However, > it passes both telnet encode/decode tests. Here is the delivery > problem I see in the logs: > > Feb 3 16:31:00 quimby0 postfix/smtpd[32357]: connect from > homer.terabytemedia.com[74.206.115.225] > Feb 3 16:31:00 quimby0 postfix/smtpd[32357]: warning: > tcp:127.0.0.1:10002 lookup error for "~us...@forwardingdomain.com~" > Feb 3 16:31:00 quimby0 postfix/smtpd[32357]: NOQUEUE: reject: RCPT > from homer.terabytemedia.com[74.206.115.225]: 451 4.3.0 > : Temporary lookup failure; > from= > to=<~us...@forwardingdomain.com~> proto=ESMTP > helo= > Feb 3 16:31:00 quimby0 postfix/smtpd[32357]: disconnect from > homer.terabytemedia.com[74.206.115.225] > > So I am now getting some "warning: tcp:127.0.0.1:10002 lookup error" > with the -I switch enabled - but it passes telnet encode/decode tests. > > I am confused why it is logging a decoding error with -I as opposed to > without -I in the logs above - you would think it would do that in either > case since ~us...@forwardingdomain.com~ is not SRS encoded. One thing that > might explain this - when testing on telnet with -I off, I get a "400 > external domains are ignored" error (maybe 4xx errors are warnings to Postfix > and it continues to send and moves on to encoding?) - with -I on, I get a > "500 Not an SRS address." which I assume is fatal. > > One fix might be to patch pfix-srsd (I don't program in C but could probably > figure it out) to return a 400 error for the "500 Not an SRS address.". I > cannot think of any way that opens me up to problems since I assume the > address would just not be rewritten by Postfix in this case. > > Any ideas? > > Michael > >
Re: SRS bounces not working in postfix
Hi Michael, It all looks fine config wise. But seems the bounce, although going through cleanup according to log, isn't rewriting. All I can suggest is to check there's no conflicting config elsewhere regarding canonical etc. such as master.cf overriding it etc. And maybe test the decoding by Telnet 127.0.0.1 10002 And send the following line: get Example: get SRS0==XX=test.com=t...@domain.com (Use the address you see in logs, bearing in mind it is only valid for a period of time.) It will either return reason it's not working, or confirm it is working and confirm it's something postfix side preventing the canonical rewriting from processing. Regards, Jason
Re: SRS bounces not working in postfix
Hi Michael, I did some tweaks on pfixtools I will have to have a look and check for you (I use it too.) It's not the ideal method though and a milter is really the correct way to do SRS as the canonical filters, although giving almost desired effect, aren't ideal or intended for this. I'm eventually switching to srs-milter and will be improving it. Can you provide the pfixtools options you are using, and contents if the pfix-no-srs? Also the full bounce log entry including the user it showed could prove useful. Thanks Jason > On 2 Feb 2014, at 22:57, Michael McCallister > wrote: > > Hi, > > I am having some difficulty getting SRS to work properly with postfix and was > hoping someone here might be able to shed some light on my issue. Some quick > background on the problem: > > * Almost all email on this system just gets forwarded on elsewhere (no > local deliveries). This is implemented via virtual > (virtual_alias_domains and virtual_alias_maps). > * I am using pfix-srsd to handle envelope address rewriting: > https://github.com/Fruneau/pfixtools I am not sure if this is the > recommended tool to implement SRS within postfix - I am open to > alternatives. > * SRS deliveries work fine - it sends the email just like I would > expect and passes SPF tests > * The problem I am having is with SRS bounces (i.e. a SRS delivery > results in a bounce - which must then be sent back to the original > sender). Here is an example of the problem (please note that in the > below example, srsdomain.com is in mydestination): > > User 1 (us...@originaldomain.com) emails User 2 > (us...@forwardingdomain.com) where us...@forwardingdomain.com is > configured in virtual_alias_maps and forwardingdomain.com is > configured in virtual_alias_domains. pfix-srsd is running fine on > srsdomain.com (same result with or without -I). However, > us...@forwardingdomain.com forwards to badaddr...@gmail.com which > does not exist (will result in a 550 from gmail on attempted delivery). > o When us...@originaldomain.com sends an email to > us...@forwardingdomain.com, the sender address is rewritten to > srs0=pl7i=xe=originaldomain.com=us...@srsdomain.com as expected > o postfix determines, via virtual_alias_maps, to deliver the mail > to badaddr...@gmail.com > o The delivery to gmail.com results in a 550 and postfix then > bounces to srs0=pl7i=xe=originaldomain.com=us...@srsdomain.com > instead of us...@originaldomain.com. And here lies the problem - > I assumed it would bounce to us...@originaldomain.com (after > magically being rewritten by pfix-srsd) thereby alerting that > user of the problem, but instead when it delivers the bounce to > srs0=pl7i=xe=originaldomain.com=us...@srsdomain.com, postfix > issues a "status=bounced (unknown user:" error and deletes the > bounce. > * pfix-srsd is configured as such in main.cf > recipient_canonical_maps = cdb:/etc/postfix/pfix-no-srs.cf, > tcp:127.0.0.1:10002 > recipient_canonical_classes = envelope_recipient > sender_canonical_maps = cdb:/etc/postfix/pfix-no-srs.cf, > tcp:127.0.0.1:10001 > sender_canonical_classes = envelope_sender > > It of course should be noted that I am a postfix noob - I have always used > qmail in the past for my MTA needs, but I am required to use postfix for this > - seems like a nice MTA btw :-) > > Any advice on how to get bounces working? Am I using the wrong tool? It > seems to be the most widely referenced SRS option for postfix and has active > development so I went with it. I am running postfix 2.11 from source with > cdb db support added. Am I better off running an older version? > > Any help/advice is greatly appreciated. My apologies if I missed something > obvious - I tried multiple different options before asking the list. I of > course tried asking the pfixtools community about this first - but I think it > is really just one guy and have not heard anything back. > > Michael > >
recipient_canonical_maps bypassing local recipient existence checks
Hello! Happy new year everyone. Postfix version 2.10.2. I have a canonical maps configuration: recipient_canonical_maps = hash:/etc/postfix/rcptcanon Which contains one entry: @firstdomain.com @seconddomain.com The firstdomain.com and seconddomain.com are both virtual mailbox domains. The seconddomain.com has a single user, "test". If I send an email to he...@seconddomain.com, I get the following which is exactly as one would expect with the default recipient checking: 220 server ESMTP Postfix EHLO testing 250-server ... MAIL FROM: f...@thirddomain.com 250 2.1.0 Ok RCPT TO: he...@seconddomain.com 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table QUIT 221 2.0.0 Bye However, if I send an email to he...@firstdomain.com, it sends successfully. A few minutes later I will then receive a bounce from the server: 220 server ESMTP Postfix EHLO testing 250-server ... MAIL FROM: f...@thirddomain.com 250 2.1.0 Ok RCPT TO: he...@firstdomain.com 250 2.1.5 Ok QUIT 221 2.0.0 Bye It seems that if an entry is found in recipient_canonical_maps, postfix assumes the target address to exist. Is this intended behaviour? Also, a secondary question I have regarding recipient_canonical_maps - is it possible to specify this under "-o" for smtpd, so it only performs the canonical on the way out/in? I can't see a way to do this. Thanks, Jason
TCP Table and Unix Sockets
Hi, I'm wanting to get some unix socket support on my mail server for the same protocol used by the TCP table. I can see patches for this were submitted before but had some issues with usability and namespace: http://comments.gmane.org/gmane.mail.postfix.user/222895 Has any thought been put into this? I'm guessing there may not be much demand for it so may be not but I want to check. I'm just thinking if, namespace wise, it could use "socket". Then it could be: socket:inet:host:port socket:unix:pathname socket:host:port The last format could be allowed (and quite easily detected) so use of dict_tcp_open can simply be replaced with dict_socket_open, reducing code (tcp:host:port => socket:host:port). If absolute pathnames (start with /) are enforced, there would never be a conflict with this. Of course if relative pathnames are allowed there would be a possible conflict if somebody had a hostname of "unix" but I believe enforcing absolute pathnames would be safer and rule this out. This would be 100% in line with "socketmap" and "lmtp" I believe. So usability it would be very familiar, and if "socket" is not the best keyword, we could use something else. I can also see in socketmap there is use of auto_cln.h which maintains connections, reuses them, and re-establishes them, and already supports both tcp and unix sockets. Without having looked into them too deeply it looks like these could be utilised for the tcp table and unix socket table too? It looks like it could be possible to just clone the dict_socketmap_open and just replace the protocol areas. This would potentially mean we're not changing the amount of code since we'd be removing dict_tcp.[ch] and adding a potentially same size dict_socket.[ch] I am really keen on helping to implement this and feedback on the above thoughts and ideas would be greatly appreciated. It would definitely offer a more secure way to do simple lookups such as the current tcp implementation provides. Thanks! Jason
Re: TCP Table and Unix Sockets
> Why not use socketmaps? These already support "inet" and "unix" > domain sockets, and they use (length, value) netstrings which require > no encoding of special characters. There are netstring implementations > for many languages, so availability should not be a problem. Thanks. I'll definitely explore that approach... I hadn't realised the protocol for socketmap was so simple! > tcp_table(5) is not really something that I am proud of. I can appreciate your thoughts on TCP now I've looked more closely at the netstrings. Much better method, and even if there isn't an implementation it's so simple you could write it in 15 minutes haha. > The following is from Postfix internal documentation. Unfortunately I did > not find time to make this available as a socketmap_table(5) manpage. No problem! That's where the mailing list helps I guess ^^ Thanks! Jason
