gmane.mail.exim.user

Re: Help with simple .forward filter: accept only campus mail

David Mathog — 2008-10-07T19:47:58

I seem to be missing some key point. With this ~drm/.forward file: # Exim filter if error_message then seen finish endif # if $reply_address matches .*campus\.edu\$ then unseen deliver mathog< at >campus.edu seen finish else unseen finish endif Here is the command line test: % /usr/exim/bin/exim -bf .forward -f mathog< at >caltech.edu < test_message Warning: no message headers read Return-path copied from sender Sender = mathog< at >campus.edu Recipient = drm< at >campus.edu Testing Exim filter file ".forward" Unseen deliver message to: mathog< at >campus.edu Seen finish Filtering set up at least one significant delivery or other action. No other deliveries will occur. However, when I actually send mail from mathog< at >campus.edu to drm< at >campus.edu no forwarding back to the designated address occurs. A copy is saved in /var/mail/drm though, so at least that part of the delivery works. Watching this with eximon shows no attempt by exim to forward mail to the designated target. When the command line test is changed to

Help with simple .forward filter: accept only campus mail

David Mathog — 2008-10-07T17:41:02

For a class I set up a common email so that the students could communicate with the TAs. When mail is sent to it, it delivers that message to the common account and my account, and also forwards that message to the TAs. The current .forward is just: \common_account, \my_account, ta1< at >campus.edu, ta2< at >campus.edu Somehow or other that email address made it onto a spam list. The common account only needs to receive mail from campus addresses. So I want to put something like the following in the .forward instead, but this is pseudocode because I do not know the correct syntax: # exim filter if $reply_to = "campus.edu$" then #reply_to ENDS in "campus.edu" deliver common_account #delivery to addressee on this machine deliver my_account #delivery to 2nd account on this machine deliver ta1< at >campus.edu #forward to one TA deliver ta2< at >campus.edu #forward to another TA fi finish What is the actual syntax for this? Thanks, David Mathog mathog< at >caltech.edu Manager, Sequence Analysis Facility, Bi

Re: Per-recipient post-DATA acknowledgements

W B Hacker — 2008-10-07T17:05:37

*That's* not a problem. Few spambots are either authenticated or in possession of PTR records and HELO's that match a DNS record. They are mostly gone - or at least 'tagged' before acl_smtp_data. M$ UA clients come in on a different port (587) and protocol (TLS/SSL) in order to AUTH, so not expected to have those. Different acl's process 'em. M$ alleged-MTA (Exchange) as clients can follow the rules, same as everyone else, OR be whitelisted.. or go pound sand.. Workable per-user prefs for those things - all of which precede DATA, are a road well-travelled. Can't boil the ocean with a post-data-phase tool. But we could improve the coffee, particularly w/r eliminating post-smtp DSN's.. Mind - IF/AS/WHEN we get the 'tools' - my plan is to stop deferring second and subsequent delivery for those arrivals who can agree to a post-data handshake. ELSE NOT. May be BFBI, but one-at-a-time is all we have at present, and it works, and works well. Either way, a post-data-phase DSN goes only to our own u

Re: Per-recipient post-DATA acknowledgements

Ian Eiloart — 2008-10-07T16:42:04

--On 8 October 2008 00:06:24 +0800 W B Hacker conducive.org> wrote: The problem is that some M$ clients time out earlier than some spambots.

Re: Per-recipient post-DATA acknowledgements

W B Hacker — 2008-10-07T16:06:24

Not sure that cannot be done 'easily enough' anyway... and w/o overly relying on timeouts. The biggest advantage is that the Exim community has to do only half the work - eg meet the same documented spec that courier already supports. Finding a few courier-mta users who will test should be easy enough. They'd like to get more use out of their feature as well. Now - XPRDR would at first glance have the same advantage, and source code is there for both of 'em. But I just don't see that XPDR's 'parent' MTA has anything close to the coverage or pool of admins of courier-mta which is in ports and packages everywhere, and in very long-term production use, regardless of 'market share'. Once there are two players interoperable, the third one is easier to enlist. Final and most enduring solution? There ain't no such animal. > XLMTP has the advantage that LMTP is ACK. - but no fewer than TWO MTA have to have an implementation created, of the parts to be used in smtp. We can't just adopt lmtp directl

Re: Per-recipient post-DATA acknowledgements

Ian Eiloart — 2008-10-07T15:34:29

--On 7 October 2008 19:49:44 +0800 W B Hacker conducive.org> wrote: NOPE. There are three suggestions so far: XEXDATA, XLMTP, and XPRDR I favour XPRDR technically (strict timeouts enable tarpitting without losing compliant hosts, for example), but XEXDATA has the advantage of having an existing implementation. XLMTP has the advantage that LMTP is in widespread use, so there's lots of code out there. I agree with you that we should favour XEXDATA because it's already out there, even though I think it is inelegant. However, I'd also advocate supporting both EXDATA and XPRDR, because that might give us code that's flexible enough to be adapted to any similar scheme.

Re: how do I block mail to local domains except SMTP auth or trusted source?

Dave Lugo — 2008-10-07T15:33:37

This is overly simplistic, but I can't do more because I don't know what your config looks like, and I've customized my config so much that I can't cut-n-paste and hope that it will drop correctly into yours. Add this hostlist near the top: hostlist my_mx_provider = 1.2.3.4 : 1.2.3.5 Add something like this in the rcpt acl: accept hosts = +my_mx_provider domains = +local_domains : +relay_to_domains AFTER the ACL stanza that allows inbound from auth'd clients, do a default deny at the end of that acl. (I think the default at the end of the rcpt acl is, in the stock config file, accept. You need to change) The exim config file, on a stock install, is very well commented, and the spec.txt file has a lot of examples. Have you been reading them at all?

send to smarthost with a unified MAIL FROM address

Gergely Polonkai — 2008-10-07T15:21:09

Hello list, I'm a bit stuck and tired with this problem. Maybe I was choosing the wrong path... My problem is that our smarthost accepts mails from us only from a given IP address (on which my exim instance runs), and with only a specific address in the MAIL FROM: command. I was trying with rewrite rules: *< at >* bocmok< at >clients.wx with this, I succeeded, as mails went out from my box, but local mailing failed, as exim sent thos mails to the smarthost for somewhat reason. So sending a mail with "mail polesz< at >w00d5t0ck.info" sent to the smarthost, so as "mail polesz", which should arrive in the local user "polesz"'s mailbox. Can you suggest me a new solution, or a correct rewrite line for this problem please? Thanks in advance, Gergely Polonkai

Re: how do I block mail to local domains except SMTP auth ortrusted source?

Exim List — 2008-10-07T14:58:14

My experience is that some spammers look for mail.* and simply try to connect directly to that. When you are dealing with a brand new startup, you can plan around that. When you are dealing with legacy domains and legacy customer bases, especially in acquisitions, you can't force a bunch of changes, at least all at once.

Re: how do I block mail to local domains except SMTP auth ortrusted source?

Exim List — 2008-10-07T14:50:41

We migrated these domains to our server from an acquisition. I'm presuming that many spammers look for mail.domain.com as a valid hostname anyway -- even without previous history of sending to that address. In this case, the mail.domain.com was the MX for many of these domains so they already have the history of sending to mail.domain.com. So, us changing the MX record to a separate filtering appliance doesn't force a spammer to use that appliance. They simply continue to send to mail.domain.com instead. We want to prevent that by disallowing SMTP traffic except from the trusted spam filter source and from any SMTP AUTH clients in the field. A firewall can (a) stop all mail or (b) allow trusted hosts or (c) allow all mail. A firewall, to my knowledge, doesn't have the capacity to understand SMTP AUTH. If I'm wrong, enlighten me. I need a solution which will stop all mail to the host mail.domain.com EXCEPT for (a) the trusted spam filter host and (b) anyone who authenticates against the d

Re: Per-recipient post-DATA acknowledgements

W B Hacker — 2008-10-07T11:49:44

Fat chance of that. The latest smtp RFC timeout specs are not even real-world relevant, let alone seen in common use. Add up the mandated times. quarter-speed telex was faster than that. I don't see the connection there. Pipelining potentially saves time, but it *adds* failure modes. Only if you assume pipelining will be permitted (not on our boxes) and timing will fit yet-another particular set of parameters. Am I the Lone Ranger in wanting to tilt toward an implementation ten years in use vs one not yet even dry? If so, WHY so? Bill

Re: how do I block mail to local domains except SMTP auth ortrusted source?

Marc Haber — 2008-10-07T10:52:53

On Tue, 7 Oct 2008 10:41:45 +0300, "Mike Barnard" gmail.com> wrote: Most probably, the spam filter appliances are new and the MX records used to point to the actual SMTP servers. Some Spamware comes with a list of IP addresses to deliver to and doesn't care about MX records to speed up delivery, so their data base might be outdated, which is an advantage for the Spammer in the OP's case. Greetings Marc

Re: Per-recipient post-DATA acknowledgements

Ian Eiloart — 2008-10-07T09:55:48

--On 6 October 2008 20:19:08 -0700 Claus Assmann esmtp.org> wrote: This one? It differs like this: With PRDR, the server can give a single response if all the responses would be the same. There's a slight efficiency there. When giving a full response, the format is like LMTP except that it starts with a "353" response, eg "353 content analysis has started". So, this is more like LMTP, but is a bit more efficient. Furthermore, PRDR requires strict adherence to timeout specifications, and requires use of pipelining, in order to reduce the chances of losing responses. That all seems like an improvement on both XEXDATA and XLMTP, and therefore worthwhile.

Re: Per-recipient post-DATA acknowledgements

Ian Eiloart — 2008-10-07T09:55:43

--On 6 October 2008 15:40:41 -0700 Phil Pennock spodhuis.org> wrote: Excellent! Seriously consider supporting XEXDATA, since that gives us interoperability with Courier. And, consider supporting PRDR, since it looks like an improvement on LMTP. The reply to DATA is a single multiline 558 code response. Stripping the first four characters of each line in the response yields a set of LMTP style responses, each of these may be multiline.

Re: Per-recipient post-DATA acknowledgements

W B Hacker — 2008-10-07T09:18:23

I'm not against adding three or four and seeing what works best in practice. But that needs working between at least two disparate MTA *each* of which should have some visible, sizeable, active, and expert user community that uses that MTA 'in anger' eg for revenue or 'job risk'. *OW - seriously give a damn about stuff working as it should. Call it market share if that suits. Exim has it, courier-mta has it, postfix has it, and for sure sendmail has it. And MS Exchange? But let's not go there just yet.. ;-) I'm not criticizing MeTAl, but it doesn't look to have yet even had *time* to gather that sort of acceptance. Bill

Re: Per-recipient post-DATA acknowledgements

W B Hacker — 2008-10-07T09:11:03

Sorry - been fighting heat and hardware problems on this server ... Point w/r MeTA1 - there you go. TWO implementations each of which work only to themselves. Perhaps MeTAl has a more elegant approach. Or not. But does it stay within the allowance for experimental extensions as well as Courier? Plus - it is still early days for the MeTAl project, whereas courier-mta has been around for donkey's years.

Re: how do I block mail to local domains except SMTP auth ortrusted source?

Mike Barnard — 2008-10-07T07:41:45

you lost me there.... if the the MX records are the spam filter appliances... how did they get the IP addresses of the actual smtp servers... and why would a firewall stop that from happening? unless i dont quite get what you are saying, a firewall should work, depending of course on how you set it up I would assume that the smtp servers receive/send email from the spam filtering machines! If this is the case, then allow only the spam filtering devices to send emails to your smtp servers Further, i dont quite get 'relay mails through their respective domains' Then you are not configuring your firewall well...open the respective ports required for mail. But this wont solve your problem. You may need to look at your design again. It sounds more like a design flaw than a configuration problem. When you get the design figured out and one that works well for what you want to do, the configuration falls into place pretty fast. Regards,

Re: Possibly OT

Frank Elsner — 2008-10-06T14:15:03

You should add the user "apache" to the list of trusted_users. For details on "trusted_users = " refer to the documentation. --Frank Elsner

Re: how do I block mail to local domains except SMTP auth ortrusted source?

Marc Haber — 2008-10-07T06:20:21

On Mon, 06 Oct 2008 23:46:29 -0400, Exim List wingnet.net> wrote: It is generally a bad idea to run outgoing and incoming mail on the same host names for exactly this reason: It prevents you to take different routing/filtering approaches on the IP level, and - in times of higher load - prevents you from separating these functions to different machines. Define "relay mail through domains". This is probably a rather sophisticated application of ACLs which surely can be done. If I were you, I'd take a closer look at the documentation's chapters about string expansion, lookups and ACLs, and if that's too complicated to tackle in the given time frame, hire an experienced consultant. Greetings Marc

how do I block mail to local domains except SMTP auth or trusted source?

Exim List — 2008-10-07T03:46:29

New to exim and have not found this in the FAQs or online resources so far. We have a machine with several domains. The MX record for these domains is pointed to a spam filter appliance. Alas, spammers don't play fair. They choose to connect directly to the IP address(es) of the domains on the box and still send their spam that way. While a firewall solution might seem the logical choice, it isn't here. The reason is that the users in each domain need to be able to see mail.abc.com or mail.xyz.com as their outgoing SMTP server which they relay through via SMTP auth. So, I need to know how to disable the ability to receive mail for local domains EXCEPT from a trusted source (the spam appliance box). Further, I need to allow SMTP AUTH clients to relay mail through their respective domains. A firewall simply shuts off all SMTP traffic including SMTP auth unless I know all the "trusted sources" which is basically moot given roaming customers. How can this be done? Also, it would be preferab

Re: Per-recipient post-DATA acknowledgements

Phil Pennock — 2008-10-07T03:44:09

Reading the PRDR draft, it's almost identical in the protocol changes to EXDATA, which is an older draft and implemented in Courier, we're told. The real difference is that PRDR uses unwrapped response codes, so that you get multiple top-level responses, in the style of LMTP, but without claiming to be other than SMTP, which means that it's breaking the protocol. Mind, that doesn't matter much since it has to be requested. Since Tony is listed in the Acknowledgements for the PRDR draft, I'd be interested in knowing his opinion. -Phil