Little help w/ greylisting bypass for SMTP AUTH-ed sessions

Pawel Osiczko p.osiczko@tetrapyloctomy.org
Mon Dec 11 05:09:49 UTC 2006


Hi Vernon,

Thank you for your reply. I think I've solved this issue as you had
pointed me in the right direction. Turns out that the hackmc line you
mentioned,
R<$={TrustAuthMech}> $* $: $(macro {dcc_notspam} $@ authenticated $) <> $2
was in fact not in my sendmail.cf even though I munged my mc file with
hackmc.

The last addition in hackmc which is meant to add pertinent lines after
SLocal_check_mail (the delimiters are
"/^S${AUTH}check_mail/,/^SLocal_check_mail/{" ). The issue is that my
sendmail.cf generated by m4 (version 8.13.8) spits out:

######################################################################
###  check_mail -- check SMTP `MAIL FROM:' command argument
######################################################################

SLocal_check_mail
(...)

So, I've fixed it like so in hackmc:

185c185
<           -e "/^S${AUTH}check_mail/,/^SLocal_check_mail/{"            \
---
>           -e "/^#* *check_mail/,/^SLocal_check_mail/{"                \

This presumes that you are passing -T into hackmc. Additionally, I had
FEATURE(`delay_checks')dnl which had to be disabled. After that things
started working.

Thanks for your help and a bit of tutorial on dcc.

--p

PS
Next time, I'll remember to send the right version of the log to the
list without, err, 64base coded passwords and stuff. 8-)

Vernon Schryver wrote:
>> From: Pawel Osiczko 
> 
>> I was wondering if you could help me out w/ greylist bypass for authenticated
>> sessions in sendmail.
> 
> Depending on the situation, there may be something better than fully
> whitelisting clients.  People trying to use typical MUAs such as Netscape
> that use SMTP as a mail submission protocol but do not understand any
> 4yz rejections, such as for too many recipients, have problems.
> If possible, they should be whitelisted by IP address with lines like
> 
> submit  ip  10.2.3.0/24
> 
> That tells dccm or dccifd that the SMTP clients must not be greylisted
> or be given 4yz rejections for conflicts in per-user DCC whiteclnt files
> among targets, but does not otherwise whitelist them.  This way dccm
> can still detect and reject spam, such as a trojan trying to send spam
> through your smarthost.
> 
> Of course, clients that send legitimate bulk mail need to be fully
> whitelisted.
> 
> 
> 
>>                       I generated sendmail.cf with hackmc -AROT. With dcc
>> up and running and with sendmail authenticating against saslauthd, I specify
>> option MTA-first to attempt to whitelist authenticated sessions. 'Cept it does
>> not work. After TLS-ed AUTH PLAIN succeeds, the message is embargoed leaving
>> client all hot, bothered, and confused. Here is what my sendmail sees:
> 
> 
>> Nov 29 21:51:59 foo sm-mta[24096]: kAU4plca024096: <-- AUTH PLAIN AHBhYmxvAGxpVkYhMEQ=
>> Nov 29 21:51:59 foo sm-mta[24096]: kAU4plca024096: --- 235 2.0.0 OK Authenticated
> 
> Is TRUST_AUTH_MECH set in the .mc file?
> Does it include "PLAIN" or whatever?
> When a message gets through, does the Received: header say that TLS
> authentication worked with "verify=OK"?
> 
> As you can see from the changes that hackmc makes to sendmail.cf,
> dccm simply obeys the sendmail ${dcc_notspam} macro that should be set
> with this sendmail.cf line:
> 
>    R<$={TrustAuthMech}> $* $: $(macro {dcc_notspam} $@ authenticated $) <> $2
> 
> The ${dcc_notspam} mechanism works for me with STARTTLS self-signed PKI
> certs.  However, there may be something wrong with SMTP-AUTH, because
> Sam Leffler has reported being unable to make authentication whitelist
> senders.  I do not have a test-bed for SMTP-AUTH.
> 
> 
> The problem of users getting all hot and bothered by greylisting often
> indicates that they know less than they think they do about email.  They
> choose to not understand that a 4yz rejection will not delay their
> incoming mail by more than 15 or 30 minutes if the sending SMTP client
> is reasonable, and that the delay will happen only once.  For the most
> part, such hot and bothered lusers are reacting to delays that are
> already finished when they see them.  The hot luser problem is so common
> that years ago an ISP suggested and I added a control that disables
> per-user logging of greylisting.  That control is enabled by adding the
> following line to /var/dcc/whiteclnt
> 
> option greylist-log-off
> 
> 
> Vernon Schryver    vjs@rhyolite.com
> _______________________________________________
> DCC mailing list      DCC@rhyolite.com
> http://www.rhyolite.com/mailman/listinfo/dcc




More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.