Re: [vps-mail] Sendmail - going from spammers.db to access.db

[Weldon Whipple <weldon@xxxxxxxxxxx>]

Marjolein Katsma wrote:

> Comment at the top of default.mc says:
> # Relayers can authenticate with either POP before SMTP or SMTP AUTH
>
> Except, when Eudora tried that, with sendmail.cf based on default.mc, it was rejected. So, my conclusion now is that somehow, authentication with SMTP AUTH was _not_ allowed, in spite of what this comment states. When I UNchecked "Authentication allowed" in Eudora, mail got through again.
>
>  
I've heard of lots of people with similar problems to yours (using 
Eudora), who have solved the problem the same way.

> > Those rules include a pop-before-smtp-relay check of the relayers database, 
> > which short circuits (and prevents from happening) sendmail's check for RELAY 
> > lines in access.db.
> >    
>
> I see are three lines _apparently_ setting up SMTP AUTH (?):
> # SMTP AUTH configuration for relaying through server
> define(`confAUTH_MECHANISMS',`PLAIN LOGIN')dnl
> TRUST_AUTH_MECH(`PLAIN LOGIN')dnl
>  
The few times I've used Eudora, I noticed that it tries to use a third 
mechanism called CRAM-MD5 by default.. While CRAM-MD5 is a superior 
authentication mechanism (because it is encrypted), it is an extreme 
pain to configure and set up on VPS1. (That's why it isn't in any of the 
default configurations.) Last time I checked, all Microsoft clients use 
the LOGIN mechanism (exclusively). Most other clients use the LOGIN 
and/or PLAIN mechanisms. (Two months ago, when I was trying out 
different clients, I jotted down a few--random and incomplete--notes. 
You can read them at: http://www.technoids.org/saslmech.html)

> What notice is:
> - in default.mc these lines occur _before_ the lines setting up access.db, while 
> - in default-auth-only.mc these lines occur after the access.db definition
>
> (And a comment at the top of default-auth-only.mc states:
> # Relayers must authenticate with SMTP AUTH
> Must?)
>  
>
> > If you don't use pop-before-smtp-relay, then you can use switch to the mc file 
> > named default-auth-only.mc. I think the only difference between it and the 
> > default.mc file is that the Local_check_rcpt ruleset is deleted
> >    
>
> That, too - but the location of the SMTP AUTH configuration is different as well. And the setting up of the relayers map (Krelayers) is also missing in default-auth-only.mc
>  
Ah, yes. (I should have grepped before I posted ... [sigh])

> > ... so RELAY lines in access.db will work.
> >    
>
> Looking at default.mc, I think one could accomplish the same (RELAY working in access.db) by merely moving the three lines mentioned above _after_ the access.db lines, just like they are in default-auth-only.mc ?
> Comments?
>  
This is probably more than you want to know, but here goes:

If you include the two lines about authentication mechanisms 
(confAUTH_MECHANISMS and TRUST_AUTH_MECH) in a "vanilla" sendmail mc 
file and generate a cf file, the build process will dutifully generate 
all the rules needed for SMTP authentication.

The reason the three "home-grown"  SMTP AUTH lines had to be added 
*before* the POP-before-SMTP rules in the LOCAL_RULESETS is because the 
Local_check_rcpt ruleset (if present) is invoked before sendmail's 
"standard" check_rcpt ruleset--and can potentially 
trumps/override/affect the outcome of the standard check_rcpt rule set.  
At Verio (historically) relayers.db has been (until now, at least), the 
final word on who gets to relay through the server. If a client IP 
address appears in relayers.db, the client gets to relay; it not, she 
doesn't (and that's *final*--at least with the default.mc :-). However, 
since SMTP AUTH is the "current"  preferred relay method in the sendmail 
world (at large), three SMTP AUTH lines appear first, to allow those who 
can authenticate to relay (before they are "shut out" by not being in 
relayers.db).

If you remove the Local version of check_rcpt (which, as you might have 
guessed by its name, sendmail calls right after the client issues the 
SMTP "RCPT TO:" command to specify the envelope recipient),  then 
sendmail's other "standard" rules will handle SMTP authentication just 
fine ... (because of the presence of the confAUTH_MECHANISMS and 
TRUST_AUTH_MECH lines ...)

As far as reordering the lines *within* Local_check_rcpt is concerned: 
do it at your own risk!

Sendmail is more forgiving when it comes to the order of the macros 
definitions, FEATUREs, etc., in the mc file. However, in some cases, 
order is important. If (for example) you use procmail as the local 
delivery agent, you *must* include one (not both!!) of the lines:

define(`local_procmail_lmtp')

OR

define(`local_procmail')

*before*

the MAILER lines!

(See one of the default procmail mc files in the VPS1 sendmail vinstall 
directory ~/usr/local/sendmail/cf/cf  for examples ...)

When I look for a place to insert a new FEATURE or define, I generally 
look for other FEATUREs and defines and insert in the same general 
vicinity ...

> Except, now that Eudora is no longer set up to use AUTH (only) I don't think I need RELAY lines in access.db at all. And if I don't need those, I don't need to change the order in which SMPT AUTH (?) and access.db are set up either.
>
> I think, for now, I'll just continue with my default.mc based config and move on to set up access.db. Unless I'm still missing something really important here...
>  
I think you're set to go. ("If it ain't broke, don't fix it!")

Weldon

======================================================================
This is <vps-mail@xxxxxxxxxxxx>       <http://www.perlcode.org/lists/>
======================================================================