I notiiced that on my redhat box etrn is turned off but to check on my suse box it is very much there. I would like to know how to tun it off I tried O PrivacyOptions=goaway,authwarnings,noetrn but that didn't work. Aslo does it have any security implications to leave it enabled? Noah ksemat@eahd.or.ug
On Wed, 16 Aug 2000, Sematimba Noah wrote:
As far as I can see, nobody answered your mail yet. sendmail's etrn doesn't have any security implications since the sendmail implementation doesn't betray any secrets to the one triggering the queue. Don't confuse etrn with expn. expn does indeed have security aspects since it provides information about deliverable addresses and therefore possible local accounts on the system in question. Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
ETRN: ETRN lets you tell the mail server to try and deliver mail to a host/domain. THis is useful because let's say I'm an ISP in europe with atrocious phone rates. I don't want to use UUCP to deliver/send email from clients that are only online for say an hour a day, I also do not want to keep their mail on my server, because they'd have to connect constantly to read/edit/etc it. So they have a mail server at their end, and Iact as a backup MX server for it. Of course 90% of the time email can't be delivered to them, so it gets delivered to my host (which holds it for say 72 hours max). Now how to force deliver to the client? Well the simply dialup, issue an ETRN command and voila! (that's french ya know) my server delivers the spooled up mail to their server. An attacker could potentially issue a shitload of ETRN commands as a denial of service. You probably want to control access to it, but it's not critical (i.e. they prolly won't get a root account through it). -Kurt
On Wed, 16 Aug 2000, Sematimba Noah wrote:
As far as I can see, nobody answered your mail yet. sendmail's etrn doesn't have any security implications since the sendmail implementation doesn't betray any secrets to the one triggering the queue. Don't confuse etrn with expn. expn does indeed have security aspects since it provides information about deliverable addresses and therefore possible local accounts on the system in question. Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
ETRN: ETRN lets you tell the mail server to try and deliver mail to a host/domain. THis is useful because let's say I'm an ISP in europe with atrocious phone rates. I don't want to use UUCP to deliver/send email from clients that are only online for say an hour a day, I also do not want to keep their mail on my server, because they'd have to connect constantly to read/edit/etc it. So they have a mail server at their end, and Iact as a backup MX server for it. Of course 90% of the time email can't be delivered to them, so it gets delivered to my host (which holds it for say 72 hours max). Now how to force deliver to the client? Well the simply dialup, issue an ETRN command and voila! (that's french ya know) my server delivers the spooled up mail to their server. An attacker could potentially issue a shitload of ETRN commands as a denial of service. You probably want to control access to it, but it's not critical (i.e. they prolly won't get a root account through it). -Kurt
participants (4)
-
Kurt Seifried -
Roman Drahtmueller -
semat＠wawa.eahd.or.ug -
Sematimba Noah