Re: [courier-users] missing MX record

[Matus UHLAR - fantomas]

On 10.06.17 14:53, SZÉPE Viktor wrote:

RFC 5321 states in https://tools.ietf.org/html/rfc5321#section-5


The lookup first attempts to locate an MX record associated with the name.
... If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host.


Were you a ware of that?
I think it is very unusual and dangerous.

Do modern MTA-s - including Courier - implement that?



Idézem/Quoting Matus UHLAR - fantomas :

This behaviour was described in rfc 821 and 2821.
AFAIK all MTAs implement this behaviour since MX records were implemented.

What and why exactly sounds unusual and dangerous to you?


On 10.06.17 16:42, SZÉPE Viktor wrote:

I think it gives us no means to stop emails for a domain.
I thought removing the MX record and not listening on port 25 is enough.

This way anyone my send an email to a mailserver-less sub/domain.


This mechanism was created when MX records were introduced, to support
host/domains without them.

This is how things should be done - creating new standard and define how
backwards compatibility should be implemented.

Read rfc 7505 that tries to implement mechanism to archieve that as a new
measurement, and don't blame us for implementign something that has existed
even before MX and was never dropped since.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool. 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] missing MX record

[SZÉPE Viktor]

Idézem/Quoting Matus UHLAR - fantomas :


On 10.06.17 14:53, SZÉPE Viktor wrote:

RFC 5321 states in
https://tools.ietf.org/html/rfc5321#section-5


The lookup first attempts to locate an MX record associated with the name.
... If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host.


Were you a ware of that?
I think it is very unusual and dangerous.

Do modern MTA-s - including Courier - implement that?


This behaviour was described in rfc 821 and 2821.
AFAIK all MTAs implement this behaviour since MX records were implemented.

What and why exactly sounds unusual and dangerous to you?


I think it gives us no means to stop emails for a domain.
I thought removing the MX record and not listening on port 25 is enough.

This way anyone my send an email to a mailserver-less sub/domain.


SZÉPE Viktor
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
--
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] missing MX record

[Matus UHLAR - fantomas]

On 10.06.17 14:53, SZÉPE Viktor wrote:

RFC 5321 states in
https://tools.ietf.org/html/rfc5321#section-5


The lookup first attempts to locate an MX record associated with the name.
... If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host.


Were you a ware of that?
I think it is very unusual and dangerous.

Do modern MTA-s - including Courier - implement that?


This behaviour was described in rfc 821 and 2821.
AFAIK all MTAs implement this behaviour since MX records were implemented.

What and why exactly sounds unusual and dangerous to you?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains? 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Bowie Bailey]

On 8/9/2011 9:28 PM, Ben Kennedy wrote:
 Bowie Bailey wrote at 9:47 AM (-0400) on 6/10/11:
 My solution to this problem is to take the secondary server offline.  If
 the primary server goes down, the sending servers will queue the mail
 for you for a reasonable amount of time (generally at least 24 hours,
 although I think 3-5 days is most common).  This should give you plenty
 of time to repair the primary server or activate the secondary as a
 temporary replacement.  Since mail is not being delivered while the
 primary server is down in either case, does it really matter whose queue
 the mail sits in?
 That's a good point.  On reflection, this is probably the most sensible 
 solution.  You've unearthed the nut of it in the final sentence above.  
 Frankly, aside from expediting the delivery of mail following a failure of 
 the primary, I can't think of a good reason why I've been adamant about 
 accepting mail on two machines.

 You can leave the secondary MX record in place even if the server is
 offline.  This will not have any negative side effects and may even help
 to reduce spam since spammers frequently try the lower-priority server
 first.
 In that case, I think what I may do is leave my configuration as it is, but 
 simply shut down courier on the secondary machine.  In a pinch I can simply 
 start up courier again to begin queueing mail, or switch the secondary over 
 to primary mode.

 This solution is so simple and obvious, I'm a bit flummoxed why it has taken 
 me so long (several years) to come to this conclusion.  Obviously, at various 
 points in time, I've seen merit in having more than one machine online and 
 capable of receiving mail, but I seem to have now forgotten what I thought 
 they were.

Just be careful with the second server.  If there is something
responding to port 25, it may cause problems.  Make sure that a
connection to that port simply fails and is not rejected in some manner.

However, on second thought, since this is a secondary MX record, it
should not be a major issue.  Legitimate servers should try the primary
first, so as long as the primary is running, the second server should
see very few non-spam connection attempts.

-- 
Bowie

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Sam Varshavchik]

Ben Kennedy writes:


u...@example.com: u...@mailhost.example.com

That's an interesting and clever approach.  Would this properly pass through  
ad hoc local-part extensions, e.g. for mail addressed to user- 
someth...@example.com - user-someth...@mailhost.example.com?


No, it wouldn't.




pgpCNdUQKpurU.pgp
Description: PGP signature
--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Ben Kennedy]

Sam Varshavchik wrote at 7:07 AM (-0400) on 8/10/11:

 That's an interesting and clever approach.  Would this properly pass
through  
 ad hoc local-part extensions, e.g. for mail addressed to user- 
 someth...@example.com - user-someth...@mailhost.example.com?

No, it wouldn't.

Well, that rules out that approach, then.

thanks,

-ben

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca



--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Sam Varshavchik]

Ben Kennedy writes:


Sam Varshavchik wrote at 7:07 AM (-0400) on 8/10/11:

 That's an interesting and clever approach.  Would this properly pass
through
 ad hoc local-part extensions, e.g. for mail addressed to user-
 someth...@example.com - user-someth...@mailhost.example.com?

No, it wouldn't.

Well, that rules out that approach, then.

thanks,


Well, it depends on how much work you want to do.

If there's only a handful of email addresses in that domain, you can set it  
up as a virtual domain, which simply maps it to a local mailbox, and you set  
up forwarding addresses via .courier files. With a careful arrangement  
of .courier-x-default files, and with careful usage of environment variable,  
you should be able to craft fairly sophisticated forwarding rules.




pgpjsFoEJhZ1J.pgp
Description: PGP signature
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. 
http://p.sf.net/sfu/wandisco-dev2dev___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Ben Kennedy]

Hey all,

I'm folloiwng up on this thread I started about two months ago.  I haven't had 
time to revisit it or implement any of your suggestions until now.  So this is 
a delayed response, but thank you for the ideas, Bowe and Sam!

Sam Varshavchik wrote at 10:05 PM (-0400) on 6/9/11:

One thing you can do is redefine a local domain. If you are example.com,  
rather than defining example.com as a local domain, define instead  
mailhost.example.com as a hosted domain, and install an alias

u...@example.com: u...@mailhost.example.com

That's an interesting and clever approach.  Would this properly pass through ad 
hoc local-part extensions, e.g. for mail addressed to 
user-someth...@example.com - user-someth...@mailhost.example.com?

Bowie Bailey wrote at 9:47 AM (-0400) on 6/10/11:

My solution to this problem is to take the secondary server offline.  If
the primary server goes down, the sending servers will queue the mail
for you for a reasonable amount of time (generally at least 24 hours,
although I think 3-5 days is most common).  This should give you plenty
of time to repair the primary server or activate the secondary as a
temporary replacement.  Since mail is not being delivered while the
primary server is down in either case, does it really matter whose queue
the mail sits in?

That's a good point.  On reflection, this is probably the most sensible 
solution.  You've unearthed the nut of it in the final sentence above.  
Frankly, aside from expediting the delivery of mail following a failure of the 
primary, I can't think of a good reason why I've been adamant about accepting 
mail on two machines.

You can leave the secondary MX record in place even if the server is
offline.  This will not have any negative side effects and may even help
to reduce spam since spammers frequently try the lower-priority server
first.

In that case, I think what I may do is leave my configuration as it is, but 
simply shut down courier on the secondary machine.  In a pinch I can simply 
start up courier again to begin queueing mail, or switch the secondary over to 
primary mode.

This solution is so simple and obvious, I'm a bit flummoxed why it has taken me 
so long (several years) to come to this conclusion.  Obviously, at various 
points in time, I've seen merit in having more than one machine online and 
capable of receiving mail, but I seem to have now forgotten what I thought they 
were.

cheers,

-ben

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca



--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Michelle Konzack]

Hello Sam,

your suggestion is genearaly working but if you have two mails like

linux4miche...@tamay-dogan.net
linux4miche...@tdexample.net

then you run into problems wbch can be solved IF the whole lenght of the

LOCALPART@DOMAIN

does not exceed 32 characters.  :-D

If you have already an account linux4michelle on the Server like

/home/linux4michelle/

which does the Backup-MX for the first server, create an account of

/home/linux4miche...@tdexample.net/

and it just works!  Please remeber, that this does  ONLY  work,  if  the
name is maximum 32 characters long.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet Franceitsystems@tdnet
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice) Gewerbe Straße 3
50, rue de Soultz 77694 Kehl/Germany
67100 Strasbourg/France   Tel: +49-177-9351947  mobil
Tel: +33-6-61925193 mobil Tel: +49-176-86004575 office

http://www.itsystems.tamay-dogan.net/  http://www.flexray4linux.org/
http://www.debian.tamay-dogan.net/ http://www.can4linux.org/

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Bowie Bailey]

On 6/9/2011 8:45 PM, Ben Kennedy wrote:
 Hey folks,

 Some of you may recall this discussion from last fall.  I've got a
 problem, one that I guess my servers have exhibited for years, and I
 want to fix it.

 I have two machines, which I'll call primary and secondary.  They
 are both MX for a number of domains; primary has a lower priority number
 (i.e. is a first choice for delivery), and holds the canonical backing
 store (maildirs, POP3/IMAP service, etc).  Secondary is designed to also
 accept mail for these domains, and shunt any it happens to receive (by
 virtue of esmtproutes) to primary.  Both have mailbox configuration
 provided by authmysql from a local replicated MySQL database.

 In case primary goes down, secondary will continue to queue mail and, at
 my option, may be quickly switched into primary behvaiour (to deliver
 locally and provide POP3/IMAP service) in the event that the original
 primary cannot be brought online in a timely fashion.

 I have used this pattern for several years now, with general success.

 The gaping hole, of course, is that the secondary will accept any mail
 for any mailbox on any of the domains.  For domains with alias@...
 style catch-alls, this is fine.  For the rest, it induces the primary
 into spewing out backscatter for any undliverable addresses.

 As I said, both machines share the mailbox config, and therefore have
 the capability of knowing what is a legitimate address and what isn't. 
 But on the secondary, which has empty hosteddomains and esmtproutes
 pointing to the primary, it never bothers to do an account lookup (it
 only looks at the domain).

 How do I fix this?

My solution to this problem is to take the secondary server offline.  If
the primary server goes down, the sending servers will queue the mail
for you for a reasonable amount of time (generally at least 24 hours,
although I think 3-5 days is most common).  This should give you plenty
of time to repair the primary server or activate the secondary as a
temporary replacement.  Since mail is not being delivered while the
primary server is down in either case, does it really matter whose queue
the mail sits in?  The only downside is that it will take longer for all
of the queued mail to be delivered once the primary is back online, but
I consider that to be an acceptable trade-off for not having to worry
about synchronizing account lists or sending backscatter.  After all,
how frequently does your mail server crash?

You can leave the secondary MX record in place even if the server is
offline.  This will not have any negative side effects and may even help
to reduce spam since spammers frequently try the lower-priority server
first.

If you truly need to avoid any downtime, you might want to consider
having two primary servers with shared storage for the mailboxes.

-- 
Bowie

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Ben Kennedy]

Hey folks,

Some of you may recall this discussion from last fall.  I've got a
problem, one that I guess my servers have exhibited for years, and I
want to fix it.

I have two machines, which I'll call primary and secondary.  They
are both MX for a number of domains; primary has a lower priority number
(i.e. is a first choice for delivery), and holds the canonical backing
store (maildirs, POP3/IMAP service, etc).  Secondary is designed to also
accept mail for these domains, and shunt any it happens to receive (by
virtue of esmtproutes) to primary.  Both have mailbox configuration
provided by authmysql from a local replicated MySQL database.

In case primary goes down, secondary will continue to queue mail and, at
my option, may be quickly switched into primary behvaiour (to deliver
locally and provide POP3/IMAP service) in the event that the original
primary cannot be brought online in a timely fashion.

I have used this pattern for several years now, with general success.

The gaping hole, of course, is that the secondary will accept any mail
for any mailbox on any of the domains.  For domains with alias@...
style catch-alls, this is fine.  For the rest, it induces the primary
into spewing out backscatter for any undliverable addresses.

As I said, both machines share the mailbox config, and therefore have
the capability of knowing what is a legitimate address and what isn't. 
But on the secondary, which has empty hosteddomains and esmtproutes
pointing to the primary, it never bothers to do an account lookup (it
only looks at the domain).

How do I fix this?

thanks,

-ben


Malcolm Weir wrote at 11:53 AM (-0700) on 9/24/10:

-Original Message-
From: Alessandro Vesely [mailto:ves...@tana.it] 
Sent: Friday, September 24, 2010 2:40 AM

 In my experience, enterprises of size actually operate dedicated boundary
 servers as their MX platforms, and final delivery is handled by an
entirely
 different set of servers often totally invisible to the outside user.

While that's correct, those invisible servers are not _primary_ MXes 
on the public Internet.  So, it is still unanswered why large 
enterprises may want to operate _secondary_ MXes, i.e. MXes with a 
higher preference number.

Ummm... the invisible servers are not actually any kind of MX on the
public
Internet, primary or otherwise.

There is a certain amount of confusion in this area because a lot of the
mindset
is structured around the notion that the primary MX is final recipient
(the
MDA), and other MX nodes end up relaying traffic to that primary.

But if you use a purpose designed boundary server whose sole job is
scanning
and filtering, then forwarding the scanned mail to distinct delivery nodes,
you
may well choose to implement multiple such systems attached to different
network
providers and/or points-of-presence.  In this model, the MX is just another
MTA,
quite distinct from the MDA and MSA.

For example: suppose you have campuses in Los Angeles and New York. Each
campus
has its own connection to the Internet, but also a private network between
the
two. Even if you want the bulk of outside traffic, and all mail, to go to
LA, it
may make sense to have an MX based in NY with a lower priority that routes
its
traffic to LA over the private network. That way a service outage on the LA
campus would not bring down all external mail acceptance.

I don't think we're in disagreement with anything, here, other than perhaps
the
issue created by the fact that MX server has been conflated with delivery
server, a fact that should surprise no-one who's seen the separation, over
time,
of the MTA, MDA and MSA parts of the system.

Malc.





--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-- 
Ben Kennedy (chief magician)
zygoat creative technical services
http://www.zygoat.ca



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Sam Varshavchik]

Ben Kennedy writes:


Hey folks,

Some of you may recall this discussion from last fall.  I've got a
problem, one that I guess my servers have exhibited for years, and I
want to fix it.

I have two machines, which I'll call primary and secondary.  They
are both MX for a number of domains; primary has a lower priority number
(i.e. is a first choice for delivery), and holds the canonical backing
store (maildirs, POP3/IMAP service, etc).  Secondary is designed to also
accept mail for these domains, and shunt any it happens to receive (by
virtue of esmtproutes) to primary.  Both have mailbox configuration
provided by authmysql from a local replicated MySQL database.

In case primary goes down, secondary will continue to queue mail and, at
my option, may be quickly switched into primary behvaiour (to deliver
locally and provide POP3/IMAP service) in the event that the original
primary cannot be brought online in a timely fashion.

I have used this pattern for several years now, with general success.

The gaping hole, of course, is that the secondary will accept any mail
for any mailbox on any of the domains.  For domains with alias@...
style catch-alls, this is fine.  For the rest, it induces the primary
into spewing out backscatter for any undliverable addresses.

As I said, both machines share the mailbox config, and therefore have
the capability of knowing what is a legitimate address and what isn't.
But on the secondary, which has empty hosteddomains and esmtproutes
pointing to the primary, it never bothers to do an account lookup (it
only looks at the domain).

How do I fix this?


Only a machine which has a domain configured as a local/hosted domain can  
know which address in the domain exists, or not.


One thing you can do is redefine a local domain. If you are example.com,  
rather than defining example.com as a local domain, define instead  
mailhost.example.com as a hosted domain, and install an alias


u...@example.com: u...@mailhost.example.com

Mail addressed to u...@example.com gets rewritten to be addressed to  
u...@mailhost.example.com, which would be a valid local mailbox. Nonexistent  
addres...@example.com get rejected because example.com is not a local  
domain. Adresses that exist get rewritten and delivered.


It should be a simple matter to write a script to dump your list of  
mailboxes, generate an alias entry for each valid mailbox, then run  
makealiases.


I believe that if you do that, you can install the same alias table on your  
secondary, and on the secondary put mailhost.example.com into  
esmtpacceptmailfor, so that mail for that domain gets accepted and queued.


If you've got mail queued up on the secondary, and want to make it a  
primary, you will need to stop courier, remove mailhost.example.com from  
esmtpacceptmailfor, and put it into hosteddomain, and start courier, and it  
should then deliver the queued up mail into local mailboxes.


You'll need to do some experimenting to verify this, but I'm fairly certain  
that it'll work.




pgpdoOa65UWPs.pgp
Description: PGP signature
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] DNS MX lookup failed.?

[Sam Varshavchik]

Mark Constable writes:


On 16/02/11, Sam Varshavchik wrote:
  Received-SPF: error (DNS MX lookup failed.?)
SPF=FROM;
sender=po...@pobox.com;
remoteip=:::64.74.157.115;
remotehost=;
helo=support.icgroup.com;
receiver=mail.spiderweb.com.au;
 
  The above is courier 0.60.0 with this bofh...
 
  opt BOFHBADMIME=accept
  opt BOFHSPFHELO=pass,none,neutral,softfail,unknown,error
  opt BOFHSPFMAILFROM=pass,none,neutral,softfail,unknown,error
  opt BOFHSPFFROM=pass,none,neutral,softfail,unknown,error,mailfromok
  opt BOFHSPFTRUSTME=1
  opt BOFHSUPPRESSBACKSCATTER=smtp,authsmtp

 I just sifted through the code. I believe that when a DNS lookup fails,
 the resulting status is error, and not softfail, so you really need
 the following patch.

 I think I can put together a test scenario in the next day or two --
 set up a fake subdomain on one of my domain with an NS record pointing
 to a bogus IP address. That should reliably result in a DNS lookup error
 resolving the given domain.

 Stay tuned…

 diff -U3 -r1.74 submit.C
 --- courier/submit.C12 Oct 2010 00:27:55 -  1.74
 +++ courier/submit.C16 Feb 2011 02:56:53 -
 @@ -887,7 +887,8 @@
 return 1;
 }
 frominfo.receivedspfmailfrom=receivedspfmailfrom;
 -   if (strcmp(result, pass) == 0)
 +   if (strcmp(result, pass) == 0 ||
 +   strcmp(result, error) == 0)
 frominfo.mailfrom_passed_spf=1;
 }

Sorry to bother you Sam but this problem is impacting even more
clients than I thought and I'm stuck on older Debian systems which
I can't upgrade until I physically get near the server. IOW I can't
really test this myself.

Any progress or workarounds until an official solution?


The above code is the code that's currently in, and will be in the next  
release.




pgpqIxkaGSw9P.pgp
Description: PGP signature
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] DNS MX lookup failed.?

[Mark Constable]

On 15/03/11, Sam Varshavchik wrote:
  Any progress or workarounds until an official solution?
 
 The above code is the code that's currently in, and will be in
 the next release.

Ah great, so I could patch 0.65.3 and be good or wait for 0.65.4.

Dare I ask how long, rough estimate, before 0.65.4 will be released?

--markc

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] DNS MX lookup failed.?

[Sam Varshavchik]

Mark Constable writes:


On 15/03/11, Sam Varshavchik wrote:
  Any progress or workarounds until an official solution?

 The above code is the code that's currently in, and will be in
 the next release.

Ah great, so I could patch 0.65.3 and be good or wait for 0.65.4.

Dare I ask how long, rough estimate, before 0.65.4 will be released?


Not sure. The major version will bump. There's been a ton of changes under  
the scene, dealing with mostly webmail, maildrop, and imap. They need a good  
shaking out.


You can certainly patch this in. This is an almost a no-risk patch.




pgpYt5ASscufF.pgp
Description: PGP signature
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Malcolm Weir]

-Original Message-
From: Alessandro Vesely [mailto:ves...@tana.it] 
Sent: Friday, September 24, 2010 2:40 AM

 In my experience, enterprises of size actually operate dedicated boundary
 servers as their MX platforms, and final delivery is handled by an
entirely
 different set of servers often totally invisible to the outside user.

While that's correct, those invisible servers are not _primary_ MXes 
on the public Internet.  So, it is still unanswered why large 
enterprises may want to operate _secondary_ MXes, i.e. MXes with a 
higher preference number.

Ummm... the invisible servers are not actually any kind of MX on the
public
Internet, primary or otherwise.

There is a certain amount of confusion in this area because a lot of the
mindset
is structured around the notion that the primary MX is final recipient
(the
MDA), and other MX nodes end up relaying traffic to that primary.

But if you use a purpose designed boundary server whose sole job is
scanning
and filtering, then forwarding the scanned mail to distinct delivery nodes,
you
may well choose to implement multiple such systems attached to different
network
providers and/or points-of-presence.  In this model, the MX is just another
MTA,
quite distinct from the MDA and MSA.

For example: suppose you have campuses in Los Angeles and New York. Each
campus
has its own connection to the Internet, but also a private network between
the
two. Even if you want the bulk of outside traffic, and all mail, to go to
LA, it
may make sense to have an MX based in NY with a lower priority that routes
its
traffic to LA over the private network. That way a service outage on the LA
campus would not bring down all external mail acceptance.

I don't think we're in disagreement with anything, here, other than perhaps
the
issue created by the fact that MX server has been conflated with delivery
server, a fact that should surprise no-one who's seen the separation, over
time,
of the MTA, MDA and MSA parts of the system.

Malc.




--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX, alias

[Gordon Messmer]

Bernd Plagge wrote:
 
 As suggested previously in this list I'd like to set up alias
 for all existing mail accounts to avoid mail for invalid
 accounts to be accepted (and later bounced by the primary mail
 server).
 
 I tried it with:

   [EMAIL PROTECTED]  -  user1-domain1
 
 but this didn't work. 

That doesn't look like a line from an alias file.

To prevent looping, you'll want to use the hostname of your primary MX,
rather than the domain name in the alias destination.  Naturally, the
primary MX will need to consider its hostname a local domain.  If your
primary mx is mx1.domain1, then the alias should look like:

[EMAIL PROTECTED]: [EMAIL PROTECTED]

There should be no MX records in DNS for mx1.domain1.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX not working. Needs Help Please(456 Address temporarily unavailable.)

[Gordon Messmer]

Lourik Malan wrote:
 
 I'm using courier to backup mx for the a domain (test.co.za). Here is
 the config files i've configured.

Generally speaking, I think most people will recommend that you not run 
a backup MX.  They're going to be a spam target, and they don't really 
improve site reliability any more.

 :locals
 mx2.test.co.za
 
 :esmtpacceptmailfor
 test.co.za
 
 :Domain test.co.za:
 Relay: mx1.testco.za, Priority: 10, Address: 196.ip.ip.ip
 Relay: mx2.test.co.za, Priority: 20, Address: 192.168.4.2 [ LOCAL ]
 
 I get the following Error:
 :456 Address temporarily unavailable.

You need to be more specific about where you see that error.  It 
indicates that a previous delivery to the address specified failed. 
That probably means that the address is considered local, which would 
mean that the backup MX isn't configured correctly.  Without the 
address, and probably all of the related lines in the mail log, there's 
not much advice we can give you.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] DNS MX lookup failed

[Sam Varshavchik]

Grzegorz Janoszka writes:



Aug  3 09:52:15 poczta courieresmtpd: 
error,relay=:::193.41.230.201,from=[EMAIL PROTECTED]: 417 SPF 
error [EMAIL PROTECTED]: DNS MX lookup failed.?


Is any way to remove such errors?

This machine has no problem to see MX:

poczta:~# host -t mx mbank.pl
mbank.pl mail is handled by 0 mail.bremultibank.com.pl.
mbank.pl mail is handled by 10 mx.bremultibank.com.pl.


One single DNS lookup doesn't really say much.  Perhaps mbank.pl's DNS 
servers are flaky, or one of .pl's servers was briefly on a fritz.





pgp6ugJ9olnFQ.pgp
Description: PGP signature

RE: [courier-users] To MX or not...

[Martijn Lievaart]

Julian Mehnle said:
 Jay Lee [EMAIL PROTECTED] wrote:
 You will lose mailinglist mail?  Huh??  I never had such a problem.  Why
 would that happen?

After the mailtroubles are restored, I get a notification from the
mailinglist which mails could not be delivered. In that sense you don't
loose mail, you just have to get it yourself.

I'm not sure which mailinglist it was last time (I think Bugtraq), but I
have seen this behaviour over the years with multiple mailinglists. Now
this would be fine if the timeouts on those lists would be anything near
an normal MTA, however these seem to be a few hours at most. I can
understand that a big mailinglist server does not want a large baglog, so
the timeouts are kept short, but this is a pain when your mail goes down
for more than a couple of hours.

Greetz,
M4



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Alessandro Vesely]

Julian Mehnle wrote:
 
 Jay Lee [EMAIL PROTECTED] wrote:
  Julian Mehnle said:
   If it's a cost issue, run just one (i.e. drop the differently
   configured secondary MX).  That's what I actually do.
 
  Have you ever had issues with downtime or lost mail?
 
 Nothing where a secondary MX would have helped.

Once that happened to me: a server monitor in North America
sent me a warning that my web server was not reachable. I
received it through the secondary MX while that monitor was
still not reachable from my net.

I don't think such sporadic result justifies running an
uncontrolled secondary MX.


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Frederik Dannemare]

On Thursday 20 January 2005 09:54, Martijn Lievaart wrote:
 Julian Mehnle said:
  Jay Lee [EMAIL PROTECTED] wrote:
  You will lose mailinglist mail?  Huh??  I never had such a
  problem.  Why would that happen?

 After the mailtroubles are restored, I get a notification from the
 mailinglist which mails could not be delivered. In that sense you
 don't loose mail, you just have to get it yourself.
[ snip ]

And some mailing lists will also unsubscribe you after x number of mails 
that bounces, so one may also have to re-subscribe to some lists. I 
have seen this happen with lkml a couple of times.
-- 
Frederik Dannemare | mailto:[EMAIL PROTECTED]
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://frederik.dannemare.net | http://www.linuxworlddomination.dk


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Mark Bucciarelli]

On Wednesday 19 January 2005 16:18, Jay Lee wrote:

  So here's my question, would it be risky to drop the backup MX
 completely?  

There was a long thread on this topic on debian-isp in Nov:

http://lists.debian.org/debian-isp/2004/11/msg00080.html

Regards,

Mark


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] 517-MX records..

[Bowie Bailey]

From: Dick Hoogendijk [mailto:[EMAIL PROTECTED]
 
 On 17 Jan Bowie Bailey wrote:
  From: Phillip Hutchings [mailto:[EMAIL PROTECTED]
   demarskramer.nl: their.mx.ip.address
  Actually, that should be:
  demarskramer.nl: [their.mx.ip.address]
 
 I have it without the brackets and all seems to work just fine. Mail
 gets delivered at last ;-)

Well, if it works, it works...

But from the man page:

domain:relay[,port][/SECURITY=STARTTLS][/SECURITY=NONE]

relay  can  be  another domain, or an explicit IP address inside
brackets. For example, if esmtproutes contains the following:

example.com: relay.domain.com
domain.com: [192.168.0.2]

Mail for example.com is delivered to relay.domain.com,  ignoring
any  MX  records  for  example.com.  Mail for domain.com will be
delivered to the machine at IP address  192.168.0.2.  All  other
domains will have their MX and A records looked up.

Bowie


---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Ben Kennedy]

On 19 1 2005 at 4:18 pm -0500, Jay Lee wrote:

 However, more recently,
spammer techniques has caused me to rethink the usefulness of a
Backup MX Server which accepts all mail for delivery, without spam
filters or rcpt checking.

The obvious solution is to put spam filtering and rcpt checking on your
secondary MX.  Why is this not an option?

It's what I do.  Both of my machines run identical filtering.

-ben

-- 
Ben Kennedy, chief magician
zygoat creative technical services
613-228-3392 | 1-866-466-4628
http://www.zygoat.ca




---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Jay Lee]

Ben Kennedy said:
 On 19 1 2005 at 4:18 pm -0500, Jay Lee wrote:

 However, more recently,
spammer techniques has caused me to rethink the usefulness of a
Backup MX Server which accepts all mail for delivery, without spam
filters or rcpt checking.
 The obvious solution is to put spam filtering and rcpt checking on your
 secondary MX.  Why is this not an option?
 It's what I do.  Both of my machines run identical filtering.

Because the backup MX is not in my control.  Yes, I could put a secondary
MX on my network and have identical rcpt/spam checking but if my T1 goes
down, the primary and secondary mx both go down.  We cannot afford
redundant network connections at this time.  I guess one solution would be
to have a server hosted at another ISP but under my control but the cost
of that would probably not be to much less than a backup DSL line or such.

Jay
-- 
Jay Lee
Network / Systems Administrator
Information Technology Dept.
Philadelphia Biblical University
--


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] To MX or not...

[Robert Pfister]

When spam inevitably sneaks through, you end up with it twice


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Kennedy
Sent: Wednesday, January 19, 2005 2:38 PM
To: Courier Users
Subject: Re: [courier-users] To MX or not...

On 19 1 2005 at 4:18 pm -0500, Jay Lee wrote:

 However, more recently,
spammer techniques has caused me to rethink the usefulness of a Backup 
MX Server which accepts all mail for delivery, without spam filters or 
rcpt checking.

The obvious solution is to put spam filtering and rcpt checking on your
secondary MX.  Why is this not an option?

It's what I do.  Both of my machines run identical filtering.

-ben

--
Ben Kennedy, chief magician
zygoat creative technical services
613-228-3392 | 1-866-466-4628
http://www.zygoat.ca




---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] To MX or not...

[Julian Mehnle]

Jay Lee [EMAIL PROTECTED] wrote:
  So here's my question, would it be risky to drop the backup MX
 completely?  We're on a T1 that has been extremely reliable the past
 few years.  Should we have an outage, we'd have 4 hours I believe
 until most mailservers would start generating delayed delivery
 messages back to remote senders and 4 days before most mail servers
 would give up on delivering a message (in which case we'd have time
 to update the DNS most likely).
 [...]
 What do you do?

I would run any number of _identically_ configured MXes.  One, two, more,
you name it.

If it's a cost issue, run just one (i.e. drop the differently configured
secondary MX).  That's what I actually do.



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] To MX or not...

[Jay Lee]

Julian Mehnle said:
 If it's a cost issue, run just one (i.e. drop the differently configured
 secondary MX).  That's what I actually do.

Have you ever had issues with downtime or lost mail?

Jay
-- 
Jay Lee
Network / Systems Administrator
Information Technology Dept.
Philadelphia Biblical University
--


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Martijn Lievaart]

Jay Lee wrote:
Julian Mehnle said:
 

If it's a cost issue, run just one (i.e. drop the differently configured
secondary MX).  That's what I actually do.
   

Have you ever had issues with downtime or lost mail?
 

I run the same configuration since a few months. One mailserver, ditched 
the backup MXes for the same reasons stated here. I have had troubles 
with mail (o.a. mail server crashed while I was on holiday, it was down 
for two days). The main issue is that mailinglists can be quite 
sensitive. You will loose mailinglist mail. Other than that no big 
problems occur. The sending servers do exactly the same function as your 
backup MX would, they store the mail for a reasonable time and notify 
the sender if it cannot be delivered.

I greatly recommend dropping all backup MXes you cannot lock down like 
your primaries.

M4

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] To MX or not...

[Julian Mehnle]

Jay Lee [EMAIL PROTECTED] wrote:
 Julian Mehnle said:
  If it's a cost issue, run just one (i.e. drop the differently
  configured secondary MX).  That's what I actually do.

 Have you ever had issues with downtime or lost mail?

Nothing where a secondary MX would have helped.

Martijn Lievaart [EMAIL PROTECTED] wrote:
 I run the same configuration since a few months. One mailserver, ditched
 the backup MXes for the same reasons stated here. I have had troubles
 with mail (o.a. mail server crashed while I was on holiday, it was down
 for two days). The main issue is that mailinglists can be quite
 sensitive. You will loose mailinglist mail. Other than that no big
 problems occur. The sending servers do exactly the same function as your
 backup MX would, they store the mail for a reasonable time and notify
 the sender if it cannot be delivered.

You will lose mailinglist mail?  Huh??  I never had such a problem.  Why
would that happen?



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] To MX or not...

[rogerk]

Quoting Julian Mehnle [EMAIL PROTECTED]:
 You will lose mailinglist mail?  Huh??  I never had such a problem.  Why
 would that happen?

For those of us who are used to RFC-'should'-friendly MTA's and MLM's, it
seems odd -- after all, five days or more of retries, right?

But in the past few weeks, I've been plagued by the following:
- a mass-mailer provided as a service for non-profits that is configured to
retry transmission 4 times within 2 hours and abort the transmission
- the Yahoo Groups policy of treating a single 5xx as reason to disable delivery
of all groups to any given address, even if it's a spam/virus block or other
content-related 5xx



---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] To MX or not...

[Justin Murdock]

Jay Lee wrote:
 Traditional Mail Server Configuration has always taught that it's a
good idea to have a Backup MX Server configured for your domain so
that if your SMTP Server or subnet were to go down, mail for your
domain could still be received.
From a time when a good number of internet links were not always-on. It
made a lot of sense to get mail closer to you, even if you were not
available to receive it.
 So here's my question, would it be risky to drop the backup MX
completely?
No
 We're on a T1 that has been extremely reliable the past
few years.  Should we have an outage, we'd have 4 hours I believe
until most mailservers would start generating delayed delivery
messages back to remote senders
Entirely dependant on the servers, but sendmail defaults to 4 hours.
Given the great unwashed's current expectations, this should be dropped
to half an hour or less
and 4 days before most mail servers
would give up on delivering a message (in which case we'd have time
to update the DNS most likely). 
Our domain hosts about 1500 accounts,
how are your backups? how quickly and reliably could you set up a new
mailserver AND user accounts?

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] 517-MX records..

[Dick Hoogendijk]

On 17 Jan Bowie Bailey wrote:
 From: Phillip Hutchings [mailto:[EMAIL PROTECTED]
  demarskramer.nl: their.mx.ip.address
 Actually, that should be:
 demarskramer.nl: [their.mx.ip.address]

I have it without the brackets and all seems to work just fine. Mail
gets delivered at last ;-)

-- 
dick -- http://www.nagual.st/ -- PGP/GnuPG key: F86289CE
++ Running FreeBSD 4.10 ++ Debian GNU/Linux (Woody)
+ Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja


---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] 517-MX records..

[dick hoogendijk]

On 16 Jan Martijn Lievaart wrote:
 dick hoogendijk wrote:
 
 517-MX records for demarskramer.nl violate section 3.3.9 of RFC 1035
 
 OK, I looked it up (dig bla bla) and it's wrong indeed. One IP and two
 FQDN's. It can't be helped though, I'm told. The IP is added and the
 sysadmins of demarskramer.nl cannot change that.
 
 So, does that mean I will not be able to send E-mail to people on that
 domain at all, or can this check be overruled? If so, where?
 
 Sorry for the obvious, but ofcourse it can be changed.  Host the domain 
 somewhere they understand RFCs and the magic word service. In .nl, I 
 recommend IAF, but there are many others. Hosting at essenkabel is 
 asking for trouble, those guys know central heating, but not DNS 
 (obviously).

Sure, you're right. But, as said, I don't control that domain. I just
want to have my courier mailer deliver mail there. Can that be done?

-- 
dick -- http://www.nagual.st/ -- PGP/GnuPG key: F86289CE
++ Running FreeBSD 4.10 ++ Debian GNU/Linux (Woody)
+ Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilya


---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] 517-MX records..

[Phillip Hutchings]

On 17/01/2005, at 10:47 PM, dick hoogendijk wrote:
On 16 Jan Martijn Lievaart wrote:
dick hoogendijk wrote:
517-MX records for demarskramer.nl violate section 3.3.9 of RFC 
1035

OK, I looked it up (dig bla bla) and it's wrong indeed. One IP and 
two
FQDN's. It can't be helped though, I'm told. The IP is added and the
sysadmins of demarskramer.nl cannot change that.

So, does that mean I will not be able to send E-mail to people on 
that
domain at all, or can this check be overruled? If so, where?
Sorry for the obvious, but ofcourse it can be changed.  Host the 
domain
somewhere they understand RFCs and the magic word service. In .nl, I
recommend IAF, but there are many others. Hosting at essenkabel is
asking for trouble, those guys know central heating, but not DNS
(obviously).
Sure, you're right. But, as said, I don't control that domain. I just
want to have my courier mailer deliver mail there. Can that be done?
esmtproutes. You have to hard code the MX in the esmtproutes file, and 
then courier will ignore the DNS. Check the man pages, but it goes like 
this iirc (note it uses the IP address, not the hostname):

demarskramer.nl: their.mx.ip.address
--
Phillip Hutchings
[EMAIL PROTECTED]
http://www.sitharus.com/


smime.p7s
Description: S/MIME cryptographic signature

RE: [courier-users] 517-MX records..

[Bowie Bailey]

From: Phillip Hutchings [mailto:[EMAIL PROTECTED]
 
 On 17/01/2005, at 10:47 PM, dick hoogendijk wrote:
   
  Sure, you're right. But, as said, I don't control that domain. I
  just want to have my courier mailer deliver mail there. Can that
  be done?
 
 esmtproutes. You have to hard code the MX in the esmtproutes file,
 and then courier will ignore the DNS. Check the man pages, but it
 goes like this iirc (note it uses the IP address, not the hostname):
 
 demarskramer.nl: their.mx.ip.address

Actually, that should be:

demarskramer.nl: [their.mx.ip.address]

Bowie


---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] 517-MX records..

[Martijn Lievaart]

dick hoogendijk wrote:
517-MX records for demarskramer.nl violate section 3.3.9 of RFC 1035
OK, I looked it up (dig bla bla) and it's wrong indeed. One IP and two
FQDN's. It can't be helped though, I'm told. The IP is added and the
sysadmins of demarskramer.nl cannot change that.
So, does that mean I will not be able to send E-mail to people on that
domain at all, or can this check be overruled? If so, where?
 

Sorry for the obvious, but ofcourse it can be changed.  Host the domain 
somewhere they understand RFCs and the magic word service. In .nl, I 
recommend IAF, but there are many others. Hosting at essenkabel is 
asking for trouble, those guys know central heating, but not DNS 
(obviously).

M4

---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Check MX on gateway

[Gordon Messmer]

chepil wrote:
How can I configure courier does not accept letters without MX record for
gateway IP (ip from)?
Your best option would be to use a firewall to segragate the Courier 
server from the internet, and allow traffic from your MX to pass through.

If that's not an option, I think you can set AUTH_REQUIRED=1 in the 
esmtpd file, and then set AUTH_REQUIRED=0 for the MX server's IP in 
smtpaccess.


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Pierre Ossman]

Patrick O'Reilly wrote:

From: Pierre Ossman [EMAIL PROTECTED]

 

Ok, I've tried this now and either I'm missing something or the
semantics aren't quite as you explained.
I'll try to explain my total configuration to give you a better view of
what I'm trying to acheive.
The machine is called mail.craffe.se. It is a MX for the domain
craffe.se. Sending mail to the domain works fine (it is later forwarded
to an internal server using esmptroutes). It is also a backup MX for the
domain mathias.nu. Being a backup MX I have the machine's name in locals
in order for the backup MX semantics to function properly. Sending mail
to the domain mathias.nu also works perfectly fine.
Now for the problem. Sending mail to, for example, [EMAIL PROTECTED]
results in the machine trying to deliver the mail to the local user
account 'luser'. I added mail.craffe.se to esmtproutes in an attempt to
redirect the mail, but the locals file seems to have priority. What I'd
like is that mail would have been redirected to [EMAIL PROTECTED] (i.e. to
the domain, not the machine) or have it rejected (with '550 User
unknown' or similar).
From what I can gather the only system that has priority over locals is
the aliases. And I doesn't seem to be a syntax that gives me what I want
(except one aliases for each and every user on the machine).
So, what are my options? I don't like the current situation where the
local users can receive mail but I can't figure out how to stop it.
Regards Pierre

   

Aha.

I think the whole secondary MX thing is a red herring...

Do you actually have local accounts which match the email addresses? -
'luser' in your above example.  If these are local shell accounts, perhaps
you should remove 'authvchkpw' from the authmodulelist in 'authdaemonrc'?!?
The fact that the account exists locally might interfere with any attempt to
use esmptroutes - but I'm guessing here.
I don't have any box configured the way you are describing, so here's my
best guess:
esmptroutes:
craffe.se:internalrelay.craffe.se
.craffe.se:internalrelay.craffe.se
locals:
craffe.se
.craffe.se
mathias.nu
esmtpacceptmailfor:
craffe.se
.craffe.se
mathias.nu
That's all I can think of.

 

Yes! It finally works! =)
Thanks for the help. Removing everything from authmodulelist effectively 
blocks all user. Should have thought of that one...
I also noticed another weird behaviour. If I send a mail to 
[EMAIL PROTECTED], the machine realises it's a local account and 
strips it down to just 'root'. I have also specified 'craffe.se' as the 
default domain (/etc/courier/defaultdomain) so when it aplies the 
standard alias 'root: postmaster' it becomes '[EMAIL PROTECTED]' and 
goes away to the internal server. Just the way I wanted, and I didn't 
have to touch a thing =)

So a question to you and/or anyone else who knows (probably only *Sam 
Varshavchik):
*Is this the intended behaviour (default domain being added when 
resolving aliases) or should I expect to have to change this alias to 
'root: [EMAIL PROTECTED]' at some point?

Regards
Pierre


---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Patrick O'Reilly]

From: Pierre Ossman [EMAIL PROTECTED]

 Ok, I've tried this now and either I'm missing something or the
 semantics aren't quite as you explained.

 I'll try to explain my total configuration to give you a better view of
 what I'm trying to acheive.

 The machine is called mail.craffe.se. It is a MX for the domain
 craffe.se. Sending mail to the domain works fine (it is later forwarded
 to an internal server using esmptroutes). It is also a backup MX for the
 domain mathias.nu. Being a backup MX I have the machine's name in locals
 in order for the backup MX semantics to function properly. Sending mail
 to the domain mathias.nu also works perfectly fine.

 Now for the problem. Sending mail to, for example, [EMAIL PROTECTED]
 results in the machine trying to deliver the mail to the local user
 account 'luser'. I added mail.craffe.se to esmtproutes in an attempt to
 redirect the mail, but the locals file seems to have priority. What I'd
 like is that mail would have been redirected to [EMAIL PROTECTED] (i.e. to
 the domain, not the machine) or have it rejected (with '550 User
 unknown' or similar).
  From what I can gather the only system that has priority over locals is
 the aliases. And I doesn't seem to be a syntax that gives me what I want
 (except one aliases for each and every user on the machine).

 So, what are my options? I don't like the current situation where the
 local users can receive mail but I can't figure out how to stop it.

 Regards Pierre


Aha.

I think the whole secondary MX thing is a red herring...

Do you actually have local accounts which match the email addresses? -
'luser' in your above example.  If these are local shell accounts, perhaps
you should remove 'authvchkpw' from the authmodulelist in 'authdaemonrc'?!?
The fact that the account exists locally might interfere with any attempt to
use esmptroutes - but I'm guessing here.

I don't have any box configured the way you are describing, so here's my
best guess:

esmptroutes:
craffe.se:internalrelay.craffe.se
.craffe.se:internalrelay.craffe.se

locals:
craffe.se
.craffe.se
mathias.nu

esmtpacceptmailfor:
craffe.se
.craffe.se
mathias.nu

That's all I can think of.



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Pierre Ossman]

Ok, I've tried this now and either I'm missing something or the 
semantics aren't quite as you explained.

I'll try to explain my total configuration to give you a better view of 
what I'm trying to acheive.

The machine is called mail.craffe.se. It is a MX for the domain 
craffe.se. Sending mail to the domain works fine (it is later forwarded 
to an internal server using esmptroutes). It is also a backup MX for the 
domain mathias.nu. Being a backup MX I have the machine's name in locals 
in order for the backup MX semantics to function properly. Sending mail 
to the domain mathias.nu also works perfectly fine.

Now for the problem. Sending mail to, for example, [EMAIL PROTECTED] 
results in the machine trying to deliver the mail to the local user 
account 'luser'. I added mail.craffe.se to esmtproutes in an attempt to 
redirect the mail, but the locals file seems to have priority. What I'd 
like is that mail would have been redirected to [EMAIL PROTECTED] (i.e. to 
the domain, not the machine) or have it rejected (with '550 User 
unknown' or similar).
From what I can gather the only system that has priority over locals is 
the aliases. And I doesn't seem to be a syntax that gives me what I want 
(except one aliases for each and every user on the machine).

So, what are my options? I don't like the current situation where the 
local users can receive mail but I can't figure out how to stop it.

Regards Pierre

Patrick O'Reilly wrote:

From: Pierre Ossman [EMAIL PROTECTED]

 

Thanks for the reply, but I'm afraid it doesn't quite answer my questions.
The problem was never mail directed to the domain that it was a backup
MX for. The problem is mail directed at the mail server itself.
So in a more condensed form:
* Does it check in 'me' when comparing MX records if 'locals' doesn't
   

exist?
 

* How can I block/redirect mail addressed to the mail server (_not_ the
domain it's handling) without having to put up an alias for every user
on the machine?
   

Ah.

Well, all the hostnames must be in 'locals', both for primary and secondary
roles.  And all the domain names must be in 'esmtpacceptmailfor'.  The
server will compare itself with the MX records.
* Where the server finds itself to be the MX at the lowest priority, it
will keep the email - you need to have a local account, or perhaps forward
it to a private internal mail server using 'smtproutes'.  Of course, if you
relay the mail using smtproutes, then the destination server will do the
user account validation.
* Where the server finds itself to be a secondary MX, it will queue the
mail for the primary MX.
I hope this is what you needed...

Patrick.

 



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Jeff Jansen]

On Monday 12 January 2004 05:30, Patrick O'Reilly wrote:
 all you need for the secondary MX server is the hostname entry in 'locals'
 (which must match the hostname listed in the MX record exactly, of course).

 When courier accepts the email and then recognises that this email address
 is not held locally it will consult the dns itself, see that there is
 another preferred MX record, and try to relay the email to that hostname.
 Presumably that host is temporarily unavailable, so the email will just sit
 in the mailq as usual until the primary MX is available again.

OK, I'm showing my ignorance here.  I don't follow this.  I thought in order 
to be a backup MX you needed an entry in acceptmailfor and specifically NOT 
in locals or hosteddomains.  If I am example.com and I want to function as 
a backup server for domain.com, then I put domain.com into 
/etc/courier/acceptmailfor.  Then my machine accepts mail for all addresses 
at domain.com and tries to ship it back out since this domain is not 
actually hosted on my machine.

If I put domain.com into locals then when any mail arrives for this domain 
won't it be rejected by courier with 550 - user unknown since this account 
does not exist on my machine?

What have I missed here?

Jeff Jansen



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Patrick O'Reilly]

 On Monday 12 January 2004 05:30, Patrick O'Reilly wrote:
  all you need for the secondary MX server is the hostname entry in
'locals'
  (which must match the hostname listed in the MX record exactly, of
course).
 
  When courier accepts the email and then recognises that this email
address
  is not held locally it will consult the dns itself, see that there is
  another preferred MX record, and try to relay the email to that
hostname.
  Presumably that host is temporarily unavailable, so the email will just
sit
  in the mailq as usual until the primary MX is available again.

 OK, I'm showing my ignorance here.  I don't follow this.  I thought in
order
 to be a backup MX you needed an entry in acceptmailfor and specifically
NOT
 in locals or hosteddomains.  If I am example.com and I want to function
as
 a backup server for domain.com, then I put domain.com into
 /etc/courier/acceptmailfor.  Then my machine accepts mail for all
addresses
 at domain.com and tries to ship it back out since this domain is not
 actually hosted on my machine.

 If I put domain.com into locals then when any mail arrives for this
domain
 won't it be rejected by courier with 550 - user unknown since this
account
 does not exist on my machine?

 What have I missed here?


Oops - I omitted mentioning 'esmtpacceptmailfor'.  Here's a quaestion posted
on this list some time ago, and the answer which was from Sam:

 I have a machine which is the secondary mail server for domain1.com
 and domain2.com.  The machine is known as mail2.domain1.com and
 mail2.domain2.com in the MX records.  What is the proper way to
 configure Courier so that it will spool the mail and then deliver it to
 the primary mail servers when they are available?

domain1.com and domain2.com in esmtpacceptmailfor

mail2.domain1.com and mail2.domain2.com in locals

MX records for mail2.domain1.com and mail2.domain2.com indicating a higher
priority than the MX records for the primary MX.

The process is very simple.

When sending mail via ESMTP, MX records are read and sorted.  Each record is
checked against the local domain list.  If a record is found that's naming
the local machine, all MX records with the same, or higher, priority are
removed.

HTH - Patrick.




---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Pierre Ossman]

Thanks for the reply, but I'm afraid it doesn't quite answer my questions.
The problem was never mail directed to the domain that it was a backup 
MX for. The problem is mail directed at the mail server itself.
So in a more condensed form:

* Does it check in 'me' when comparing MX records if 'locals' doesn't exist?

* How can I block/redirect mail addressed to the mail server (_not_ the 
domain it's handling) without having to put up an alias for every user 
on the machine?

Regards Pierre

Patrick O'Reilly wrote:

Pierre,

all you need for the secondary MX server is the hostname entry in 'locals'
(which must match the hostname listed in the MX record exactly, of course).
When courier accepts the email and then recognises that this email address
is not held locally it will consult the dns itself, see that there is
another preferred MX record, and try to relay the email to that hostname.
Presumably that host is temporarily unavailable, so the email will just sit
in the mailq as usual until the primary MX is available again.
Regards,
Patrick.
- Original Message -
From: Pierre Ossman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 9:47 PM
Subject: [courier-users] Backup MX configuration
 

Hi!

I've been using courier for awhile now and I think it's a great piece of
software. I am, however, not quite clear about how to configure it as a
backup MX server.
From the FAQ I can read that:
Furthermore, the hostname in the MX record must be one of the hostnames
in the |locals| configuration file.
Is it absolutely crucial that this hostname exists in 'locals' or does
it follow normal semantics and defaults to 'me' when 'locals' doesn't
   

exist?
 

Also, I'd prefer to not have any mail delivered to the machine acting as
a backup MX. But the constraint above makes it consider any mail to
[EMAIL PROTECTED] to be a local mailbox. If it is possible
I'd like it to forward this mail to [EMAIL PROTECTED] instead. Setting
up an alias for every user is not an option. I need some kind of
   

catch-all.
 

If this is not possible, then can I configure it to bounce all mail
heading for [EMAIL PROTECTED]? There are user accounts on the
machine but I don't want them to receive mail.
I don't know if you're supposed to retain some accounts going to
specific mail servers ([EMAIL PROTECTED] comes to
mind). If so, I'd appreciate any pointers on what's customary to have
set up. Maintaining aliases for some system critical stuff is
acceptable, having to put up a new reject rule for each new user on the
machine is not.
Regards Pierre Ossman

PS. Could you cc any replies to this address since I'm not subscribed to
courier-users, thanks.
   



 



---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Patrick O'Reilly]

Pierre,

all you need for the secondary MX server is the hostname entry in 'locals'
(which must match the hostname listed in the MX record exactly, of course).

When courier accepts the email and then recognises that this email address
is not held locally it will consult the dns itself, see that there is
another preferred MX record, and try to relay the email to that hostname.
Presumably that host is temporarily unavailable, so the email will just sit
in the mailq as usual until the primary MX is available again.

Regards,
Patrick.

- Original Message -
From: Pierre Ossman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 9:47 PM
Subject: [courier-users] Backup MX configuration


 Hi!

 I've been using courier for awhile now and I think it's a great piece of
 software. I am, however, not quite clear about how to configure it as a
 backup MX server.
  From the FAQ I can read that:

 Furthermore, the hostname in the MX record must be one of the hostnames
 in the |locals| configuration file.

 Is it absolutely crucial that this hostname exists in 'locals' or does
 it follow normal semantics and defaults to 'me' when 'locals' doesn't
exist?

 Also, I'd prefer to not have any mail delivered to the machine acting as
 a backup MX. But the constraint above makes it consider any mail to
 [EMAIL PROTECTED] to be a local mailbox. If it is possible
 I'd like it to forward this mail to [EMAIL PROTECTED] instead. Setting
 up an alias for every user is not an option. I need some kind of
catch-all.
 If this is not possible, then can I configure it to bounce all mail
 heading for [EMAIL PROTECTED]? There are user accounts on the
 machine but I don't want them to receive mail.

 I don't know if you're supposed to retain some accounts going to
 specific mail servers ([EMAIL PROTECTED] comes to
 mind). If so, I'd appreciate any pointers on what's customary to have
 set up. Maintaining aliases for some system critical stuff is
 acceptable, having to put up a new reject rule for each new user on the
 machine is not.

 Regards Pierre Ossman

 PS. Could you cc any replies to this address since I'm not subscribed to
 courier-users, thanks.





---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Backup MX configuration

[Chris Petersen]

 When courier accepts the email and then recognises that this email address
 is not held locally it will consult the dns itself, see that there is
 another preferred MX record, and try to relay the email to that hostname.
 Presumably that host is temporarily unavailable, so the email will just sit
 in the mailq as usual until the primary MX is available again.

Unfortunately, if the main MX server has bofh rules (like mine does - a
lot of them), but the secondary doesn't, the administrator of the
secondary server will get all of the bounced messages, rather than the
original sender (which is why my friend who secondaries the rest of my
services told me to stop using him as a secondary MX - he refuses to
give in to spammers by imposing manual bofh rules).  This is one
reason why spammers prefer to direct mail towards secondary MX servers
rather than primary ones.

-- 
Chris Petersen
Programmer / Web Designer
Silicon Mechanics:  http://www.siliconmechanics.com/
Blade Servers:  http://www.siliconmechanics.com/c292/blade-server.php
1U Servers: http://www.siliconmechanics.com/c272/1u-server.php




---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] bad MX problems...

[Thomas von Hassel]

On Tuesday, September 23, 2003, at 11:27 PM, Evelyn Pichler wrote:

I second that (and yes, I also got users asking me what this RFC thing 
is they are getting...)

Ev

snip

Well, to finish this lengthy read, I made some minor modifications in
order to avoid the infamous This domain's MX violates RFC 1035
messages. I'm sending the diff files for your review. If anyone is
interested, please give it a try, if you find a correction to this
patch, please share it.
I would prefer Sam to produce an official patch, and give us the 
choice
to perform this checks or no. BE_A_MX_WHORE sounds like a good name
for the controlling env var I think ;-)
snip

I have to disagree, while it can be a pain in the butt to deal with 
disgruntled users and idiot admins, if we start slacking up on things 
like this we end up with a set of RFC's that don't mean squat to people 
...

/thomas



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] bad MX problems...

[Malcolm Weir]

 -Original Message-
 From: Thomas von Hassel
 Sent: Wednesday, September 24, 2003 12:17 AM

[ Snip ]

 I have to disagree, while it can be a pain in the butt to deal with
 disgruntled users and idiot admins, if we start slacking up on things
 like this we end up with a set of RFC's that don't mean squat to people
 ...

Yet there is at least a viable school of thought that this particular
feature is not forbidden, just strongly discouraged, as in should not
compared with must not or shall not.

Now, whether or not *you* happen to agree with that reading is entirely
secondary to the issue of whether an admin, who may not be an idiot, does.
And if he does, you (and your disgruntled users) lose.

Which leads to the inevitable observation that there are no prizes for
conformance to the RFC, but there are for getting the job done.  The job of
a mail transfer agent is to transfer mail.  Not pass a conformance test
based on a specific interpretation of an RFC...

 /thomas

Malc.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] bad MX problems...

[Phillip Hutchings]

On Wednesday, Sep 24, 2003, at 19:50 Pacific/Auckland, Malcolm Weir 
wrote:

-Original Message-
From: Thomas von Hassel
Sent: Wednesday, September 24, 2003 12:17 AM
[ Snip ]

I have to disagree, while it can be a pain in the butt to deal with
disgruntled users and idiot admins, if we start slacking up on things
like this we end up with a set of RFC's that don't mean squat to 
people
...
[...]
Which leads to the inevitable observation that there are no prizes for
conformance to the RFC, but there are for getting the job done.  The 
job of
a mail transfer agent is to transfer mail.  Not pass a conformance test
based on a specific interpretation of an RFC...
I would disagree on this. The MTAs job is to transfer mail based on the 
set of standards in the RFCs. If these standards are open to 
interpretation then there will be discrepancies between the MTAs.

In this case Courier has chosen a stricter interpretation of the RFCs.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

RE: [courier-users] bad MX problems...

[Malcolm Weir]

 -Original Message-
 From: Phillip Hutchings
 Sent: Wednesday, September 24, 2003 1:26 AM

[ Snip ]

  Which leads to the inevitable observation that there are no prizes for
  conformance to the RFC, but there are for getting the job done.  The
  job of
  a mail transfer agent is to transfer mail.  Not pass a conformance test
  based on a specific interpretation of an RFC...

 I would disagree on this. The MTAs job is to transfer mail based on the
 set of standards in the RFCs.

Not true.  The MTA's job is to transfer mail.  Period.

The techniques used to transfer mail are defined by the MTAs.  But it is
simply erroneous to confuse the task with the protocols, and indeed the
implementation of the protocols!

 If these standards are open to
 interpretation then there will be discrepancies between the MTAs.

And that would be a problem... why?

Oh, yes, because it would impair the ability to transfer mail.

So your argument boils down to the notion that relaxing the requirements on
MX record definitions to permit users to transfer mail is a problem because
it would somehow allegedly impair the ability of the MTA to transfer mail...

Logically, we call that reductio ad absurdum, and absurd is an appropriate
word!

If you look back at the history of the IETF, you'll find that in many cases
the RFC simply codifies accepted practice, so the argument that accepted
practice is wrong because a given RFC doesn't cover it is erroneous.

I would draw your attention to this extract from RFC2555:

[ About the culture behind the RFCs: ]

  The RFCs themselves also represented a certain sense of fear.  After
   several months of meetings, we felt obliged to write down our
   thoughts.  We parceled out the work and wrote the initial batch of
   memos.  In addition to participating in the technical design, I took
   on the administrative function of setting up a simple scheme for
   numbering and distributing the notes.  Mindful that our group was
   informal, junior and unchartered, I wanted to emphasize these notes
   were the beginning of a dialog and not an assertion of control.

 In this case Courier has chosen a stricter interpretation of the RFCs.

And, in this case, the question becomes... why?  Or at least, why not
provide a means to relax that interpretation on a per-site basis?

Remember, the RFCs don't *do* anything, so claiming conformance is a hollow
claim, *unless* the actual _goals_ that RFCs set out to standardize are also
met.  In this case, the goal is transferring mail.  And absent a good
argument *why* the MX records *must* point to an A record (as opposed to
SHOULD point to one), refusing to accept mail from clients that don't have
an MX pointing to an A is simply capricious: surely it is the DNS system's
area of responsibility to enforce DNS rules?

[ By contrast, insisting on an MX that is ultimately resolvable to an A
record is not capricious, since SMTP requires that... the issue is *how* the
MX gets resolved, not whether it gets resolved ].

I've spent a lot of my professional life dealing with standards, and I can
promise you that telling a prospective client that the reason your product
doesn't interoperate is the other vendor's fault is usually greeted with a
question as to the problem with conforming to the de facto, instead of de
jure, standard...

By the way, this attitude that the requirement is X, we meet X, therefore
any problems must be handled by the other guy is the old attitude of
companies like IBM and DEC (who, I grant you, wrote the specs) and
Microsoft.  None of whom were or are noted for being models of
interoperability!

Malc.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] bad MX problems...

[Evelyn Pichler]

I second that (and yes, I also got users asking me what this RFC thing is 
they are getting...)

Ev

snip

Well, to finish this lengthy read, I made some minor modifications in
order to avoid the infamous This domain's MX violates RFC 1035
messages. I'm sending the diff files for your review. If anyone is
interested, please give it a try, if you find a correction to this
patch, please share it.
I would prefer Sam to produce an official patch, and give us the choice
to perform this checks or no. BE_A_MX_WHORE sounds like a good name
for the controlling env var I think ;-)
snip  



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] bad MX problems...

[Eduardo Roldan]

On Tue, 2003-09-23 at 16:35, Carlos Paz wrote:

 
 I would prefer Sam to produce an official patch, and give us the choice
 to perform this checks or no. BE_A_MX_WHORE sounds like a good name
 for the controlling env var I think ;-)

Agreed.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Lukas Vesely]

On Thu, 30 May 2002, Sam Varshavchik wrote:

 Lukas Vesely writes:


  I have to agree with Alexej.
  Much nicer behaviour of Courier would be when upon receiving mail from
  misconfigured domain the courier itself would send mail to either
  Postmaster@thatdomain

 Which will immediately bounce because @thatdomain does not have any valid
 mail relays.

Well, I was talking about pointing the MX record to IP addresses, you
know. So in this case the mail wouldn't bounce.



___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Luc Brouard]

On Wed, May 29, 2002 at 05:02:51PM -0400, Sam Varshavchik wrote:
 Anand Buddhdev writes: 
 
 
 I have also seen this, and I posed this question to Sam some time
 ago. Since he did not come back with a no, I'm hoping he has put this
 request on his todo list, and that it will appear in courier soon. Sam,
 are you working on such a feature?
 
 I have not decided yet. 

I think it should be done, that's what MX are for .. moreover when they
have the same weight !

Luc

___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Lukas Vesely]

On Thu, 30 May 2002, Luc Brouard wrote:

 On Wed, May 29, 2002 at 05:02:51PM -0400, Sam Varshavchik wrote:
  Anand Buddhdev writes:
 
  
  I have also seen this, and I posed this question to Sam some time
  ago. Since he did not come back with a no, I'm hoping he has put this
  request on his todo list, and that it will appear in courier soon. Sam,
  are you working on such a feature?
 
  I have not decided yet.

 I think it should be done, that's what MX are for .. moreover when they
 have the same weight !

Yes, I guess so also!  Or at least to have the possibility to turn this
feature on.

Lukas


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Lukas Vesely]

On Thu, 30 May 2002, Alexei Batyr' wrote:

 Sam Varshavchik writes:

  Alexei Batyr' writes:
 
   Sam Varshavchik writes:
  
   mz.ru is broken.
   ...
   maxmail.co.uk is horribly broken.  maxmail.co.uk should win the Broken
   DNS
   of the year award.
  
   Everything is working the way it should be working.
  
   I didn't state that these domains' DNSes are not broken, I just said
 that
   courier reports these existent domains as nonexistent. The fact that
 some
   domain have broken DNS records could not automatically be treated as the
   reason for bouncing all mail from that domain.
 
  It most certainly is.  That's the whole purpose of the CHECKDNS option: to
  bounce mail from undeliverable domains.  None of those domains are
  deliverable.

 Most certainly doesn't mean always. One example: mz.ru is undeliverable
 but perfectly valid domain of mailing list server mailzone.ru. These gyus
 intentionally or erroneously configured their domain as undeliverable, but
 there could be users who nevertheless would like to recieve messages from
 their lists.

 It would be nice if courier could make difference between nonexistent and
 nondeliverable domains and postmaster could configure BOFH options for
 each case.

I have to agree with Alexej.
Much nicer behaviour of Courier would be when upon receiving mail from
misconfigured domain the courier itself would send mail to either
Postmaster@thatdomain or dns admin from that domain explaining what's
wrong with their MX record with some clues how to fix it. IMHO many
'admins' would accept it and fix it, because they don't have it
misconfigured on purpose.

Lukas


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Juha Saarinen]

On Thu, 30 May 2002, Sam Varshavchik wrote:

  It most certainly is.  That's the whole purpose of the CHECKDNS option: to
  bounce mail from undeliverable domains.  None of those domains are
  deliverable.

I would agree with Sam here:

dnslookup router called for [EMAIL PROTECTED]
  domain = maxmail.co.uk
DNS lookup of maxmail.co.uk (MX) succeeded
DNS lookup of smv06.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of smv04.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of smv05.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of smv07.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of maxmail-co-uk.mr.outblaze.com (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of smv03.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of smv08.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of maxmail-co-uk-bk.mr.outblaze.com (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of spool.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
DNS lookup of mail.globecomm.net (A) gave HOST_NOT_FOUND
returning DNS_NOMATCH
fully qualified name = maxmail.co.uk
host_find_bydns yield = HOST_FIND_FAILED (0); returned hosts:
  smv06.globecomm.net null 10 *
  smv04.globecomm.net null 10 *
  smv05.globecomm.net null 10 *
  smv07.globecomm.net null 10 *
  maxmail-co-uk.mr.outblaze.com null 10 *
  smv03.globecomm.net null 10 *
  smv08.globecomm.net null 10 *
  maxmail-co-uk-bk.mr.outblaze.com null 20 *
  spool.globecomm.net null 20 *
  mail.globecomm.net null 30 *
dnslookup router declined for [EMAIL PROTECTED]
more is false: skipping remaining routers
no more routers
[EMAIL PROTECTED] is undeliverable:
  all relevant MX records point to non-existent hosts


Yep... maxmail.co.uk receives the award for most broken DNS...

-- 
Juha Saarinen


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Re: [courier-users] Re: MX Lookup sending

[Juha Saarinen]

On Thu, 30 May 2002, Lukas Vesely wrote:

  Much nicer behaviour of Courier would be when upon receiving mail from
  misconfigured domain the courier itself would send mail to either
  Postmaster@thatdomain or dns admin from that domain explaining what's
  wrong with their MX record with some clues how to fix it. IMHO many
  'admins' would accept it and fix it, because they don't have it
  misconfigured on purpose.

How's that possible if their DNS is broken and they can't receive mail?
What do you do with the bounces? Accepting mail from
non-existent/non-routable domains can really come back and bite you in the
arse.

-- 
Juha Saarinen


___

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

___
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users